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 initial characteristics of 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 pageset.
  • You want to isolate different sets of queues from each other for class-of-service reasons.
    • Each set of queues might then require one, or both, of the two types of buffer pools 1 or 2, as described in Table 2, necessitating creation of several buffer pools of a specific type.

[Continuous Delivery]In IBM® MQ 9.0 for z/OS®, the maximum number of buffer pools that you can define depends on the OPMODE parameter. If IBM MQ 8.0 new functions are enabled, a maximum of 100 buffer pools can be defined. Otherwise, a maximum of 16 buffer pools can be defined.

Decide on the initial characteristics of each buffer pool

Having decided on the number of buffer pools that you require, you now need to decide the initial characteristics of those buffer pools. The available characteristics are affected by OPMODE, and are summarized in Table 1.
Table 1. Buffer pool characteristics by OPMODE setting
Parameter name/ OPMODE setting Maximum number of buffers in a single buffer pool Maximum number of buffer pools Maximum total number of buffers in queue manager Buffer pool location Buffer pool page class
DEFINE or ALTER BUFFPOOL parameter BUFFERS     LOCATION (ABOVE/ BELOW) PAGECLAS (4KB/FIXED4KB)
[Continuous Delivery]IBM MQ 8.0 new functions not enabled [Continuous Delivery]500 000 [Continuous Delivery]16 [Continuous Delivery]Limited by available space below the bar. Likely to be less than 262 144 [Continuous Delivery]BELOW bar [Continuous Delivery]Pageable (4KB)
[Continuous Delivery]IBM MQ 8.0 functions enabled [Continuous Delivery]999 999 999 [Continuous Delivery]100 [Continuous Delivery]99 999 999 900 (If MEMLIMIT /IEFUSI exit allows) [Continuous Delivery]ABOVE or BELOW bar [Continuous Delivery]Pageable (4KB) or page-fixed (FIXED4KB)

If you are using the four buffer pools described in Decide on the number of buffer pools to define, then Table 2 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. Regardless of the OPMODE setting, the values assume that the buffer pools will be located below the bar, and that the buffers will be pageable.
Table 2. 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 Table 2.

[Continuous Delivery]It might be that you will need to reduce the size of some of the other buffer pools, or reconsider the number of buffer pools, especially if you have not enabled IBM MQ 8.0 new functions with OPMODE.

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 initial characteristics of each buffer pool, if required.

Use the performance statistics from Monitor the performance of buffer pools under expected load as guidance.
[Continuous Delivery]Note: These points all assume that IBM MQ 8.0 new functions have been enabled with OPMODE, with the exception of point 2.
  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 pagesets that use it, although you should take into account pageset 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 - WebSphere® MQ for z/OS Capacity planning & tuning provides further information about tuning buffer pools.