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.
- 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.