Tuning your queue manager on IBM MQ for z/OS

There are few simple steps that we can take to ensure that your queue manager is tuned to avoid basic performance problems.

There are a number of ways in which we can improve the performance of our queue manager, which are controlled by queue manager attributes set by the ALTER QMGR command. This section contains information about how we can do this by setting the maximum number of messages allowed on the queue manager, or by performing 'housekeeping' on the queue manager. IBM MQ SupportPac MP16 - WebSphere MQ for z/OS Capacity planning & tuning gives more information on performance and tuning.

Syncpoints

One of the roles of the queue manager is syncpoint control within an application. An application constructs a unit of work containing any number of MQPUT or MQGET calls terminated with an MQCMIT call. However, as the number of MQPUT or MQGET calls within the scope of one MQCMIT increases, the performance cost of the commit increases significantly.

We can limit the number of messages within any single syncpoint by using the MAXUMSGS queue manager attribute. We should not normally exceed 100 MQPUTs within a single MQCMIT.

Set a fairly low MAXUMSGS value, such as 100, to avoid performance problems, and to protect against looping applications. If we have a need for a larger value, change MAXUMSGS temporarily while the application that requires the larger value is run, rather than using a permanently high value. However, be aware that reducing the value of MAXUMSGS can cause problems to existing applications and queue manager processes such as clustering if they are already using a higher value.

When publishing messages out of syncpoint to topics it is possible to receive this reason code. See Publishers and publications.

MAXUMSGS has no effect on MQ Telemetry. MQ Telemetry tries to batch requests to subscribe, unsubscribe, send, and receive messages from multiple clients into batches of work within a transaction.

Expired messages

Messages that have expired are discarded by the next appropriate MQGET call. However, if no such call occurs, the expired messages are not discarded, and, for some queues, particularly those where message retrieval is done by MessageId, CorrelId, or GroupId and the queue is indexed for performance, many expired messages can accumulate. The queue manager can periodically scan any queue for expired messages, which are then deleted. We can choose how often this scanning takes place, if at all. There are two ways of doing this:

Explicit request

We can control which queues are scanned and when. Issue the REFRESH QMGR TYPE(EXPIRY) command, specifying the queue or queues that we want to be scanned.

Periodic scan

We can specify an expiry interval in the queue manager object by using the EXPRYINT attribute. The queue manager maintains information about the expired messages on each queue, and knows at what time a scan for expired messages is worthwhile. Each time that the EXPRYINT interval is reached, the queue manager looks for candidate queues that are worth scanning for expired messages, and scans only those queues that it deems to be worthwhile. It does not scan all queues. This avoids any processor time being wasted on unnecessary scans.

Shared queues are only scanned by one queue manager in the queue sharing group. Generally, the first queue manager to restart or the first to have the EXPRYINT set performs the scan.

Note: We must set the same EXPRYINT value for all queue managers within a queue sharing group.

Parent topic: Defining the system on z/OS