This content has been marked as final. Show 1 reply
There is no obvious patch on Tuxedo 10gR3 from 000=>042 which would have made a difference.
Your best bet is to open an SR (provide ulog, ubb, machine architecture, ps -ef, ipcs -qa, CPU usage info,truss info, and environment variables)
and have Oracle Tuxedo support review what is occurring.
The machine architecture (CPUs, memory , ipc resources) number of Tuxedo servers, interaction with other servers, and the load can contribute to Q_CAT:1447.
Here is the documentation for it:
1447 WARN: [Semaphore appears stuck - currently held by pid]
While trying to lock a portion of the queue space (using a user-level semaphore), the process is unable to get the lock for a long period.
This WARNING message is from qmlock() function, which locks any semaphore used by the queue space. The process identifier printer in this WARNING message
should give you some indication of which process is trying to lock the semaphore.
If the process is hung it must be stopped and the IPC resources must be removed using qmadmin ipcrm command
1) The ULOG for other errrors.
2) Check the IPC resources (e.g. ipcs -qa) to see what process 10223792 is doing and if it is in a deadlock with another process.
3) Check for processes using very high CPU %. Truss that process to see what it is executing(truss 10223792 if it is not the high CPU process)
There is an environment variable which may help - TM_QM_NAPTIME
Here are notes from Doc ID 976199.:
This variable "TM_QM_NAPTIME" is specific to the queue access management to avoid contention; this allows time between retry of access to a semaphore.
TM_QM_NAPTIME - Time in nano seconds a process takes a break between attempts to acquire lock. A value of 5000 is a good place to start.