[luw - v10.5 FP8] [QRepl - 10.2.1] negative current_memory and 0 trans_spilled in IBMQREP_CPAMON?

Rui Chen

[luw - v10.5 FP8] [QRepl - 10.2.1] negative current_memory and 0 trans_spilled in IBMQREP_CPAMON?

Seems like we reached our max memory_limit, but interestingly trans_spilled always stays at 0. Does that mean no new tx captured while QCap saturated its memory? How does QCapture program behave while it exhausted available memory? Naively i would expect none-zero trans_spilled, but what do i know..... There's no info logged in QCap program log, nor any monster_transaction reported on IBMQREP_APPLYMON (not a surprise though) ... 

We are also considering doubling our memory_limit (currently at 2GB, far away from the 100GB upper limit....), and we do have more than enough free memory to allocate (O(100)GB free memory). Curious if someone had unpleasant experience with high memory_limit.... thanks 

Oh, and Happy New Year everyone!

David Williams

[luw - v10.5 FP8] [QRepl - 10.2.1] negative current_memory and 0 trans_spilled in IBMQREP_CPAMON?
(in response to Rui Chen)
"Seems like we reached our max memory_limit"...how do you know?

Are we talking Q Capture memory_limit or Q Apply memory_limit?

For Q capture:

https://www.ibm.com/support/knowledgecenter/SSTRGZ_11.4.0/com.ibm.swg.im.iis.repl.qtune.doc/topics/iiyrqtunrepca.html?cp=SSEPGG_11.1.0

https://www.ibm.com/support/knowledgecenter/SSTRGZ_11.4.0/com.ibm.swg.im.iis.repl.qtune.doc/topics/iiyrqtunrepca2.html?cp=SSEPGG_11.1.0

"The memory_limit parameter specifies the amount of memory that a Q Capture program can use to build transactions in memory."

"You might need to increase the memory limit if the Q Capture program is spilling transactions to disk or virtual I/O."

" If the TRANS_SPILLED column in the IBMQREP_CAPMON table has a value greater than 0 (you can also view this value in the Q Capture Throughput window in the Replication Center), try increasing the memory limit."

For Q Apply:

https://www.ibm.com/support/knowledgecenter/en/SSTRGZ_11.4.0/com.ibm.swg.im.iis.repl.qtune.doc/topics/iiyrqtunrepap4.html?cp=SSEPGG_11.1.0

"The memory_limit parameter determines the amount of memory that a Q Apply program can use as a buffer to process transactions from one receive queue. "

"When the memory limit is reached, the browser thread stops getting messages from the receive queue and waits for agent threads to apply more transactions to the target table to free memory. If a single transaction is large enough to exceed the memory limit, the browser thread applies partial rows of the transaction before processing more rows of the same transaction. Both of these actions slow performance."

"The MONSTER_TRAN column measures the number of transactions that exceeded the memory limit."

Regards,
David.

> On 28 December 2018 at 21:24 Rui Chen <[login to unmask email]> wrote:
>
>
> Seems like we reached our max memory_limit, but interestingly trans_spilled always stays at 0. Does that mean no new tx captured while QCap saturated its memory? How does QCapture program behave while it exhausted available memory? Naively i would expect none-zero trans_spilled, but what do i know..... There's no info logged in QCap program log, nor any monster_transaction reported on IBMQREP_APPLYMON (not a surprise though) ... 
> We are also considering doubling our memory_limit (currently at 2GB, far away from the 100GB upper limit....), and we do have more than enough free memory to allocate (O(100)GB free memory). Curious if someone had unpleasant experience with high memory_limit.... thanks 
> Oh, and Happy New Year everyone!
>
>
> -----End Original Message-----

Rui Chen

RE: [luw - v10.5 FP8] [QRepl - 10.2.1] negative current_memory and 0 trans_spilled in IBMQREP_CPAMON?
(in response to David Williams)

Thanks for the reminder David, i jumped to the conclusion of QCapture program reaching its memory_limit, which is probably not accurate (still waiting for our operational team for the memory_limit config in-use on capture side, which could've been overwritten during QCapture startup, and we don't have an easy way seeing it... ).

I saw our IBMQREP_CAPMON.current_memory has been lingering around 1800/1900MB range, and then became negative when we had high capture latency. Actually IBMQREP_CAPMON.current_memory uses INT (-2^31 ~ 2^31-1 ?), which doesn't sound like a good choice, considering memory_limit can be configured to 100GB.....

As for our high capture_latency, we had higher than normal MQ_BYTES/MQCMIT_TIME/MQPUT_TIME/TRANS_QUEUED, suggesting QCapture couldn't put TX/MSG onto XMITQ quick enough. Nothing conclusive yet, still researching for potential other possibilities/improvements.

Edited By:
Rui Chen[Organization Members] @ Dec 28, 2018 - 09:28 PM (America/Eastern)