You 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:
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.
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. You can use the remaining three buffer pools for user messages, for example:
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.
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.
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. You 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.
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.
Notices |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
csq82ee |