A few words about the real performance of the hypervisor

Users of virtualized systems, and especially - service providers, very often ask the question: "How to squeeze the most out of the available hardware?". And in this context, we often have to discuss the KVM hypervisor and the differences between different versions of Virtuozzo. In this post, we will talk about a number of tests of the latest virtualization system along with estimates of actual performance under typical loads, as well as taking into account the Meltdown and Specter patches.

What is most important for a hosting company or for an IT department who needs to organize support for the maximum number of tasks on existing equipment? If a company works on a service-oriented model or sells services, then practice shows that the main thing is an indicator of profit per server. What technologies are used at the same time and due to which density is achieved, is not so much concerned about business representatives.

However, the question of why we use KVM as a hypervisor in Virtuozzo 7, and how we differ in this case from simple OpenSource virtualization systems, is asked very often. And today I want to give an answer to it.

In the past, Virtuozzo worked with its own proprietary hypervisor, but several years ago we realized that it was more expensive and more difficult to develop than optimizing a reasonably successful and efficient KVM. However, KVM is not a benchmark for performance, and, like any OpenSource platform, requires file modification. This is part of our development department. We optimize the code, integrate it with the data storage platform and other components, thereby improving performance and density.

Comparison with other hypervisors


One of the tests we use to evaluate performance is DVD Store. It uses the classic set of server software: Linux, Apache, MySQL, PHP (LAMP). Inside each virtual machine, the test emulates an online DVD store. The result of the test is the total number of transacted sum total in all virtual machines (axis of ordinates). The number of virtual machines involved in the test increases sequentially from 1 to 100 (x-axis).

LAMP: OpenSource QEMU KVM vs Virtuozzo @ CentOS 7.4 (virtual machines)

As can be seen in the graphs above, the performance of virtual machines running CentOS Linux 7.4 running on the Virtuozzo 7 hypervisor is up to 30% higher than when running the same load on a standard KVM. The greatest difference is observed at the point of the CPU overcommit, where the total number of processor cores allocated to all virtual machines reaches the number of physical cores of the server's CPU. For this server, this point corresponds to 20 virtual machines. In addition, the core of Virtuozzo 7 and an adaptive memory management policy ensure the stable operation of virtual machines after the RAM overcommit point, where the total amount of RAM allocated to all virtual machines exceeds the size of the physical memory of the server. With such a load, the standard KVM cannot create conditions for normal operation at all.

Another comparison was made between the Virtuozzo 7 hypervisor and Microsoft Hyper-V 3.0. Here, performance was evaluated using the vConsolidate test, and Windows Server 2012 R2 was used as the guest operating system for the virtual machines.

vConsolidate: Hyper-V vs Virtuozzo @ Windows 2012 R2 (virtual machines)

image Unlike DVD Store, in vConsolidate the load is not the same for all virtual machines. In this test, they are divided into so-called CSU (Consolidation Stack Units). Each CSU is a group of four virtual machines, in which SPECjbb, WebBench and SysBench (OLTP) create a load. The fourth VM in each CSU is idle, that is, no load. The quantitative result is the geometric mean of the results of the three above-mentioned tests, obtained in total from all virtual machines (axis of ordinates). The number of CSUs involved in the test increases sequentially from 1 to 24 (abscissa axis).

For both hypervisors, the test was performed twice: with installed patches for Meltdown and Specter vulnerabilities, and also without them. An approximation of the results shows that Virtuozzo 7, on average, demonstrates 15% more performance than the Microsoft native hypervisor.

Meltdown and Specter


As you know, on January 4, 2018, the entire IT community was agitated by the discovery of large-scale conceptual vulnerabilities in all Intel processors, with the exception of Itanium and the old Atom (until 2013). Using these vulnerabilities allows any unprivileged process in the system to access the core data (Meltdown) or data from another process (Specter). Software developers have focused on the release of software updates to fix these vulnerabilities. However, users naturally had questions about how these updates affected system performance.

We checked how the patches for Meltdown and Specter affect the performance of containers with CentOS Linux 7.4 using the vConsolidate test as an example. Then we carried out another measurement - with a kernel compiled with a modified compiler with the “Retpoline” option (for example, GCC and Clang / LLVM are offered, for example).

Performance with Retpoline: vConsolidate @ CentOS 7.4 (containers)

As can be seen in the graphs above, the use of patches against Meltdown and Specter significantly reduces the performance of containers. And the most "heavy" was the patch for Specter-V2. However, using the compiler with the new option Retpoline allows you to safely abandon this patch on systems with processors older than Skylake and play as much as 25% of performance. However, we still lost about 5% due to the patches for Meltdown and Specter-V1.

Retpoline performance: vConsolidate @ CentOS 7.4 (virtual machines)


In the case of CentOS Linux 7.4 inside virtual machines, the situation looks a little more optimistic: patches for Meltdown and Specter only degrade performance by 15%, and the difference in performance of an unpatched kernel and a kernel compiled with Retpoline is only 1-2%. Thus, the use of a new compiler made it possible to almost completely compensate for the performance drop. However, it is worth considering that all three measurements were performed on the same virtual machines - with unpatched guest OS kernels. Updating guest OS will entail an additional degradation in user application performance.

Performance with Retpoline: vConsolidate @ Windows 2012 R2 (virtual machines)



The latest graph for today is a similar comparison, but now with Windows Server 2012 R2 virtual machines. Here, the slowdown from the patches was not so great and amounted to about 10%, and the use of the core with Retpoline reduced the difference to 2-3% relative to the unpatched core.

Conclusion


Of course, unmodified KVM has its advantages, and the main advantage is its free. But the tests carried out prove that private improvements and upgrades make it possible to increase the return on the infrastructure used. That is, if you need to place a maximum of containers and virtual machines, provide them with permanent storage — all on one platform and with a minimum of shaman dances — the improved KVM is much more effective, especially if the services running on the platform show good margins and bring real money. In this case, the cost of licenses and support is more than paid for in the shortest possible time.

The strength of the VZ7 remains the support of different types of VMs and containers on the same platform, and with higher performance for each category of virtual objects. However, here we can not talk about a panacea. For example, if the increase in density does not bring the organization additional finance, and its own staff may well administer and finish OpenSource solutions, then the logic inclines towards the use of open tools, including CentOS and the original KVM.

By the way, in the next post we will talk about the evolution of our distributed repository and its real capabilities for working with VMs and containers.

Source: https://habr.com/ru/post/413127/


All Articles