From: gijs@mbase97.hacktic.nl (Gijs Bok) Newsgroups: comp.lang.ada,comp.os.vms,comp.databases.oracle Subject: HELP! VMS Ada process in MUTEX state Message-ID: Date: Wed, 02 Feb 1994 23:32:30 +0200 Reply-To: gijs@mbase97.hacktic.nl Organization: M-BASE Lines: 52 X-Software: HERMES GUS 1.10 Rev. May 17 1993 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, my program is slow on an otherwise empty VAX. It runs as a detached process. It is given some quota which seem appropriate, but I'm no expert on this. My sysman ran sysgen during a session, and he found nothing alarming. But still my process is slow. put_line's displaying times indicate: - that task switching may be involved. - it's not Oracle queries that take long. Page faulting is low. There's enough core memory. Characteristics of the process: It's linked with Oracle7 (directly, not 2-task), using PRO*Ada. Because of Oracle, timeslicing is disabled. About 10 tasks, most of them idly waiting for a mailbox read. The process reads commands from mailboxes, executes them, and puts results back on other mailboxes. Many moderately experienced people have gathered around me, monitor-ed, sho sys-ed, sqldba-ed, but nobody can find what's going on. The process is nearly always in the MUTEX state (as shown by SHOW SYSTEM), a.k.a. the MWAIT state (as show by SHO PROC/CONT). It does what it is supposed to do, but 1 minute for deleting 4 Oracle rows and some housekeeping seems a little slow. I understand that MUTEX is something like waiting for a semaphore to be freed. But I don't understand what this semaphore protects. Is it disk space, core memory, Oracle shared memory, something in the Ada RTL? My questions are: Does anybody have a clue what's going on? Where should I look for now? I'd be very happy to provide you with additional information, if that's necessary. Thanks for your attention! -- Gijs Bok (gijs@mbase97.hacktic.nl) Listen to M-BASE music! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQA9AiyWNO4AAAEBgNsly7W6TnOlaVLOWbrkRyw1ATzledvUhPwrtAbeO/1FVOaD pmwtRkJoqMpnIYhwYQAFEbQiR2lqcyBCb2sgPGdpanNAbWJhc2U5Ny5oYWNrdGlj Lm5sPg== =J27y -----END PGP PUBLIC KEY BLOCK-----