Defining your buffer pools

We can use up to 16 buffer pools. However, you are recommended to use just the four buffer pools described in Table 18, except in the following circumstances:

• a particular queue is known to require isolation, perhaps because it exhibits significantly different behavior at various times.

  • such a queue might either require the best performance possible under the varying circumstances, or need to be isolated so that they do not adversely impact the other queues in a buffer pool.

  • each such queue can be isolated into its own buffer pool. However, buffer pool 3 (as described below) might be the appropriate place.

• you want to isolate different sets of queues from each other for class of service reasons.

  • each set of queues might then require any or all of the three types of buffer pools 1, 2 and 3, as described in Table 18.

The following table shows suggested values for buffer pool definitions that affect the performance of queue manager operation, recovery, and restart. Two sets of values are given; one set is suitable for a test system, the other for a production system or a system that will become a production system eventually.

Table 18. Suggested definitions for buffer pool settings

Definition setting	Test system	Production system
BUFFPOOL 0	1 050 buffers	50 000 buffers
BUFFPOOL 1	1 050 buffers	20 000 buffers
BUFFPOOL 2	1 050 buffers	50 000 buffers
BUFFPOOL 3	1 050 buffers	20 000 buffers

Reserve buffer pool zero for object definitions (in page set zero) and performance critical, system related message queues, such as the SYSTEM.CHANNEL.SYNCQ queue and the SYSTEM.CLUSTER.* queues. We can use the remaining three buffer pools for user messages, for example:

• You could use buffer pool 1 for important long-lived messages.

  Long-lived messages are those that remain in the system for longer than two checkpoints, at which time they are written out to the page set. If you have a large number of long-lived messages, this buffer pool should be relatively small, so that page set I/O is evenly distributed (older messages are written out to DASD each time the buffer pool becomes 85% full).

  If the buffer pool is too large, page set I/O is delayed until checkpoint processing. This might affect response times throughout the system.

  If you expect a small number of long-lived messages only, define this buffer pool so that it is sufficiently large to hold all these messages.

• You could use buffer pool 2 for performance-critical, short-lived messages.

  There is normally a high degree of buffer reuse, using a small number of buffers; however, you are recommended to make this buffer pool large to allow for unexpected message accumulation, for example, when a server application fails.

• You could use buffer pool 3 for all other (usually performance non-critical) messages. Queues such as the dead-letter queue, SYSTEM.COMMAND.* queues and SYSTEM.ADMIN.* queues can also be mapped to buffer pool 3.

  Where virtual storage constraints exist and buffer pools need to be smaller, buffer pool 3 is the first candidate for size reduction.

Initially, define all buffer pools as shown in the table. We can monitor the usage of buffer pools by analyzing buffer pool performance statistics. In particular, you should ensure that the buffer pools are large enough so that the values of QPSTSOS, QPSTSTLA and QPSTNBUF remain at zero. (These performance statistics are described in the WebSphere MQ for z/OS System Setup Guide.)

Tune buffer pool zero and the buffer pool for short-lived messages (buffer pool 2) so that the 15% free threshold is never exceeded (that is, QPSTCBSL divided by QPSTNBUF is always greater than 15%). If more than 15% of buffers remain free, I/O to the page sets using these buffer pools can be largely avoided during normal operation, although messages older than two checkpoints are written to page sets.

Note:

The optimum value for these parameters is dependent on the characteristics of the individual system. The values given are intended only as a guideline and might not be appropriate for your system.

MQSeries SupportPac Capacity planning and tuning for MQSeries for OS/390 (MP16) gives more information about tuning buffer pools.

Buffer pools can be dynamically re-sized with the ALTER BUFFPOOL command. For more information, see the Script (MQSC) Command Reference.