Can a private queue be in two places?
Simply no, but it can look like it. In reviewing one customer’s data for performance problems I found the following (names are changed) :
As you can see ELKINSC.QUEUE1 shows up as being in both pageset 0/ bufferpool 0 and pageset 4/ bufferpool 3. When I asked the development lab some years ago about this, the explanation given is that this is because when the transaction started the no access to the bufferpool and pageset for that queue had been done. The physical location of the queue was not yet established, so these two fields were in the initial state. This can happen on first access or if a queue is consistently able to take advantage of put to a waiting getter. As the latch type (‘19’) (see Figure 2) indicates a buffer wait, and other transactions show non-zero values for the pageset and bufferpool, then the transaction reporting the zeros was very likely the first access to the queue. There was some discussion on fixing this in the SMF buffer, but as no customer has complained, it is not a priority for either level 3 support or development.
Another interesting thing about this data, one of the transactions that showed the long latch crossed SMF boundaries. The longest latch time and type are the same across many SMF accounting records (see Figure 1), and all these have the same Correlation – or task identifier information. So where it may look like there are several instances of long latches for transaction using ELKINS.QUEUE1, in reality there are only two instances.
After checking with the customer, just to be sure that they did not move the queue, the queue is physically located on pageset 4 bufferpool 3 and has not moved. As nearly all the queues used in the environment are using that same pageset and bufferpool combination, they have probably used the typical DEFAULT storage class or DEFINE LIKE to copy an existing queue definition. Because they are expecting growth in the use of these transactions and queues, I am giving two recommendations:
1) Add pages to bufferpool 3, which from the MQ statistics is under a bit of stress
2) Move some of the more active queues to other storage classes to reduce the contention for the underlying resources.
Contention for pages in the bufferpool, with all the transactions in the environment using queues in the same storage class, can slow down work even though they may not be showing the traditional signs of buffer stress.
This table is the result of a query against data processed by MQSMFCSV and loaded into DB2 as shown:
SELECT Q.QMgr, Correlation, Base_Name, Pageset_ID, BufferPool_ID, Get_Pageset_Count, Get_Messages_Skipped_Count, Get_Messages_Expired_Count, Put_Pageset_Access_Count, Put1_Pageset_Access_Count, Correl, Longest_Latch, Max_Latch_Wait_Time_us, Max_Latch_Wait_ID, Start_Time_Date, Start_Time_Time
FROM MQSMF.WQ Q , MQSMF.WTAS WTAS
(Q.QMgr = ”QML1” AND Correlation = Correl AND
Longest_Latch > ”00000000000000000” AND
Max_Latch_Wait_Time_us > 25000 )
Note that the latch wait time used is 25,000 microseconds. This value is arbitrary, I have chosen it because it seems a reasonable cut off point for workload that has semi-formal service level agreements of a response in a second. This value may be too high for some applications and may over-report issues for others. Knowing the application expectations and workload is key to setting this value appropriately for your environment.