SAP Solutions on VMware
Best Practices Guide
© 2011 VMware, Inc. All rights reserved.
Page 9 of 32
Note that vSphere 5 introduces two new memory reclamation techniques to allow users to overcommit
host memory (see Understanding Memory Management in VMware vSphere 5 at
). Memory compression reduces the number of
host-swapped pages by storing the compressed format of the pages in a per-VM memory compression
SSD leverages SSD’s low read latency to alleviate the host swapping penalty
these two new techniques can help to reduce the performance impact in memory overcommit scenarios,
the above guidelines not to overcommit memory for SAP production virtual machines still stands.
To minimize guest operating system swapping, the configured memory size of the virtual machine should
be greater than the average memory usage of the SAP application running in the guest. If the SAP
application in the virtual machine needs more memory than it has been allocated, the guest operating
system paging/swapping mechanisms are invoked.
Memory and swap/page file configuration of the SAP application in the virtual machine follow the same
guidelines as for native environments, and generally, you should set them to minimize guest operating
system swapping. Follow existing SAP documentation and recommendations as provided in these SAP
Zero Administration Memory Management as of 4.0A/Windows.
abap/heap_area* parameter Defaults Changed (64-Bit Windows).
Java virtual machine settings for J2EE 6.40/7.0.
SAP memory management for 64-bit Linux systems (or: STD memory model).
386605 -- SAP memory management for 32-bit Linux systems (or: MAP memory model).
5.2 Virtual CPU
VMware uses the terms virtual CPU (vCPU) and physical CPU to distinguish between the processors
within the virtual machine and the underlying physical x86-based processors. Virtual machines with more
than one virtual CPU are also called SMP (symmetric multiprocessing) virtual machines.
VMware Virtual Symmetric MultiProcessing (Virtual SMP) enhances virtual machine performance by
enabling a single virtual machine to use multiple physical processors simultaneously. vSphere supports
use of up to 32 virtual CPUs per virtual machine. The biggest advantage of an SMP system is the ability
to use multiple processors to execute multiple tasks concurrently, thereby increasing throughput (for
example, the number of transactions per second). Only workloads that support parallelization (including
multiple processes or multiple threads that can run in parallel) can really benefit from SMP. The SAP
architecture is multithreaded (NetWeaver JAVA stack) and includes multiple processes (NetWeaver
ABAP stack comprises multiple ―disp+work‖ C processes) which m
akes it a good candidate to take
advantage of Virtual SMP.
In the latest versions of ESX/ESXi, the CPU scheduler has undergone several improvements to provide
better performance and scalability; for details, see the paper VMware vSphere: The CPU Scheduler in
VMware ESX 4.1. For example, the relaxed co-scheduling algorithm was refined so that scheduling
constraints due to co-scheduling requirements are further reduced. These improvements have resulted in
better scalability and performance of SAP workloads, as described in Section 8
Consequently, in vSphere, the larger 4-way and 8-way virtual machines exhibit great scalability,
so that running multiple smaller 2-way virtual machines for better performance is not required as
recommended with ESX/ESXi 3 versions.
While larger virtual machines are possible in vSphere, VMware recommends reducing the number of
virtual CPUs if monitoring of the actual workload shows that the SAP application is not benefitting from
the increased virtual CPUs. For more background, please see the ―ESX
CPU Considerations‖ section in
the whitepaper Performance Best Practices for VMware vSphere 5.