Cluster caching facility memory and CPU usage monitoring overview

A basic indicator of the operational effectiveness of a cluster caching facility is the extent to which memory and the CPU are consistently used to their maximum configured capacity.

Memory usage

Cluster caching facilities (also known as CFs) use different memory heaps for the following purposes:

Group buffer pool memory
Group buffer pool memory is used for the group buffer pool for the Db2® pureScale® instance. If this type of memory is consistently used to the maximum configured capacity, it might have a negative effect on performance. However, the fact that memory might be used to capacity is not itself an indicator that performance might be affected. Check the hit rates for the group buffer pool to confirm that performance has degraded. Low hit rates coupled with high group buffer pool memory usage might be an indication that this type of memory needs to be increased. This type of memory is configured by the cf_gbp_sz configuration parameter.
Lock memory
Lock memory is used for managing page locks across the Db2 pureScale instance. If there is insufficient memory available for locks on the CF, one or both of the following conditions might arise:
  • Lock escalation might take place, which reduces concurrency for the objects involved
  • Requests for locks might be denied, resulting in the SQL0912 message being returned.
This type of memory is configured by the cf_lock_sz configuration parameter.
Shared Communication Area (SCA) memory
SCA memory contains database-wide information for tables, indexes, table spaces, and catalogs. Each database has its own SCA memory in the CF. It is allocated during the first database activation on any database member, and is not freed until the database is dropped, or the CF is stopped. If table partitioning is used then the information required to synchronize the table partitioning data between the CF and the members is also stored in SCA memory.

If this type of memory is used to capacity, tables may fail to load, and an error is returned. This type of memory is configured by the cf_sca_sz configuration parameter.

Overall CF memory
Overall CF memory is the total amount of physical memory available to the CF. It is set by the cf_mem_size configuration parameter. The memory for the group buffer pool, locks and shared communication area are all allocated out of this pool of memory. For this reason, the total amount of the memory allocated for these specific types of memory must not exceed the amount of memory configured using the cf_mem_size configuration parameter.

By default, configuration of each of these types of memory is performed automatically. The Db2 pureScale Feature provides monitor elements that you can use to examine the amount of each of these types of memory that is currently in use by the system. There are also related elements that you can use to determine what the maximum size is for each type of memory, and whether a memory resize operation is in progress.

In addition to monitor elements that report on the usage of specific types of CF memory, you can use the ENV_CF_SYS_RESOURCES administrative view to examine the total amount of physical and virtual storage available to the CF.

CPU load

CPU load on the CF is an indication of how heavily taxed its processors are. If you find that the processors on the host where the CF is running are working at maximum capacity most of the time, it might be an indication that the host the CF is running on is not powerful enough. You might want to add processors, or upgrade to a more powerful system.

You can view the overall CPU load for the host serving as the CF in a Db2 pureScale instance using the ENV_CF_SYS_RESOURCES administrative view.

Note: The value reported for CPU load reflects the total usage of the CPU for actual processing performed by the CF, and for host processes other than processes from the CF.