Showing posts with label balloon driver. Show all posts
Showing posts with label balloon driver. 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, 30 November 2016

Virtualization Oversubscription - What’s so scary? Balloon Driver (7 of 20)

Today we'll take a look at the Balloon Driver (vmmemctl)

The Problem

A process in VM1 is shut down and its memory is freed in the OS.
The “hardware” does not know.  The data is still there but only the OS inside the VM knows it can overwrite it.


The VMware Solution

When memory gets tight on an ESX host, the VM kernel will pick a VM (based on shares), and tell the balloon driver to request some memory.

The balloon driver requests memory and “pins” it so it cannot be paged.  The Memory on the ESX is then freed up and can be allocated to another system.

On Friday I'll be talking about Memory Test.

There's less than a week to go until our 'VMware Capacity and Performance Essentials' online workshop starts, still time to book your place.

Phil Bell
Consultant

Monday, 28 November 2016

Virtualization Oversubscription - What’s so scary? Memory Oversubscription (6 of 20)

As stated in my previous blog having set out a few ground rules we can now look at memory oversubscription.
So how can we over-subscribe memory?
Free Space - Just like disks have a lot of free space, servers typically run with free space in memory. 
Then there are a number of tricks that the hypervisor can do to find even more savings.
·        Page Sharing (Deduplication)
·        Balloon Driver (VMware)
·        Reservations
·        Shares

We'll start with a look at:
Transparent Page Sharing
When two or more Virtual Machines have the same pages of data in memory, VMware can store a single copy and present it to all the VMs.  Should a VM alter a shared memory page, a copy will be created by VMware and presented to that VM.
An Example is shown in the graphic below:


VM1 starts and allocates some unique memory.
VM2 starts and allocates some unique memory.
VM1 allocates memory for a standard windows dll.
VM2 also allocates memory for the same standard windows dll.
VMware maps both systems memory to the same page in RAM.
On Wednesday I'll explain more about the VMware Balloon Driver.
In the meantime register for access to some of our great Resources, white papers, on-demand webinars and more.
Phil Bell
Consultant

Monday, 24 October 2016

5 Top Performance and Capacity Concerns for VMware - Monitoring Memory

Memory still seems to be the item that prompts most upgrades, with VM’s running out of memory before running out of vCPU.

It’s not just a question of how much of it is being used as there are different ways of monitoring it. Some of the things that you are going to need to consider are:

       Reservations

       Limits

       Ballooning

       Shared Pages

       Active Memory

       Memory Available for VMs

VM Memory Occupancy

In terms of occupancy the sorts of things that you will want to look at are:

       Average Memory overhead

       Average Memory used by the VM(active memory)

       Average Memory shared

       Average amount of host memory consumed by the VM

       Average memory granted to the VM


In this instance we can see that the pink area is active memory and we can note that the average amount of host memory used by this VM increases at certain points in the chart.
VM Memory Performance
It's useful to produce a performance graph for memory where you can compare:
       Average memory reclaimed
       Average memory swapped
       Memory limit
       Memory reservation
       Average amount of host memory consumed.
As illustrated below.


In this instance we can see that this particular VM had around 2.5gb of memory ‘stolen’ from it by the balloon driver (vmmemctrl), at the same time swapping was occurring and this could cause performance problems.
The next place to look at for memory issues is at the Cluster and I'll deal with this on Wednesday.
In the meantime don't forget to book your place on our VMware vSphere Capacity & Performance Essentials workshop taking place in December http://www.metron-athene.com/services/online-workshops/index.html
Phil Bell
Consultant