Re: locked mutexes!

Added to the faq as useful to know. Jacques add to the credits list for the FAQ! David. > On 11 September 2013 at 16:08 JACQUES RENAUT <jrenaut@us.ibm.com> wrote: > > > Original post: > > Hi, > > I had some user sessions in locked mutexes > > onstat -g lmx> Locked mutexes: > 8777 c00000019a5c0f30 uselock0 2708810 0 > 8778 c00000019a619f30 uselock1 1683484 0 > 8779 c00000019a620f30 uselock2 2708811 0 > > I was able to trace those sessions using holder thread id and they were doing > nothing just like hung sessions. > onstat -u> > c0000001c7b78960 Y--P--- 1908207 xxx tR c0000001a20a9c50 0 1 0 0 > c0000001c7b80e60 Y--P--- 1878654 xxx tq c00000019c3a7860 0 1 0 0 > c0000001c7b95ae0 Y--P--- 1908957 xxx tR c0000001ec7edf90 0 1 0 0 > > I don't see any performance issues so far but wanted to know if it can impact > anything before users starts complaining.. > > IDS:11.50 FC5 > OS:HP-UX 11.23 ia64 > > Thanks!! > > Response: > > First off, stuff in the onstat -g lmx output isn't by default bad, it would > only possibly reflect a performance problem if you possibly saw large list of > waiters on a particular mutex, or large wait times. Second, the uselock mutex > has something to do with shared memory communication and so it's normal to see > that mutex locked while the sqlexec threads for those sessions aren't doing > anything...well what they are doing is waiting for the next request to do > something from the client application (so waiting for work). > > Jacques Renaut > IBM Informix Advanced Support > APD Team > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >