Consolidation amplifies the uncertainty of application performance. Still, VI administrators need a means of guaranteeing performance SLAs to their applications’ users. But the best VMware has been able to offer are resource controls, which are at best an indirect mechanism for sustaining application performance. With the acquisition of B-hive, now AppSpeed, VMware moved a step closer to allowing VI administrators to guarantee a performance SLA. As an application-aware latency measurement tool, AppSpeed may eventually provide feedback to vCenter to guarantee throughput levels. But it does not today. So how are VI administrators to guarantee application performance?
Designing VMs with Performance SLAs
vSphere 4.1: Performance Improvements
Last week I took my first vacation in a year and a half. I had not missed a single day of work in 18 months. So last week, when I was galavanting through Spain and running terrified, screaming, and covered in sangria through the streets of Pamplona, VMware made its biggest announcement in over a year: the launch of vSphere 4.1. My old team put out what looks to be a wonderful “What’s New in Performance” paper so I want to take a few minutes to add my thoughts to some of the great work VMware has done.
Hyper-V's Lack of Memory Over-commit
I find it interesting that one day after I wrote about memory over-commitment in vSphere, Greg Shields wrote about the lack of memory over-commitment in Hyper-V. In today’s short blog entry, I want provide one paragraph that Greg’s article currently lacks:
While memory over-subscription is a critical feature for production environments, balancing the demands of heterogenous applications of varying demands in a resource starved environment is difficult. Without guidance from administrators on the relative importance of the virtual machines running these applications, a hypervisor will be forced to make arbitrary decisions in assigning limited resources. Effective use of over-commitment requires a sound resource control system. The only product on the market that does this well is VMware vSphere.
Both Greg and my articles only talked of memory over-commitment, but the rules apply for CPU over-commitment, too. Microsoft will realize how important resource controls are somewhere between year two and five of their product’s life. I can only imagine where vSphere will be by then.
Memory Reservations Drive Over-commit
Many of VMware’s customers use memory reservations during troubleshooting only in a final attempt to fix performance problems. It is true that memory reservations can limit ballooning and host swapping. But if you are only using reservations to anticipate and avoid memory bottlenecks, you are missing one of the great uses of the feature: memory reservations can drive over-commitment.
Memory Compression
Steve Herrod’s keynote at Partner Exchange 2010 included a tantalizing slide on an upcoming memory maximization technology: memory compression. A few of you have already seen the overview of this technology Kit Colbert and Fei Guo previewed it at VMworld 2009. Today I want to tell you how this upcoming feature will help you pack even more virtual machines onto your existing servers.
Optimizing Memory Utilization
My recent series of blog articles have discussed ESX memory management the the performance specter of host swapping. My last article attempts to correct the misconception that VMware recommends against over-commit memory. In that article I suggested that memory over-commit is requirement in optimizing memory utilization. Today I want to provide a specific example to show why this is true. I am have also included tips for identifying host swapping in your environments.
Read the rest of this entry »
Misunderstanding Memory Management
Twice in 2009 someone showed me competitive literature from Microsoft or Citrix claiming that VMware recommends against memory over-commitment. Given the wide variety of literature we have provided in support of this feature, all of our customers recognize the absurdity of our competitions’ claims. VMware and its customers love memory over-commitment. Then where is the source of this misinformed guidance?
Solid State Disks and Host Swapping
Recently I have been thinking, talking, and writing about ESX host memory swapping a lot. ESX swaps memory under the same conditions that traditional operating systems do; the application(s) is using more memory than available on the physical hardware. Host swapping is an unavoidable consequence of this condition, whether virtualization is present or not.
Your Performance Enemy: Host Swapping
Three times in the past week I have engaged in challenging discussions on host memory swapping and its impact to performance. If you read my article on host swapping and the whitepaper it summarized, you know the deleterious effect on performance caused by host swapping. When reading the paper, one of our most astute customers saw a sentence that gave him pause:
Read the rest of this entry »
ESX Memory Management: Ballooning Rules
[Taken from my communities blog, this article shows you why you should "Love Your Balloon Driver".]
Earlier this month we finally published one of my favorite papers from ongoing vSphere launch activities. This paper on ESX memory management, written by Fei Guo of performance engineering, has three graphs that are absolute gems. They show balloon driver memory savings next to throughput numbers for three common benchmarks. The conclusion is inescapable: the balloon driver reclaims memory from over-provisioned VMs with virtually no impact to performance. This is true on every workload save one: Java.
Read the rest of this entry »