Showing posts with label VMware ballooned memory. Show all posts
Showing posts with label VMware ballooned memory. Show all posts

Friday, 14 July 2017

Understanding VMware Capacity - Measuring Memory Capacity (6 of 10)

Today we'll take a look at measuring memory capacity, below is a typical graph we might use to understand how memory is being used by a VM. 


The VM has been granted about 4GB RAM. That’s what the OS thinks it has to use.

The host memory in use, shows how much physical RAM is currently being used by the VM. We can see that at 09:00 this increases and at the same time shared memory reduces.

Memory Used is our term for Active memory, and remains steady throughout, as does the Memory Overhead on the host used to support this VM. What we can see is that only about 400MB of memory is being accessed on a regular basis. Between 1.5GB and 2GB of memory is not unique to this VM and is shared with others.

Balloon Driver

The balloon driver takes about 2.5GB of space in the memory of the VM. This will cause the OS to swap out to disk until it cannot do any more, and then the hypervisor starts to swap out memory also. At that point, performance is likely to be impacted.

Here's an example of the balloon driver in use.


Where ballooning is persistent (rather than an occasional spike), then changes should be made in order to ensure there is enough RAM available for the VMs in the cluster. Ballooning itself has an overhead on the hypervisor and as such there is the potential to impact performance for the host. Changes don’t necessarily have to be more RAM installed. The very first thing to consider is if any VMs have been created and “forgotten” about. On Monday I'll take a look at Cluster memory.

Phil Bell
Consultant



Wednesday, 12 July 2017

Understanding VMware Capacity - Measuring Memory Capacity (5 of 10)

Memory capacity is generally the limiting factor in a VMware cluster. This is improving as hardware specifically designed to be a host has become available with plenty of RAM able  to be installed, but clusters still generally have less Memory headroom than CPU. Memory on VMware is not just a case of monitoring % used. Again like CPU we want to be able to compare memory utilizations in comparable metrics, so that’s MB or GB. Then we move on to the specific VMware type metrics.

Reservations
A VM or a resource pool can have a reservation. Which means if it needs that memory, it gets to use it - no questions asked. However you cannot reserve more memory than exists in the host server.
Limits. Just because a VM has been configured to have 8GB RAM, doesn’t mean you can’t set a lower limit of say 4GB RAM. At which point, if the VM tries to use more than the limit, then some data will be placed into the Swap file of the OS or VMware may balloon some of the VMs memory to free up pages that the OS can use.

Ballooning
When VMware wants to allocate memory to a VM, but there is a shortage of Memory, then a balloon may be inflated inside the memory of one (or more) VMs. This balloon pins itself into RAM and cannot be swapped out, thus forcing the OS to swap some memory out to disk. The pages pinned into memory are not all actually stored in memory on the Host, as it knows the contents of the balloon are not important. This then frees up pages, that the Host can allocate the VM it wanted to give memory too. One of the reasons this happens is that an OS will use a page to store some data, then later the program will no longer need that data, and the OS puts that page on the free list. However, the hypervisor has no idea the page is no longer needed. The data in the page has remained unchanged. In order to identify free pages when the balloon expands and the OS put it into the free pages, the hypervisor can
identify the balloon memory pages, and therefore the pages that the OS is not using for other processes.

Shared pages
Shared Pages are pages in memory that are identical. Rather than store duplicates of the same page, the hypervisor will store a single copy, and point the appropriate VMs to it. This works well where servers are running the same OS and doing the same job, and therefore much of the memory in use is identical.

Active Memory
Active memory is the amount of memory that has been accessed in the last 20 seconds. Having sufficient memory to contain the active memory of the VMs is crucial to performance.

Memory Available for VMs
Memory available to the VMs shows what it says. There is some memory in the cluster that VMs cannot use as it’s being used by the Hypervisor to support the VMs. The memory left over is available.

On Friday I'll talk about understanding how memory is being used by a VM. In the meantime don't forget to sign up for my next webinar 'Top 5 VMware Tips for Performance and Capacity'
Phil Bell
Consultant

Friday, 7 July 2017

Understanding VMware Capacity - 5 key VMware metrics (3 of 10)

There are plenty of metrics provided by VMware. Some of these are familiar to anybody who’s ever monitored a computer (CPU%, IOPS etc.). So for a short list of 5 I’ve selected 5 metrics that are important and available in VMware environments.

To some extent I’ve cheated to make a list of 5, because for some I’m looking to get the same metric from different levels in the environment. Most of these I will cover in greater detail in the sections following this.

CPU MHz
Why not %? Well because we can’t compare the CPU% Used of a VM with the % of the Host or the Cluster. We want to judge the amount of processing power an individual VM requires. That way when we want to move it to another cluster, or are considering the size of the existing cluster, we have a comparable value to work with. I fully admit it’s not perfect. The processing you can do with 1MHz today is greater than that of 10 years ago. But it’s still better than %. 

Ready Time
It’s a measure of CPU contention. The bigger the number the less happy your users are. But it doesn’t always mean you are short of CPU power.

Active Memory
The amount of memory the VM has accessed in the last 20 seconds. If there isn’t space for all the active memory in the cluster, then performance will be sub optimal.

Ballooned Memory
Memory ballooning works by “robbing Peter to pay Paul”. When memory is in short supply and/or over committed, pages of RAM in a VM OS can be filled by a “balloon”. These pages are then not actually available to the OS, and the space freed up and will be used by other VMs that need the RAM resources. As memory demand goes down, VMware deflates the VMs balloon and the RAM is again available to the VM. Again this is a sign of contention for resource and introduces additional overhead to the VMware hypervisor.

Host Disk Latency
Among the metrics that are provided for Hosts are the Disk Latency metrics. Disk IO performance is still the greatest performance challenge faced by most organizations I meet.

In my next blog on Monday I'll take a closer look at Ready Time.

Phil Bell
Consultant