Optimizing for Virtualization, Part 2
by Liz van Dijk on June 29, 2009 12:00 AM EST- Posted in
- IT Computing
Preface
We ended the first part of this article by talking about jumbo frames, having discussed some CPU considerations and general best practices for various situations.
In the meantime, the lab got the opportunity to sit down with VMware’s Scott Drummonds, who was able to provide us with some more interesting information on this subject, and a couple of our readers pointed out some of the problems they’ve been experiencing, along with the solutions. We are really happy with the overwhelmingly positive reactions we have received to Part 1, and hope Part 2 will continue to help out the people who need to work with ESX on a regular basis to get the most out of the product.
Before we dive into the more “structured” part of the article, we would like to mention a possible issue brought up by one of our readers, yknott. Apparently, IRQ sharing on certain platforms can cause a rather large performance hit in cases where the the interrupt line is used alternatively by ESX’s service console and the VMkernel. The service console is the actual console that can be logged into when an administrator wants to check out for example esxtop, and can as such take control of certain devices to perform its tasks. The problem seems to occur when both the VMkernel and the service console have control over the same device, which is something that can be checked for when displaying the /proc/vmware/interrupts file, as documented in this article of the VMware knowledge base.
Facebook
Twitter
RSS
13 Comments
View All Comments
zdzichu - Tuesday, June 30, 2009 - link
True, for for quite some time Linux is tickless and doesn't generate uneeded timer interrupts. This change went into 2.6.21, which was released TWO YEARS ago. http://kernelnewbies.org/Linux_2_6_21#head-8547911...">http://kernelnewbies.org/Linux_2_6_21#h...47911895...yknott - Tuesday, June 30, 2009 - link
Technically Linux is NOT tickless, dynaticks only mean that when there are no interrupts occurring and the cpu is idle, there are no timer interrupts fired. When the CPU is in use, tick interrupts are still fired at 1000hz.To your point, this is still a huge advantage when it comes to virtualization. Most of the time CPUs are idle and not having the underlying VM hypervisor process ticks from each VM that is idle will allow for more processing power for the VMs who DO need the CPU time.
I also agree that RedHat definitely needs to keep up with the kernel patches. I understand that there is some lag due to regression testing etc, but two years seems a bit much.
yknott - Monday, June 29, 2009 - link
Thornburg,I think what Liz was talking about has to do with the tick interrupt under Linux. Since the 2.6.x kernel, this was set to a default of 1000hz or 1000 times a second.
I don't believe you shouldn't use linux, as you can change this tick rate either in the kernel or at boot time. For example, under RHEL 5, just set divider=10 in your boot options to get a 100hz tick rate.
You can read more about this on VMware's timekeeping article here: http://www.vmware.com/pdf/vmware_timekeeping.pdf">http://www.vmware.com/pdf/vmware_timekeeping.pdf
Checkout page 11/12 for more info.
Liz, while that paragraph makes sense, perhaps it doesnt tell the whole story about tick rate and interrupts under vmware. While I agree that running at a lower tickrate is ideal, perhaps mentioning that the interrupt rate is adjustable on most OSes.