DB2AA Customer Consumable Interface for Memory Monitoring

In DB2AA V4 all of the paired subsystems to a single Accelerator are sharing a common apply agent memory structure of 8 GB. This is a fixed size.

As customers add more subsystems to this single accelerator with replication (CDC) enabled, there is more competition for this same 8 GB buffer. If this buffer becomes fully used then this will results in more frequent flushes of memory into Netezza (even before apply interval of 1 minute is over). This results in more inefficient DML statements pushed into the database back-end.

There is a recommended limit of 10 subsystems configured in the way to a single accelerator, which is somewhat "artificial". It is just a value that the lab is confident with supporting because it was thoroughly tested and measured.

Currently, there is no external "customer consumable" interface to monitor memory usage and contention for CDC. There are IBM internal tools like RAS/PD to monitor the CDC JVM (heap stats, garbage collection frequency, etc.). There is also useful information that can be extracted IDAA traces using some python scripts.

To proceed with this type of analysis from the lab, the customer needs to collect a trace file from the existing Netezza box where you have a number of subsystems active and replicating into the accelerator. They will then need to open a PMR, and in the PMR indicate that IDAA L3 or CDC L3 should look at traces with RAS/PD to review the memory allocation/contention of the 8 GB memory buffer.

This RFE is to enable a customer consumable interface to be able to monitor the memory usage and contention on the Netezza box.