Home > Blogs > VMware VROOM! Blog

Performance Best Practices Guide for vSphere 7.0

1 Reply

We are pleased to announce the availability of Performance Best Practices for VMware vSphere 7.0. This is a comprehensive book designed to help system administrators obtain the best performance from their vSphere 7.0 deployments.

The book covers new features as well as updating and expanding on topics covered in previous versions.

These topics include:
  • Persistent memory (PMem), including using PMem with NUMA and vNUMA
  • Getting the best performance from NVMe and NVME-oF storage
  • AMD EPYC processor NUMA settings
  • Distributed Resource Scheduler (DRS) 2.0
  • Automatic space reclamation (UNMAP)
  • Host-Wide performance tuning (aka, “dense mode”)
  • Power management settings
  • Hardware-assisted virtualization
  • Storage hardware considerations
  • Network hardware considerations
  • Memory page sharing
  • Getting the best performance from iSCSI and NFS storage
  • vSphere virtual machine encryption recommendations
  • Running storage latency-sensitive workloads
  • Running network latency-sensitive workloads
  • Network I/O Control (NetIOC)
  • DirectPath I/O
  • Microsoft Virtualization-Based Security (VBS)
  • Selecting virtual network adapters
  • vCenter database considerations
  • The vSphere HTML5 Client
  • VMware vSphere Lifecycle Manager
  • VMware vSAN performance
The book can be found here.

 

AMD 2nd Gen EPYC (Rome) Application Performance on vSphere Series: Part 2 – VMmark

Leave a reply

In recently published benchmarks with VMware VMmark, we’ve seen lots of great results with the AMD EPYC 7002 Series (known as 2nd Gen EPYC, or “Rome”) by several of our partners. These results show how well a mixed workload environment with many virtual machines and infrastructure operations like vMotion can perform with new server platforms.

This is the second part of our series covering application performance on VMware vSphere running with AMD 2nd Gen EPYC processors (also see Part 1 of this series). This post focuses on the VMmark benchmark used as an application workload.

We used the following hardware and software in our testbed:

  • AMD 2nd Gen EPYC processors (“Rome”)
  • Dell EMC XtremIO all-flash array
  • VMware vSphere 6.7 U3
  • VMware VMmark 3.1

VMmark

VMmark is a benchmark widely used to study virtualization performance. Many VMware partners have used this benchmark—from the initial release of VMmark 1.0 in 2006, up to the current release of VMmark 3.1 in 2019—to publish official results that you can find on the VMmark 3.x results site. This long history and large set of results can give you an understanding of performance on platforms you’re considering using in your datacenters. AMD EPYC 7002–based systems have done well and, in some cases, have established leadership results. At the publishing of this blog, VMmark results on AMD EPYC 7002 have been published by HPE, Dell | EMC, and Lenovo.

If you look though the details of these published results, you can find some interesting information like disclosed configuration options or settings that might provide performance improvements to your environment. For example, in the details of a Dell |EMC result, you can find that the server BIOS setting Numa Nodes Per Socket (NPS) was set to 4. And in the HPE submission, you can find that the server BIOS setting Last Level Cache (LLC) as NUMA Node was set to enabled. This is also referred to as CCX as NUMA because each CCX has its own LLC. (CCX is described in the following section.)

We put together a VMmark test setup using AMD EPYC Rome 2-socket servers to evaluate performance of these systems internally. This gave us the opportunity to see how the NPS and CCX as NUMA BIOS settings affected performance for this workload.

In the initial post of this series, we looked at the effect of the NPS BIOS settings on a database-specific workload and described the specifics of those settings. We also provided a brief overview and links to additional related resources. This post builds on that one, so we highly recommend reading the earlier post if you’re not already familiar with the BIOS NPS settings and the details for the AMD EPYC 7002 series.

AMD EPYC CCX as NUMA

Each EPYC processor is made up of up to 8 Core Complex Dies (CCDs) that are connected by AMD’s Infinity fabric (figure 1). Inside each CCD, there are two Core Complexes (CCXs) that each have their own LLC cache shown as 16M L3 cache in figure 2. These diagrams (the same ones from the previous blog post) are helpful in illustrating these aspects of the chips.

Figure 1. Logical diagram of AMD EPYC Rome processor

Figure 2. Logical diagram of CCX

The CCX as NUMA or LLC as NUMA BIOS settings can be configured on most of the AMD EPYC 7002 Series processor–based servers. The specific name of the setting will be slightly different for different server vendors. When enabled, the server will present the four cores that share each L3 cache as a NUMA node. In the case of the EPYC 7742 (Rome) processors used in our testing, there are 8 CCDs that each have 2 CCXs for a total 16 CCXs per processor. With CCX as NUMA enabled, each processor is presented as 16 NUMA nodes, with 32 NUMA nodes total for our 2-socket server. This is quite different from the default setting of 1 NUMA node per socket for a total of 2 NUMA nodes for the host.

This setting has some potential to improve performance by exposing the architecture of the processors as individual NUMA nodes, and one of the VMmark result details indicated that it might have been a factor in improving the performance for the benchmark.

VMmark 3 Testing

For this performance study, we used as the basis for all tests:

  • Two 2-socket systems with AMD EPYC 7742 processors and 1 TB of memory
  • 1 Dell EMC XtremIO all-flash array
  • VMware vSphere 6.7 U3 installed on a local NVMe disk
  • VMmark 3.1—we ran all tests with 14 VMmark tiles: that’s the maximum number of tiles that the default configuration could handle without failing quality of service (QoS). For more information about tiles, see “Unique Tile-Based Implementation” on the VMmark product page.

We tested the default cases first: CCX as NUMA disabled and Numa Per Socket (NPS) set to 1. We then tested the configurations of NPS 2 and 4, both with and without CCX as NUMA enabled.  Figure 3 below shows the results with the VMmark score and the average host CPU utilization.  VMmark scores are reported relative to the score achieved by the default settings of NPS 1 and CCX as NUMA disabled.

From a high level, the VMmark score and the overall performance of the benchmark does not change a large amount across all of the test cases. These fall within the 1-2% run-to-run variation we see with this benchmark and can be considered equivalent scores. We saw the lowest results with NPS 2 and NPS 4 settings. These results showed 3% and 5% reductions respectively, indicating that those settings don’t give good performance in our environment.

Figure 3. VMmark 3 performance on AMD 2nd Gen EPYC with NPS and CCX as NUMA Settings

We observed one clear trend in the results: a lower CPU utilization in the 6% to 8% range with CCX as NUMA enabled.  This shows that there are some small efficiency gains with CCX as NUMA in our test environment. We didn’t see a significant improvement in overall performance due to these efficiency gains; however, this might allow an additional tile to run on the cluster (we didn’t test this).  While some small gains in efficiency are possible with these settings, we don’t recommend moving away from the default settings for general-purpose, mixed-workload environments.  Instead, you should evaluate these advanced settings for specific applications before using them.

AMD EPYC Rome Application Performance on vSphere Series: Part 1 – SQL Server 2019

Leave a reply

Exciting new server platforms based on the second generation of AMD EPYC processors (Rome) have become recently available from many of our hardware partners. The new Rome processors offer up to 64 cores per socket—that’s a big increase over the previous generation of AMD processors. This means that a two-socket server using these processors has 128 cores and 256 logical threads with simultaneous multi-threading (SMT) enabled, making two-socket servers look more like four-socket servers in terms of core counts.

This is the first blog in a series that will take at look at the performance of some different workloads on the AMD EPYC Rome processor on VMware vSphere. Today we’re giving you the results of our tests on Microsoft SQL Server 2019.

The AMD EPYC Rome processor is built with Core Complex Dies (CCDs) connected via Infinity Fabric. In total, there are up to eight CCDs in the EPYC 7002 processor (Rome), as shown in figure 1.

Figure 1. Logical diagram of AMD EPYC Rome processor

Two Core Complexes (CCXs) comprise each CCD.  A CCX is up to four cores sharing an L3 cache, as shown in this additional logical diagram from AMD for a CCD, where the orange line separates the two CCXs.

Figure 2. Logical diagram of CCD

The AMD EPYC 7002 series processors in some ways simplify the architecture for many applications, including virtualized and private cloud deployment. There are more details on the EPYC Rome processor as well as a comparison to the previous generation AMD EPYC processors in a great article written by Anandtech.

AMD EPYC 7002 series (Rome) server processors are fully supported for vSphere 6.5 U3, vSphere 6.7 U3, and vSphere 7.0.  For all tests in this blog, vSphere 6.7 U3 was used.

The server used for testing here was a two-socket system with AMD EPYC 7742 processors and 1 TB of memory. Storage was an all flash ExtremeIO Fibre Channel array with a 4TB LUN assigned to the test system. vSphere 6.7 U3 was installed on a local NVMe disk and used as the basis for all tests.

Testing with SQL Server 2019

Microsoft SQL Server 2019 is the current version of this popular relational database.  It’s widely used by VMware customers and is one of the most commonly used applications on the vSphere platform. It’s a good application to test the performance of both large- and medium-sized virtual machines.

For the test, we used the SQL Server workload of the DVD Store 3 benchmark. It’s an open-source online transaction processing (OLTP) workload that simulates an online store.  It uses many common database features such as indexes, foreign keys, stored procedures, and transactions.  The workload is measured in terms of orders per minute (OPM), where each order is made up of logging in, browsing the store, reading and rating reviews, adding items to the shopping cart, and purchasing them.

For all tests, the number of worker threads that simulated users were increased in successive test runs until the maximum OPM was achieved and then began to decline, or stay the same, as additional threads are added.  At this point, CPU utilization was between 90 and 100 percent.

We created a Windows Server 2019 VM and installed SQL Server 2019 on it.  For the later tests this VM was cloned multiple times to be able to quickly scale-out the test setup.

Scale Up Performance of a Monster VM

With such a large number of cores available, it was natural to test how much performance was possible when scaling up to the maximum size of vCPUs per VM (a Monster VM). We configured the scaled up VM with 512 GB of RAM and a DVD Store test database of about 400GB.

We compared the maximum throughput for 64 and 128 vCPU VMs and found good scalability. The 128 vCPU VM achieved 1.86 times the throughput of the 64 vCPU VM.  This small fall off in scalability is due to the additional NUMA node, which results in some increased latency. Additionally, the sheer number of cores involved in such large systems caused slightly higher overhead to manage for the vSphere scheduler.

Figure 3. Scale-up performance from 64 vCPUs to 128 vCPUs for a single VM.

 

Scale-Out Performance of Multiple VMs

To test the scale-out performance of a vSphere environment, we cloned the SQL Server 2019 VM until we had eight.  We configured each VM to have 16 vCPUs with 128 GB of RAM.  This allowed us to have a maximum number of active vCPUs in the test to be equal to the 128 cores in the server.  Additionally, we configured the size of the DVD Store test database to be about 100GB.  We did this to scale the workload to the size of the VM.

The results below show that the total throughput continues to increase as the number of VMs is increased to eight.  In total, the eight VMs were able to produce slightly over 6x what a single VM could achieve.

Figure 4. As we scaled out the 16-vCPU VM from 1 to 2, 4, and 8 VMs, we observed the eight VMs were able to produce slightly over 6x what a single VM could achieve.

Optimizing Performance Opportunities with AMD EPYC Rome

As mentioned at the beginning of this post, AMD EPYC Rome processors used in this test are made up of eight CCD modules, each with 8 cores.  Within each CCD there are two CCXs that share an L3 processor cache. Each CCD has an associated memory controller.  With default settings, all eight CCDs and their memory controllers act as one NUMA node with memory access interleaved across all memory controllers.

There is an option in the BIOS settings to partition the processor into multiple NUMA domains per socket.  This partitioning is based on grouping the CCDs and their associated memory controllers.  The option is referred to as NUMA per socket or NPS, and the default is 1.  This means that there is one NUMA node per socket.  The other options are to configure it to 2 or 4.  In the case where NPS is set to 4, there are 4 NUMA nodes per socket, with each NUMA node having 2 CCDs and their associated memory.

If the VM sizes allow for them to align with the NPS setting in terms of cores and memory, then there is the opportunity for performance gains with some workloads.  In the specific case of our scale-out performance testing that we looked at above, there were 8 SQL Server VMs with 16 vCPUs and 128 GB of RAM each.  This lines up with an NPS 4 setting – 1 VM per NUMA node with 16 vCPUs matching 16 cores per NUMA node.  Additionally, there is 128 GB of RAM for each VM as well as 128 GB of RAM in each NPS 4–based NUMA node for our system with 1TB of RAM.

When tested, this configuration of VMs with such nice alignment resulted in a 7.8% gain in throughput for the NPS 4 setting over the default of NPS 1.  NPS 2 showed only a negligible gain of 1%.

Figure 5. Because of good alignment, the NPS 4 setting gained 7.8% in throughput over the NPS 1 setting, compared to the NPS 2 setting, which showed only a 1% performance improvement.

It is important to note that not all workloads and VMs will gain 8% or even any performance just by using the NPS 4 setting.  The performance gain in this case is due to the clean alignment of the VMs with NPS 4. Compared to NPS 1, where multiple VMs were probably not confined across their own set of caches and were stepping on other VM’s cache usage.  In this specific scenario with NPS 4, each VM basically has its own NUMA node with its own set of L3 processor caches and lower memory latency due to the interleaving across only the local memory for the CCDs being used.  In circumstances where VM size is uniform and nicely aligns with one of these NPS settings, it is possible to obtain some modest performance gains.  Please use these settings with caution and test their effect before using them in production.

 

 

New White Paper: Optimize Virtualized Deep Learning Performance with New Intel Architectures

Leave a reply

By Dave Jaffe, VMware Performance Engineering and Padma Apparao, Intel – VMware Center of
Excellence

A new white paper is available showing the advantages of running deep learning image classification on the 2nd Generation Intel Xeon Scalable processor compared to previous Intel processors, and to show the performance benefits of running on the VMware vSphere hypervisor compared to bare metal.

The 2nd Generation Intel Xeon Scalable processor’s Deep Learning Boost technology includes new Vector Neural Network Instructions (VNNI), which are especially performant with input data expressed as an 8-bit integer (int8) rather than a 32-bit floating point number (fp32). Together with the large VNNI registers, these instructions provide a marked performance improvement in image classification over the previous generation of Intel Xeon Scalable processors.

The latest version of vSphere, 7.0, supports the VNNI instructions. The work reported in this paper demonstrates a very small virtualization overhead for single image inferencing but major performance advantages for properly configured virtualized servers compared to the same servers running as bare metal.

Continue reading →

ESXi NFS Read Performance: TCP Interaction between Slow Start and Delayed Acknowledgement

Leave a reply

VMware performance engineers observed, under certain conditions, that ESXi IO (in versions 6.x and 7.0) with some NFS servers experienced unexpectedly low read throughput in the presence of extremely low packet loss, due to an undesirable TCP interaction between the ESXi host and the NFS server. We have published a performance case study, ESXi NFS Read Performance: TCP Interaction between Slow Start and Delayed Acknowledgement which analyzes this undesirable interaction in detail.

In this paper, we explain how this TCP interaction leads to poor ESXi NFS read performance, describe ways to determine whether this interaction is occurring in an environment, and present a workaround for ESXi 7.0 that could improve performance significantly when this interaction is detected. In our experiments with ESXi NFS read traffic from an NFS datastore, a seemingly minor 0.02% packet loss resulted in an unexpected 35% decrease in NFS read throughput.

A key lesson of this paper is that seemingly minor packet loss rates could have an outsized impact on the overall performance of ESXi networked storage. We recommend customers who are using ESXi networked storage and have highly performance-sensitive workloads to consider taking steps to identify and mitigate these undesirable interactions if appropriate.

Weathervane 2.0: An Application-Level Performance Benchmark for Kubernetes

Leave a reply

Weathervane 2.0 lets you evaluate and compare the performance characteristics of on-premises and cloud-based Kubernetes clusters.

Kubernetes simplifies the deployment and management of applications on a wide range of infrastructure solutions. One cost of this simplification is a new set of decisions that you must make when acquiring or configuring Kubernetes clusters, including selecting the underlying infrastructure, configuring network and storage layers, sizing compute nodes, etc. Each choice can impact the performance of applications deployed on the cluster. Weathervane 2.0 helps you understand this impact, by:

  • Comparing the performance of Kubernetes clusters
  • Evaluating the impact of configuration decisions on cluster performance
  • Validating a new cluster before putting it into production

When using Weathervane, you only need to build a set of container images, edit a configuration file, and start the benchmark. Weathervane manages the deployment, execution, and tear-down of all benchmark components on your Kubernetes cluster.

Weathervane 2.0 is available at https://github.com/vmware/weathervane.

Continue reading →

VMware vSGA for Content-Rich VDI

7 Replies

vSGA, or Virtual Shared Graphics Acceleration, allows multiple VMware vSphere virtual machines to share hardware GPUs. We have advocated in previous blog articles the use of NVIDIA GRID vGPU technology, and this is a good solution for many use cases. In this blog, we look at the performance of vGPU technology vs. vSGA while limiting our testing to a workload generated by VMware Horizon 7 VDI desktops. Based on our measurements (we present some of that data in this blog) vSGA provides performance very close to vGPU when using a variety of software applications, including Microsoft Office, Adobe Acrobat, CAD viewers, YouTube video, and viewing or working with WebGL-based images.

Continue reading →

CPU Hot Add Performance in vSphere 6.7

4 Replies

Leaving CPU Hot Add at its default setting of disabled is one of the performance best practices that we have for large VMs. From the Performance Best Practices Guide for vSphere 6.7 U2:

CPU Hot Add is a feature that allows the addition of vCPUs to a running virtual machine. Enabling this feature, however, disables vNUMA for that virtual machine, resulting in the guest OS seeing a single vNUMA node. Without vNUMA support, the guest OS has no knowledge of the CPU and memory virtual topology of the ESXi host. This in turn could result in the guest OS making sub-optimal scheduling decisions, leading to reduced performance for applications running in large virtual machines. For this reason, enable CPU Hot Add only if you expect to use it. Alternatively, plan to power down the virtual machine before adding vCPUs, or configure the virtual machine with the maximum number of vCPUs that might be needed by the workload. If choosing the latter option, note that unused vCPUs incur a small amount of unnecessary overhead. Unused vCPUs could also cause the guest OS to make poor scheduling decisions within the virtual machine, again with the potential for reduced performance. For additional information see VMware KB article 2040375.

The reason for this is that if you enable CPU Hot Add, virtual NUMA is disabled. This means that the VM is not aware of which of its vCPUs are on the same NUMA node and might increase remote memory access. This removes the ability for the guest OS and applications to optimize based on NUMA and results in a possible reduction in performance.

Virtual NUMA (vNUMA) exposes NUMA topology to the guest operating system, allowing NUMA-aware guest operating systems and applications to make the most efficient use of the underlying hardware’s NUMA architecture. (For more information about NUMA, see page 27 in the Performance Best Practices Guide for vSphere 6.7 U2.)

To get an idea of what the performance impact can be by enabling CPU Hot Add, a simple test was run in our lab environment. This test found performance with the default setting of CPU Hot Add disabled performed from 2% to 8% better than when CPU Hot Add was enabled.

Continue reading →

New White Paper: High-Performance Virtualized Spark Clusters on Kubernetes for Deep Learning

1 Reply

By Dave Jaffe, VMware Performance Engineering

A new white paper is available showing the advantages of running virtualized Spark Deep Learning workloads on Kubernetes.

Recent versions of Spark include support for Kubernetes. For Spark on Kubernetes, the Kubernetes scheduler provides the cluster manager capability provided by Yet Another Resource Negotiator (YARN) in typical Spark on Hadoop clusters. Upon receiving a spark-submit command to start an application, Kubernetes instantiates the requested number of Spark executor pods, each with one or more Spark executors.

The benefits of running Spark on Kubernetes are many: ease of deployment, resource sharing, simplifying the coordination between developer and cluster administrator, and enhanced security. A standalone Spark cluster on vSphere virtual machines running in the same configuration as a Kubernetes-managed Spark cluster on vSphere virtual machines were compared for performance using a heavy workload, and the difference imposed by Kubernetes was found to be insignificant.

Spark applications running in Standalone mode require that every Spark worker node be installed with the correct version of Spark, Python, Java, etc. This puts a burden on the IT administrator, who may be managing many Spark applications with different requirements, and it requires coordination between the administrator and the application developer. With Kubernetes, the developer only needs to create a container with the correct software, and the IT administrator just needs to manage the cluster using the fine-grained resource management tools to enable the different Spark workloads.

To compare Spark Standalone performance to Spark on Kubernetes performance, a Deep Learning workload, the Maximum Throughput Spark BigDL ResNet50 image classifier from VMware IoT Analytics Benchmark, was run on the same 16 worker nodes, first while configured as Spark worker nodes, then while configured as Kubernetes nodes. Then the number of nodes was reduced by four (by removing the four workers on host 4), and the same comparison was made using 12 nodes, then 8, then 4.

The relative results are shown below. The Spark Standalone and Spark on Kubernetes performance in terms of images per second classified was within ~1% of each other for all configurations. Performance scaled well for the Spark tests as the number of VMs increased from 4 (1 server) to 16 (4 servers).

All details are in the paper.

How Does Project Pacific Deliver 8% Better Performance Than Bare Metal?

Leave a reply

By Karthik Ganesan and Jared Rosoff 

At VMworld US 2019, VMware announced Project Pacific, an evolution of vSphere into a Kubernetes-native platform. Project Pacific (among other things) introduces a vSphere Supervisor Cluster, which enables you to run Kubernetes pods natively on ESXi (called vSphere Native Pods) with the same level of isolation as virtual machines. At VMworld, we claimed  that vSphere Native Pods running on Project Pacific, isolated by the hypervisor, can achieve up to 8% better performance than pods on a bare-metal Linux Kubernetes node. While it may sound a bit counter-intuitive that virtualized performance is better than bare metal, let’s take a deeper look to understand how this is possible.

Why are vSphere Native Pods faster?

This benefit primarily comes from ESXi doing a better job at scheduling the natively run pods on the right CPUs, thus providing better localization to dramatically reduce the number of remote memory accesses. The ESXi CPU scheduler knows that these pods are independent entities and takes great efforts to ensure their memory accesses are within their respective local NUMA (non-uniform memory access) domain. This results in better performance for the workloads running inside these pods and higher overall CPU efficiency. On the other hand, the process scheduler in Linux may not provide the same level of isolation across NUMA domains.

Continue reading →

login