Question & Answer
Question
Why pruning IBM MQ message works slow with multiple RECVQs?
Cause
A Q Apply program has one Prune thread. IBM MQ messages from different RECVQ all go into the same prune thread, and the Prune thread does have to do one activity between MQCMIT and next MQGET call, in order to delete IBM MQ messages. It has to loop across each RECVQ and find IBMQREP_DONEMSG entries that can be a contiguous range eligible for a prune_batch_size deletion, and do DELETE from IBMQREP_DONEMSG table if a range is found. The larger the number of RECVQs, the longer such a search of eligible ranges take.
That's why we strongly recommend to use separate Q Apply for each RECVQ.
That's why we strongly recommend to use separate Q Apply for each RECVQ.
Answer
Workaround:
During stopq and startq, the browser prunes its own messages from RECVQ and donemsg table. Browser does one commit after pruning prune_batch_size of messages. During startq or stopq, pruning is done by corresponding browser thread instead of pruning thread. So pruning is faster.
During stopq and startq, the browser prunes its own messages from RECVQ and donemsg table. Browser does one commit after pruning prune_batch_size of messages. During startq or stopq, pruning is done by corresponding browser thread instead of pruning thread. So pruning is faster.
[{"Type":"MASTER","Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSMFN6","label":"IBM Data Replication for Availability"},"ARM Category":[{"code":"a8m0z0000001gSoAAI","label":"SQL\/Q Replication-\u003EQ Replication"}],"ARM Case Number":"TS012271545","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
12 April 2023
UID
ibm16983146