Summary
In the workload used in these tests, there appears to be little difference in throughput between Vertical WebSphere® JVM stacking or Horizontal WebSphere JVM stacking.
- The lowest load was observed at 10 JVMs per guest (20 guests)
- The highest load was observed at 200 JVMs per guest (one guest)
z/VM® overhead is not a contributor to the observed higher LPAR CPU load. In spite of this, it was very impressive to see how easily z/VM was able to handle 200 guests under load. The increased load comes from Linux™, WebSphere, and Java™. The number of virtual CPUs seems to determine how many JVM threads are actively consuming CPU resources.
- In the case where the CPU load per guest is less than one CPU, it seems that the WebSphere Application Server runs more efficiently with two virtual CPUs than with one virtual CPU.
- Do not size the guest with more virtual CPUs than required for one WebSphere instance. This might limit the number of JVMs stacked in one guest, and therefore avoid a shortage in guest CPU resources.
- Running with CPU overcommitment had a lower impact. But when recommendation 1 would cause very high levels of CPU overcommitment (such as 16:1), it was found that it is better to use one virtual CPU for the WebSphere guests, instead of two.
The use of a DCSS for the WebSphere installation tree has a very low impact on throughput . But the use of a DCSS has a significant impact on CPU utilization. The additional effort related to using a DCSS makes it attractive only when the number of guests using the DCSS exceeds a certain number. This number was found to be 10 guests in the test environment. With fewer guests, the use of a shared minidisk instead of a DCSS consumes fewer CPU resources. In the case where the system runs with memory constraints, the DCSS might provide additional advantages in saving memory.
If you have large z/VM guests and questions about the use of SET REORDER for your system, contact IBM® z/VM Level 2 for further analysis and help.