What’s the CPU Utilization Of Standalone SAP Central Services in a Virtual Machine?
Since VMware came out with VMware Fault Tolerance (FT) we have considered the deployment option of installing SAP Central Services in a 1 x vCPU virtual machine protected by VMware FT. FT creates a live shadow instance of a virtual machine that is always up-to-date with the primary virtual machine. In the event of a hardware outage, VMware FT automatically triggers failover—ensuring zero downtime and preventing data loss. Central Services is a single-point-of-failure in the SAP architecture that manages transaction locking and messaging across the SAP system and failure of this service results in downtime for the whole system. Hence Central Services is a strong candidate for FT but FT currently only supports 1 x vCPU (vSphere 5.x), so some guidance is required on how many users we can support in this configuration. VMware has given technical previews of multi-vCPU virtual machines protected by FT at VMworld 2013/2014, but now, better late than never, here are the results of a lab test demonstrating the performance of standalone Central Services in a 1 x vCPU virtual machine.
We configured the following setup.
We have two virtual machines: a SAP dialog instance (processes OLTP requests) and database instance in one; and Central Services in the second. The objective was to focus on performance of the standalone Central Services virtual machine that was servicing an ABAP based workload. For the ABAP stack Central Services is officially referred to as ABAP SAP Central Services (ASCS). The goal of the test was to scale up to 1000 OLTP users running transactions in the SAP Sales and Distribution module. The following metrics were measured (via vCenter): the maximum CPU usage of the ASCS virtual machine during the workload run; the maximum network usage of the ASCS virtual machine during the workload run. The following graph shows the results.
Summarizing the results:
- At 1000 users the maximum CPU utilization of the ASCS virtual machine was 29%. This is a comfortable utilization to run in production. The number of SAP lock requests (referred to by SAP as enqueues and dequeues) was over 10000 per minute during one point in the run (eyeballed via SAP transaction SM12).
- We can see a fairly linear relationship between CPU usage and the number of users.
- Lock requests generate network traffic between the SAP dialog instance and the ASCS service – we see that the network usage is fairly linear as users are scaled up. Note: there are no lock requests between the SAP database and Central Services.
It is recommended to validate SAP workloads in a pre-production performance test before go-live. Customer tests/workloads will show different results to those shown above as the frequency of SAP lock requests depends on the transaction think times and customer specific business processes (the transaction think times used in this test were < 20 seconds). Customer environments should also consider batch jobs running at the same time as OLTP activity that by design are generating a lot of locks e.g. mass update of business documents – this would create additional load on Central Services.
