Defining your buffer pools

Use this topic to help plan the number of buffer pools you should define, and their settings.

This topic is divided into the following sections:
  1. Decide on the number of buffer pools to define
  2. Decide on the settings for each buffer pool
  3. Monitor the performance of buffer pools under expected load
  4. Adjust buffer pool characteristics

Decide on the number of buffer pools to define

You should define four buffer pools initially:
Buffer pool 0
Use 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.COMMAND.QUEUE and SYSTEM.CLUSTER.REPOSITORY.QUEUE queues.

However it is important to consider point 7 in Adjust buffer pool characteristics if a large number of channels, or clustering, is to be used.

Use the remaining three buffer pools for user messages.

Buffer pool 1
Use 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 many 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, and the buffer pool never gets to 85% full, page set I/O is delayed until checkpoint processing. This might affect response times throughout the system.

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

Buffer pool 2
Use for performance-critical, short-lived messages.

There is normally a high degree of buffer reuse, using few buffers. However, you should make this buffer pool large to allow for unexpected message accumulation, for example, when a server application fails.

Buffer pool 3
Use for all other (typically, performance noncritical) 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.

You might need to define additional buffer pools in the following circumstances:
  • If a particular queue is known to require isolation, perhaps because it exhibits 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 it does not adversely affect the other queues in a buffer pool.
    • Each such queue can be isolated into its own buffer pool and page set.
  • You want to isolate different sets of queues from each other for class-of-service reasons.

Decide on the settings for each buffer pool

If you are using the four buffer pools described in Decide on the number of buffer pools to define, then Suggested definitions for buffer pool settings gives two sets of values for the size of the buffer pools.
The first set is suitable for a test system, the other for a production system or a system that will become a production system eventually. In all cases define your buffer pools with the LOCATION(ABOVE) attribute
Table 1. 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
If you need more than the four suggested buffer pools, select the buffer pool (1 or 2) that most accurately describes the expected behavior of the queues in the buffer pool, and size it using the information in Suggested definitions for buffer pool settings.

Ensure that your MEMLIMIT is set high enough, so that all the buffer pools can be located above the bar.

Monitor the performance of buffer pools under expected load

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 QPSTDMC remain at zero.

For further information, see Buffer manager data records.

Adjust buffer pool characteristics

Use the following points to adjust the buffer pool settings from Decide on the settings for each buffer pool, if required.

Use the performance statistics from Monitor the performance of buffer pools under expected load as guidance.
  1. If you are migrating from an earlier version of IBM® MQ, only change your existing settings if you have more real storage available.
  2. In general, bigger buffer pools are better for performance, and buffer pools can be much bigger if they are above the bar.

    However, at all times you should have sufficient real storage available so that the buffer pools are resident in real storage. It is better to have smaller buffer pools that do not result in paging, than big ones that do.

    Additionally, there is no point having a buffer pool that is bigger than the total size of the page sets that use it, although you should take into account page set expansion if it is likely to occur.

  3. Aim for one page set per buffer pool, as this provides better application isolation.
  4. If you have sufficient real storage, such that your buffer pools will never be paged out by the operating system, consider using page-fixed buffers in your buffer pool.

    This is particularly important if the buffer pool is likely to undergo much I/O, as it saves the CPU cost associated with page-fixing the buffers before the I/O, and page-unfixing them afterwards.

  5. There are several benefits to locating buffer pools above the bar even if they are small enough to fit below the bar. These are:
    • 31 bit virtual storage constraint relief - for example more space for common storage.
    • If the size of a buffer pool needs to be increased unexpectedly while it is being heavily used, there is less impact and risk to the queue manager, and its workload, by adding more buffers to a buffer pool that is already above the bar, than moving the buffer pool to above the bar and then adding more buffers.
  6. 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.
    Attention: 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.
  7. SYSTEM.* queues which get very deep, for example SYSTEM.CHANNEL.SYNCQ, might benefit from being placed in their own buffer pool, if sufficient storage is available.

IBM MQ SupportPac MP16 - IBM MQ for z/OS® Capacity planning & tuning provides further information about tuning buffer pools.