Scaling the cpuplugd update interval
This topic text briefly describes how the variables mentioned in the listings in this section are calculated.
For complete configuration file listings, refer to cpuplugd configuration files.
This series of test aims to compare the impact of different update intervals (parameter UPDATE). The following rules are evaluated:
MEMPLUG="pgscanrate > 20" # kswapd + direct scansMEMUNPLUG="meminfo.MemFree > meminfo.MemTotal / 10 "
Memory is increased when the page scan rate exceeds 20 page per second. Memory is reduced when the amount of free memory exceeds 10% of total memory.
CMM_INC="meminfo.MemFree / 40"CMM_DEC="meminfo.MemTotal / 40"
Memory configuration 9 (page scan, free memory, update 2 sec). The UPDATE parameter is set to 2 seconds. The plugging rules are the same as those in configuration 2.
Memory configuration 10 (page scan, free memory, update 5 sec). The UPDATE parameter is set to 5 seconds. The plugging rules are the same as those in configuration 2, but they use only the values from the current interval, which covers now 5 seconds. The others runs use an average of the last three values.
| Configuration | Update interval (seconds) | Increase memory, if | Shrink memory, if | Relative TPS* | Relative LPAR CPU load* | Guest size (MiB)* | |
|---|---|---|---|---|---|---|---|
| Linux™ | z/VM® | ||||||
| 2 | 1 | page scans > 20 pages/sec | Free > 10% of total memory | 97% | 98% | 131% | 107% |
| 9 | 2 | 93% | 99% | 131% | 119% | ||
| 10 | 5 | 96% | 96% | 124% | 109% | ||
| *100% is the manual sized run | higher is better | lower is better | closer to 100% is better | ||||
Observation
The throughput for the scenario using an update interval of 2 seconds is lower than expected, but the throughput for the scenario using an update interval of 5 seconds is close to the throughput for the scenario using an update interval of 1 second. The CPU load shows no clear tendency either. The sum of the guest sizes in the Linux view decreases as the update interval is increased.
Conclusion
The run using an update interval of 5 seconds is consistent with the run using an update interval of 1 second in the sense that the guest size, throughput and CPU load decrease. The run using an update interval of 2 seconds seems to be affected by other unknown influences.
Determining whether cpuplugd activity depends on CPU load
Figure 1 is used to determine if cpuplugd activity depends on the CPU load. The figure shows the CPU cost per transaction for the manually sized run as a function of the duration of the cpuplugd UPDATE interval.
Observation
The CPU cost per transaction for all scenarios is very similar, with the exception of the scenario using an update interval of 2 seconds, which yielded unexpected results.
Conclusion
The expectation was that the overhead caused by cpuplugd would increase as the update interval is made shorter. However, under normal workload conditions we see no differences, meaning that evaluating the rules seems to create no noteworthy additional CPU cost. If cpuplugd changes the system configuration with a very high frequency (for example each interval) a different result may be obtained.
CMM pool size over time for scaling the cpuplugd UPDATE interval
Figure 2 is used to determine if cpuplugd activity depends on the CPU load. The figure shows the CPU cost per transaction for the manually sized run as a function of the duration of the cpuplugd UPDATE interval.
Observation
The system reaction to load changes becomes more moderate as the update interval increases. When applying an update interval of 5 seconds the CMM pool stays smaller than for shorter intervals, but in steady state it remains larger than for the shorter intervals. This is true for the Combo systems, as well as for the WebSphere® Application Server system with the higher load.
Conclusion
Neither cpuplugd activity nor the size of the UPDATE interval generates a significant overhead in terms of additional CPU cost. The UPDATE value can be used to determine how fast a system should react to changing requirements.
The recommended approach is to start with an update interval of 1 second and monitor the behavior of the system. If the update interval is changed too frequently, it is possible to calm down the system by increasing the update interval at the cost of a slower reaction to load changes. An alternative method to achieve a flattening effect is to average update values over several intervals.