Executive summary

The approach used to analyze the impact of the cpuplugd rules.

This new version of the Linux™ cpuplugd daemon is a very powerful tool that can automatically adjust the CPU and memory resources of a Linux z/VM® guest. Starting with a common sizing of 4 CPUs and 5 GB memory for each guest, it adjusts the resources as required. Guests with very different middleware and combinations of middleware, different memory sizes, and workload levels have been tested and compared with a manually sized setup.

The approach is to manage all the different guests with the same rule set. For CPU management the important criteria is the management target. It is possible to either manage the CPUs exactly and with a very fast response to changing requirements, or to have a system which reacts to increasing requirements in a very restrictive manner.

The more complex part with respect to one common rule set for all guests is the memory management. Here the requirements of the various guests were so different, that for one common set of rules a trade-off between best performance or minimal resource usage had to be made. Setting up individual rules could improve the result. However, even with the common set of rules the impact on performance can be kept small (around 4% throughput degradation and corresponding reduction in CPU load) with only 5% more memory (z/VM view) as compared to the manually-sized run.

In our memory management tests, we stopped the middleware to ensure that the memory was freed up and made available again. An alternative would be to set up the middleware so that the required memory buffers can shrink when not in use. For example, define a WebSphere® Application Server with a much smaller initial heap size than the maximum heap size.

Note: For a high performance environment it is recommended that the initial heap size is set to the maximum heap size to avoid memory fragmentation and memory allocations during runtime.

Another important aspect of the comparison is that the manual sizing requires a set of test runs to identify this setup, and it is only valid for that single load pattern. If, for example, the workload on one system increases and decreases on another system by a similar amount, the total performance will suffer, whereas the cpuplugd managed guests would activate and deactivate resources as required and keep the total amount of used resources constant, that is, without changing the resource overcommitment ratio. The system now reacts according to the load pressure.

Table 1 compares the different approaches for sizing and their trade-offs:

Table 1. Different Sizing approaches and their trade-offs
Approach	Effort	Sizing and performance	Flexibility
Manual sizing	very high	optimal	none
Generic default rules	small	good trade-off	very high
Server-type adapted rules	singular effort	very good	high

The paper helps to select either generic rules or gives guidance to develop server type depending rules. The suggested default configuration file is described in Recommended default configuration.

This will help customers to automatically adjust and optimize resource usage of Linux guests according to the current load characteristics