Skip to main content

MQ tuning the persistent queue buffer with NewPQBufferSize

In the course of writing a health check for MQ and IIB this week, I was reminded of some log tuning mystique that we resolved at Hursley concerning queue buffers.

As detailed elsewhere, DefaultQBufferSize is the TuningParameters stanza value that determines the size of the non-persistent buffer of a queue. The queue's non-persistent buffer will adopt the size of this parameter based on the value this was set to in the qm.ini when the QM was last started, but before the queue was created. If this value is not set in the qm.ini at that time, then the default value is 128KB.

So far, this is pretty much aligned with the 'received wisdom', as long as you looked under the right stone.

What is not generally known is that the queue persistent buffer 'equivalent' is not DefaultPQBufferSize (which I will describe shortly), but NewPQBufferSize!

NewPQBufferSize: The persistent buffer of a queue will be set to whatever value was when the QM was last started and before the queue was created. If this value is not set in the qm.ini at that time, then the persistent buffer for the queue will be determined by DefultPQBufferSize.

Finally,

DefaultPQBufferSize: If NewPQBufferSize was not set when the queue was created, then at any time, the size of its persistent buffer will be determined by whatever value DefaultPQBufferSize was when the QM was last started.

To see evidence of the change to the queue buffers for DefaultQBufferSize and NewPQBufferSize, you can perform the following test:


1) Define a test queue.
UNIX/Linux: echo "define ql(TESTQ)" | runmqsc MYQM
Windows: echo define ql(TESTQ) | runmqsc MYQM

2) Check the current values of the storage class for this queue.
amqldmpa -m MYQM -c A -q TESTQ -u 1 -d 15 -f amqldmpa.txt

UNIX/Linux: grep StgClass amqldmpa.txt
Windows: type amqldmpa.txt | findstr "StgClass"

    StgClass.Granularity      512
    StgClass.MaxMsgsInBuffer  512
    StgClass.MaxQFileLength   2199023254528
    StgClass.MaxQFileBlocks   4278190080
    StgClass.MaxQBufferLength 131072    << Current DefaultQBufferSize
    StgClass.MaxPsistBuffer   -1                << Current, I  claim, NewPQBufferSize, -1 means default

3) Add the following stanza to qm.ini

TuningParameters:
#*1 mb persistent buffer for all open queues*#
   DefaultPQBufferSize=1048576
#*5 mb nonpersistent buffer for all open new queues*#   
   DefaultQBufferSize=5242880
#*10 mb persistent buffer for all open new queues*#
   NewPQBufferSize=10485760    

4) Delete the test queue.
UNIX/Linux: echo "delete ql(TESTQ)" | runmqsc MYQM
Windows: echo delete ql(TESTQ) | runmqsc MYQM

5) Restart the queue manager.
endmqm -w MYQM
strmqm MYQM

6) Redefine the test queue
UNIX/Linux: echo "define ql(TESTQ)" | runmqsc MYQM
Windows: echo define ql(TESTQ) | runmqsc MYQM

7) Check the updated values for the queue's storage class (these are appended to the file, if you did not delete it).
amqldmpa -m MYQM -c A -q TESTQ -u 1 -d 15 -f amqldmpa.txt

UNIX/Linux: grep StgClass amqldmpa.txt
Windows: type amqldmpa.txt | findstr "StgClass"

    StgClass.Granularity      512
    StgClass.MaxMsgsInBuffer  512
    StgClass.MaxQFileLength   2199023254528
    StgClass.MaxQFileBlocks   4278190080
    StgClass.MaxQBufferLength 131072        << Old DefaultQBufferSize
    StgClass.MaxPsistBuffer   -1                    << Old NewPQBufferSize
    StgClass.Granularity      512
    StgClass.MaxMsgsInBuffer  512
    StgClass.MaxQFileLength   2199023254528
    StgClass.MaxQFileBlocks   4278190080
    StgClass.MaxQBufferLength 5242880    << New DefaultQBufferSize
    StgClass.MaxPsistBuffer   10485760        << New NewPQBufferSize

Notice that StgClass.MaxPsistBuffer is 10MB not 1MB (that is, the value which we set for NewPQBufferSize, not DefaultPQBufferSize).

It is worth noting that qtune for supportPac MS0P (MS0P: WebSphere MQ Explorer – Extended Management Plug-ins and Tools) shows pretty much the same thing. (See Mark Taylor's well explained video MS0P part 2 - QTune.)

D:\Tools\MQ\ms0p\qtune>qtune -m MYQM -q TESTQ
File C:\ProgramData\IBM\MQ\qmgrs\MYQM\QUEUES\TESTQ
Stored npBuff     = 5,120 kB
Stored pBuff      = 10,240 kB
Stored maxQSize   = 2,097,151 MB

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Comments

Post a Comment

Popular posts from this blog

Linux systemd for integration nodes as well as MQ?

So, in the tips and tricks that are out there, you will find suggestions on how to set up an MQ queue manager as a systemd service. Here is a quick refinement for a slightly more robust version and the inclusion of an IIB (or ACE) integration node.   The following shows the necessary settings and commands (and tests the service). This works with integration nodes that are associated with queue mangers of the same name. (A practice I have personally adopted for a good few years - for numerous good reasons, including the fact that is simple to remember.) These are scant notes, but you should be able to 'read between the lines'. Enjoy!  crtmqm -ld /var/mqm/log -md /var/mqm/qmgrs -lf 16384 -lc -lp 5 -ls 5 -u SYSTEM.DEAD.LETTER.QUEUE TEST strmqm TEST mqsicreatebroker TEST -q TEST -w /var/mqsi -o advanced -s inactive endmqm TEST Switch to root: su - intadm belongs to mqm (primary group) and mqbrkrs vi /etc/systemd/system/mq@.service [Unit] Description=IBM MQ queue manager %I After=ne
Post a Comment
Read more

PKI (SSL) connection setup of client MQ and IIB tooling - Rfhutil

  This series of walk-throughs is intended to provide some guidance to developers to set up their client tooling connections, by means of example, where PKI (public key infrastructure) is employed with MQ and IIB endpoints. PKI is generally used to distinguish an SSL infrastructure from an environment where self-signed certificates are employed as personal certificates. Self-signed certificates are a quick and easy way for a developer to practice with some of the SSL aspects of their code, but are not recommended for a full Development environment and certainly not for Production. Why would one employ PKI in a Development environment? The simple answer is that there are differences and the sooner those differences are got to grips with in the development cycle the more rapid and successful the adoption of PKI will be. Following that preamble, I should add that the details of how to build and manage PKI are detailed elsewhere. (Management being far more the tric
Post a Comment
Read more