locked mutexes!

Hi, I had some user sessions in locked mutexes onstat -g lmxLocked 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!!

Original post: Hi, I had some user sessions in locked mutexes onstat -g lmxLocked 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