With an upcoming upgrade to vSphere 6 on the horizon, the subject of Transparent Page Sharing came to mind again and also the fact that I’ve had a post in draft kicking around for quite a while.
Transparent Page Sharing (TPS) is a memory saving technique employed by the ESXi hypervisor to reduce memory consumption by performing out of line memory deduplication.
Guest memory is periodically scanned for duplicated memory pages and where they are identical, remaps these to one single page therefore freeing up N-1 pages. This technique means that there is more memory available and more opportunity for over commitment.
Memory statistics can be seen using Esxtop or the vSphere client performance graphs
Figure 1 – Esxtop Memory Statistics
The image in Figure 1 shows the level of overcommit during the following intervals; 1min, 5min, 15min. In this instance the memory is overcommitted by 27% consistently.
The lower highlighted portion shows that through the use of page sharing, 89GB (89486MB) has been saved and reduced down to a footprint of 19GB. 108GB is the amount of memory that is in common with other VMs on that host.
These figures can also be reproduced through the vSphere Performance charts by looking at the Shared and Shared Common graphs of the host. Shared Common corresponds to the memory footprint and Shared corresponds to the memory saved.
A large proportion of the memory saved through page sharing may actually be down to zero pages, pages in memory that have been zeroed out by the OS such as at boot time. The amount attributed to this can be seen in the performance graphs by plotting the values Shared and Zero.
By using the values above we can work out how much memory is saved due to page sharing between VMs over just zero memory pages. (see next post for PowerCLI function to calculate this)
(261620444 – 166978640) / 1024^2 = 90 GB inter-VM memory saved
This is the amount of memory is gained by having inter-VM page sharing enabled. Now since approximately May 2015 updates have come out that disable TPS by default and ESXi 6 comes that way out of the box. This is due to security concerns that have been uncovered, the explanation is quite technical and can more detail can be found in KB2080735.
Consideration therefore must be given to the impact that this will have in the environment against the associated security risks. In environments with a fairly homogeneous profile of VMs, the potential loss of memory saving from TPS can be quite large. Eg. a VDI environment.
Configuration of TPS is carried out on the host level and on the VM. At the host level you can set whether or not TPS will be enabled or not, and on the VM level you can determine between which VMs memory will be shared/saved. The table below shows the different settings available
By default the host setting Mem.ShareForceSalting is set to 2 which results in no interVM TPS. If this is set to 0, regardless of the VM setting sched.mem.pshare.salt, TPS will occur between all VMs on the host. If you want to only enable TPS between specific VMs the same salt value should be set on the VMs and Mem.ShareForceSalting should be set to 1.
Quick PowerCLI one liners:
To view the current value of Mem.ShareForceSalting across the cluster the following PowerCLI line can be used
|
1 2 |
$cluster = “Production” Get-Cluster $cluster | Get-VMhost | select Name, @{Name="Value"; Expression={Get-AdvancedSetting -Name Mem.ShareForceSalting -Entity $_}} | sort Value | ft -AutoSize |
To set Mem.ShareForceSalting to, say, 1 across the cluster
|
1 2 |
$cluster = “Production” Get-Cluster $cluster | Get-VMhost | Get-AdvancedSetting -Name Mem.ShareForceSalting | Set-AdvancedSetting –Value 1 |
To set sched.mem.pshare.salt for a VM
|
1 |
Get-VM $VM | Get-AdvancedSetting -Name sched.mem.pshare.salt | Set-AdvancedSetting –Value 0 |
Futher reading