Dynamic runs

Edit online

The tests in the previous sections are intended to determine the impact of the various rules. The next important question is how a system managed by cpuplugd reacts to load shifts.

For this purpose an additional group of guests are created (two additional triplets and two additional combo servers). The first group of guest are referred to as “Set 1”, the new group of guests referred to as “Set 1” (see also WebSphere environment).

The steps in the experiment are as follows:

  1. load phase 1: Load on guest set 1
    1. Start the middleware on the servers in guest set 1.
    2. Run the workload against the servers in guest set 1.
    3. Stop the workload and shut down the middleware running on the servers in guest set 1.
  2. wait phase 1
    • Now that all guests in set 1 are warmed up, no middleware server or load is running, the important question is whether the guests release resources
    • The second set of guests are idle, and require few resources
  3. load phase 2: Load on guest set 2
    1. Start the middleware on the servers in guest set 2.
    2. Run the workload against the servers in guest set 2.
    3. Stop the workload and shut down the middleware running on the servers in guest set 2.
  4. wait phase 2
    • Now that all guests in all sets are warmed up, no middleware server or load is running
    • Resources allocated to servers in guest set 2 should be released
    • The question is whether the resource utilization reaches the same level it reached in wait phase 1
  5. load phase 3: Load on guest set 1
    1. Start the middleware on the servers in guest set 1.
    2. Run the workload against the servers in guest set 1.
    3. Stop the workload and shut down the middleware running on the servers in guest set 1.

The cpuplugd configuration used is configuration 2:

Memory configuration 2 (page scan, free memory). The plugging rules are:
  • MEMPLUG="pgscanrate > 20" # kswapd + direct scans
  • MEMUNPLUG="meminfo.MemFree > meminfo.MemTotal / 10 "
Memory is increased if the page scan rate exceeds 20 pages per second. Memory is reduced if more than 10% of the total memory is free. The rules use the values the variables have during each interval.
The CMM pool increments are defined as follows:
  • CMM_INC="meminfo.MemFree / 40"
  • CMM_DEC="meminfo.MemTotal / 40"

Figure 1 shows the amount of free memory in z/VM® over time for the manually sized configuration and for cpuplugd with configuration 2 as reported from the z/VM performance toolkit report AVAILOG (FCX254).

In the manually sized case, the total memory size from the guests of one set is 9,508 MiB, both sets together are defined with 19,016 MiB. The z/VM system size is 20 GB.

Figure 1. Free z/VM memory over time when switching the workload from guest set 1 to guest set 2.
Graph showing free z/VM memory over time when switching the workload from guest set 1 to guest set 2.

Observations

The free memory during load phase 1 is larger in the manually sized scenarios than in the cpuplugd managed scenario. In both wait phases, when the middleware is shut down, some memory is given back in the cpuplugd managed case, while the manually sized scenario shows no reaction on that. This means that the cpuplugd managed scenario frees up more memory and this does not change for the remainder of the test. Comparing the manual configuration with the system being managed by cpuplugd, the latter scenario uses up about 1.5 GB less memory.

When the middleware and load are started on guest set 2 in load phase 2, a significant amount of memory from these guests is allocated.

Conclusion

cpuplugd automatically adapts memory size to the requirements. This simplifies systems management significantly. In case of changing requirements (for example when one guest frees memory because an application terminates while another guest raises memory requirements because an application is started), the automated memory management resulted in a lower memory footprint as compared to the manually sized setup.

CMM pools

The fact that the memory size never comes back to the level of phase 1 merits a more detailed look at the CMM pools. Figure 2 shows the Linux™ memory size calculated as defined guest size (5 GB) – CMM pool for two selected guests the combo 2 from Set 1 and combo 4 from Set 2.
Figure 2. Linux memory size calculated as defined guest size (5 GB) – CMM pool size when switching the workload from guest set 1 (lncombo2 )to guest set 2 (lncombo4)
Graph showing Linux memory size calculated as defined guest size (5 GB) – CMM pool when switching the workload from guest set 1 to guest set 2

Observations

The CMM pools grow and shrink according to the load and memory requirements of the servers. The memory sizes after the first load shift phases are very similar on both systems, and slightly higher than before.

Conclusion

The cpuplugd daemon works as expected. The fact that this is not reflected in the z/VM view is caused by a lack of real memory pressure in z/VM. There is no hard requirement from z/VM to take away the pages from the guests.

Compare the number of active guest CPUs

Figure 3 and Figure 4 compare the number of active guest CPUs over time for selected guests in the manually sized configuration with cpuplugd using configuration 2. The guests running web servers and databases, as well as the low-utilization WebSphere® Application Server, always run with 1 CPU and are omitted. The behavior of the two combo system in each guest set is very similar, therefore only one combo is shown.

Figure 3. Number of active CPUs for a WebSphere guest and a Combo guest of Set 1 over time when switching the workload from guest set 1 to guest set 2
Graph showing the number of active CPUs for a WebSphere guest and a Combo guest of Set 1 over time when switching the workload from guest set 1 to guest set 2
Figure 4. Number of active CPUs for a WebSphere guest and a Combo guest of Set 2 over time when switching the workload from guest set 1 to guest set 2
Graph showing number of active CPUs for a WebSphere guest and a Combo guest of Set 2 over time when switching the workload from guest set 1 to guest set 2

Observations

The number of CPUs exactly follows the workload load pattern. The small peaks at the start and the end are from starting and stopping the middleware. The increase from 1 to 3 CPUs happens over two intervals, adding one CPU in each step.

Conclusion

The chosen rules are very suitable to provide the system with the appropriate CPU resources while reacting very quickly to workload changes.