CPU load analysis

The CPU load is analyzed for the system types: Systems of interest, standby systems, and base load systems. Idling guests are used.

For more information about the guest systems and their types, see Guest usage.

Figure 1 shows the real CPU utilization for the Systems of interest, measured in Integrated Facility for Linux™ (IFL), to demonstrate the workflow of the test.
Figure 1. Real CPU utilization
This figure contains three graphs, from top to bottom. Top: Graph of the real CPU utilization for the Systems of interest, measured in IFLs. The x-axis is the time measured in h:mm:ss, ranging from 0:00:00 to 0:35:00. The y-axis is the number of IFLs, ranging from 0 to 1.2. There are four lines on the graph, representing the systems with these names: LNX00102, LNX00104, LNX00105, and LNX00107. From time 0:00:00 to 0:09:40, all the lines are between 0.7 and 1.0 IFLs. The line for LNX00107 is nearly at 1.0 IFL for this entire time span. The lines for the other three systems fluctuate between 0.7 and 1.0 IFLs with no particular pattern. At time 0:09:40, all lines drop rapidly to 0.00 IFLs and stay that way until time 0:23:40. At that time, all lines rise rapidly to their former levels and look the same as they did in the beginning. At time 0:34:00, all lines drop rapidly to 0 IFLs. Middle: Graph of the real CPU utilization for the standby systems, measured in IFLs. The x-axis is the time measured in h:mm:ss, ranging from 0:00:00 to 0:35:00. The y-axis is the number of IFLs, ranging from 0 to 1.2. There are four lines on the graph, representing the systems with these names: LNX00106, LNX00108, LNX00109, and LNX00111. From time 0:00:00 to 0:09:40, all the lines are are 0 IFLs. At time 0:10:00, LNX0109 peaks sharply to 9.9 IFLs. At this same time, the others have a much smaller peak, less than 0.2 IFLs. After this peak, all lines go back to 0 IFLs, until time 0:12:40. At that time, all four lines rise rapidly to values slightly smaller than 1.0 IFLs. Between 0:12:40 and 0:24:40, the line for system LNX0111 remains a constant at 1.0 IFLs, and the other three fluctuate with not particular pattern between 0.7 and 1.0 IFLs. At time 0:24:40, all lines drop rapidly to 0 IFLs and stay that way for the rest of the time. Bottom: Graph of the real CPU utilization for the base load systems, measured in IFLs. The x-axis is the time measured in h:mm:ss, ranging from 0:00:00 to 0:35:00. The y-axis is the number of IFLs, ranging from 0 to 1.2. There are two lines on the graph, representing the systems with these names: LNX00100, and LNX00103. The line for LNX00100 starts at time 0:00:00 at 0.96 IFLs and fluctuates in no particular pattern between 0.8 and 1.0 IFLs until time 0:10:20, where it rapidly decreases to 0 IFLs. It stays at 0 IFLs until time 0:13:40, when it rapidly rises to 0.9 IFLs. It fluctuates between 0.78 and 1.0 IFLs with no particular pattern until time 0:18:00, where there is a steep and short-lived dip to 0.5 IFL. There is also a steep and short-lived dip to 0.6 IFLs at time 0:24:00. The line quickly rises again and fluctuates between 0.7 and 1.0 IFLs until time 0:34:00, where it drops to 0 IFLs and stays that way until the end of the test. The line for LNX00103 starts at time 0:00:00 at 1.0 IFLs and remains that way until time 0:10:20, where it rapidly decreases to 0 IFLs. It stays at 0 IFLs until time 0:13:40, when it rapidly rises to 1.0 IFLs. It stays at 1.0 IFLs until time 0:24:00, where there is a steep and short-lived dip to 0.1 IFL. The line quickly rises to 1.0 IFLs again and remains at that value until time 0:34:00, where it drops to 0 IFLs and stays that way until the end of the test.
Warmup phase:
  • The Systems of interest guests are under load to get warmed up (each system has one virtual CPU that is fully utilized). The memory pages of these guests should reside in central storage.
  • The standby systems are up, the servers are not started, but the node agent from the WebSphere® cluster is started. The expectation is that these guests have only a very small amount of memory pages allocated.
  • The base load systems are under workload. The memory pages of these guests should reside also in central storage. The z/VM® is sized such that there is space for the base load and the Systems of interest.
End of warmup phase:
  • Workload assigned to the Systems of interest is stopped and the systems are suspended.
  • The CPU peak at the standby systems appear only on the WebSphere guests, and is related to the cluster recovery, because the two WebSphere Application Servers from the Systems of interest no longer interact.
  • A workload pause is introduced to let the z/VM stabilize any page migration activity. This means especially that the Systems of interest should change to the dormant state.
Systems of interest suspended:
  • The servers of the standby guests are started and workload is issued against them to create memory pressure. In that phase the pages from the System of interest should be migrated to the paging space and the quantity of pages for the standby guests in central storage should increase.
Systems of interest resumed:
  • Now the workload against the standby systems is stopped and the guests are suspended. They should become dormant.
  • The Systems of interest guests are resumed and workload is assigned to them, which means their memory pages should be migrated back from paging space to central storage, forcing the pages of the dormant standby system to become migrated to the paging space.
  • The base load systems continue processing under workload. The memory pages of these guests should still reside in central storage.