If your application is running slowly, it might be in a loop or waiting for a resource that is not available.
This might also indicate a performance problem. Perhaps your system is operating near the limits of its capacity. This type of problem is probably worst at peak system load times, typically at mid-morning and mid-afternoon. (If your network extends across more than one time zone, peak system load might seem to occur at some other time.)
A performance problem might be caused by a limitation of your hardware.
If you find that performance degradation is not dependent on system loading, but happens sometimes when the system is lightly loaded, a poorly-designed application program is probably to blame. This could appear to be a problem that only occurs when certain queues are accessed.
The following symptoms might indicate that WebSphere MQ is running slowly:
If the performance of your system is still degraded after reviewing the above possible causes, the problem might lie with WebSphere MQ itself. If you suspect this, contact your IBM(R) Support Center for help.
If you are using AIX, consider setting your tuning parameter to exploit full performance for nonpersistent messages. To set the tuning parameter so that it takes effect immediately, issue the following command as a root user:
/usr/sbin/ioo -o j2_nPagesPerWriteBehindCluster=0
To set the tuning parameter so that it takes effect immediately and persists over reboots, issue the following command as a root user:
/usr/sbin/ioo -p -o j2_nPagesPerWriteBehindCluster=0
Normally, nonpersistent messages are kept only in memory, but there are circumstances where AIX can schedule nonpersistent messages to be written to disk. Messages scheduled to be written to disk are unavailable for MQGET until the disk write completes. The suggested tuning command varies this threshold; instead of scheduling messages to be written to disk when 16 kilobytes of data are queued, the write-to-disk occurs only when real storage on the machine becomes close to full. This is a global alteration and may effect other software components.
On AIX, when using multithreaded applications and especially when running on machines with multiple CPUs, we strongly recommend setting AIXTHREADSCOPE=S in the environment before starting the application, for better performance and more solid scheduling. For example:
export AIXTHREADSCOPE=S
Setting AIXTHREAD_SCOPE=S means that user threads created with default attributes will be placed into system-wide contention scope. If a user thread is created with system-wide contention scope, it is bound to a kernel thread and it is scheduled by the kernel. The underlying kernel thread is not shared with any other user thread.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
amqh |