Conclusion

Optimizing a workload for use with virtualization is no easy task, and quite often requires an IT admin to dive deep into the workings of their applications, as these can significantly impact their performance under ESX. On one side, it makes the job of today’s IT admins a lot more interesting than those of 10 years ago, on the other hand, it is all the more important to make a difference by keeping all that knowledge up to date. By implementing solid optimization practices, it is not just possible to squeeze those extra percent that make the difference out of a platform, but also to gain a strategic advantage in the harshness of today’s job climate.

The objective of this article was not to provide a tuning solution for every problem, but to share some of the pitfalls Anandtech IT and the Sizing Servers Lab have encountered in their experiences with VMware’s ESX, along with some solid advice provided by VMware themselves at VMworld Europe 2009.

This very moment, the team is working on similar in-depth research into Hyper-V and Xen, learning more as we move along and pit these solutions against each other, using our vApus Mark I workloads to test both the strengths and weaknesses of each platform. We hope you are looking forward to our hypervisor comparison; we definitely are.

"Magic" memory!
Comments Locked

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.

Log in

Don't have an account? Sign up now