Large messages depths on your WebSphere MQ queues could cause performance issues
ValerieLampkin 27000182R2 Comments (5) Visits (10011)
WebSphere MQ allows independent and asynchronous applications to communicate with each other across a large number of platforms. MQ software is not optimized for storing a large number of messages on a local queue for an extended period of time. MQ can process millions of messages in a short amount of time as throughput but when they sit on the queues and have to be reloaded from memory, it slows the processing and you would likely see performance issues.
If a large number of messages are left on queue, you may see AMQ7234 messages in the queue manager logs to indicate you have very large depths of messages on your queues. When one queue has an unusually large depth it can hold up resources within the queue manager and cause timeout delays/errors for other processes.
Storing thousands of messages on a single queue is not a best practice. When a queue is unreferenced for a period of activity, then MQ unloads the queue from memory. This process is known as "unloading the queue". When the queue is next referenced the queue index needs to be rebuilt in memory. This is known as loading the queue. As the queue is loaded, message AMQ7234 is issued periodically (by default every 10,000 messages). When the queue manager is loading the messages from disk to memory, any application that tries to access the same queue has to wait until the queue lock is released; i.e., until all the messages are loaded to the memory.
Persistent messages on queues are also stored in the logs. At queue manager restart the updates in the log are replayed against the queue files. The messages are then accessed from the queue files.
Below is an example of queue manager log entries showing an extremely large depth of messages on the queue:
04/24/2013 04:21:11 PM - Proc
AMQ7234: 620000 messages from queue 'LARGE.QUEUE' on queue manager 'QMGR1'.
In some instances during queue manager startup, the strmqm command may even pause for a while waiting for all of the messages to be reloaded on the queues, appearing to be “hung”. The best way to avoid performance issues due to large queue depths is to design your applications so that messages are being processed in a timely manner and enable alerting should the curdepth of your queues increase beyond a manageable number.