VMware vSphere: Why Do We Have So Much Ballooned Memory? Part I

VMware vSphere: Why Do We Have So Much Ballooned Memory? - Published 5/18/2011

Part I of III

Why were we confused by Memory Ballooning?

While helping us review our upcoming ESX 4.1 memory whitepaper, our good friend from VMware's Performance Team noticed that our Memory Overcommit testing resulted in an unreasonable amount of VM memory reclamation through the balloon driver.

We thought we knew what Memory Ballooning is and how it is used to reclaim memory. Right? Not so! In this and the next two blog posts, we will show you why we were confused by the actual amount of memory being reclaimed from Memory Ballooning in our memory tests; we will then show you how we analyzed the memory counters to gain better insight into the issues and finally, how the results from further testing led to a better understanding of how Memory Ballooning actually works.

Memory Ballooning Tests

We tested on a HP ProLiant DL360 G7 server with 32GB of physical memory and vSphere 4.1. We initiated a server load with about 10GB of free memory remaining after loading VMs. We then injected an additional demand for 9.5GB of memory into the VMs in order to create memory shortage to force ESX to reclaim memory. Memory pressure from this action theoretically requires no more than 9.5GB of Free ESX Memory and reclaimed memory combined. However, our test results show that the hypervisor reclaimed about 9GB of memory while additionally losing 8GB of Free Memory. This appears to imply that ESX requires 17GB of memory for the 9.5 GB injection as shown in the following chart:

Figure 1: ESX Memory Activities with Memory Balloon

This test is what started it all - we could not explain why ESX appears to reclaim much more memory through balloon memory than was needed.

So, we ran the same test with Memory Ballooning disabled to see how much memory was reclaimed through kernel swapping only. The result should tell us the exact amount of memory that ESX needs to reclaim. Our test result, in figure 2, shows 8GB of Free ESX memory consumed as well as 1.9GB of memory reclaimed through kernel swapping. These figures, adding to roughly 10 GB, are much closer to the values we originally expected.

Figure 2: ESX Memory Activities without Memory Ballooning

Based on the above findings, it appeared to us that the current Ballooned Memory only indicated the amount of the guest memory that was pinned but not necessarily the amount memory physically reclaimed by the ESX. This would explain why the amount of ballooned memory was high in Figure 1.

But before we make such conclusion, we decide to dig deeper and explore the technical rationale behind it. Our next post will explain what the ESX 4.1 memory statistics really mean, and our third and final posting will show actual testing to finally explain the Memory Ballooning scenario that was puzzling us.

Author: Yungteh Chien

Be the first to comment
          Back To Top