Comments on: Re: Swapping

By: Top 5 Planet V12n blog posts week 21 | Download VDI Solutions

Top 5 Planet V12n blog posts week 21 | Download VDI Solutions — Wed, 27 Oct 2010 00:00:31 +0000

[...] Denneman – Re: SwappingWhen a virtual machine guest OS starts, there will be a period of time before the VMware tools is [...]

By: All things virtual XI « TheSaffaGeek

All things virtual XI « TheSaffaGeek — Fri, 04 Jun 2010 10:18:47 +0000

[...] and what metrics actually show performance degradation and how they are worked out. Franks posting gives more of a description on how the memory is calculated and describes the reasons for swapping [...]

By: NiTRo

NiTRo — Sun, 30 May 2010 10:02:46 +0000

Frank, this is exactly what i’m doing because i don’t use reservation.

By: Frank Denneman

Frank Denneman — Thu, 27 May 2010 08:27:58 +0000

Hi Craig,

Yeah the new feature is awesome, can’t wait to see that one released. Besides reducing the bogus memory pressure, it will also benefit TPS as it can scan more “real” pages during its cycle.

By: Frank Denneman

Frank Denneman — Thu, 27 May 2010 08:20:49 +0000

NiTRo, good question.
It is something I’m currently looking in to.
Not only for the reason to clear the stats, but also for machines who use a local swap file.
Many NFS shops store the swap file on the local storage of the ESX.
If a virtual machine is vmotioned, the content of the local swap file is copied to the destination ESX host.
By copying useless data across the source and destination host is something I want to avoid, it generates unnecessary overhead on the vmotion process.

By: NiTRo

NiTRo — Wed, 26 May 2010 15:36:00 +0000

Frank, do you know if it is possible to force free up the swapped page to “clear” stats ?

By: Craig Risinger

Craig Risinger — Wed, 26 May 2010 15:19:19 +0000

Keep your eyes open for a possible future feature: transparent page sharing that immediately shares zero-pages as they’re written. I.e. one pRAM page holds all-zeros. As a vRAM page is accessed and all-zeros are written to it, the hypervisor immediately backs this vRAM page with the existing all-zeros pRAM page. That should drastically reduce the bogus memory pressure due to oversized-vRAM VM bootstorms.

By: Craig Risinger

Craig Risinger — Wed, 26 May 2010 15:16:03 +0000

Good discussion of the bootstorm problem.

Bootstorms + oversized vRAM = bogus memory pressure => lots of swapped “data” that is never needed and doesn’t hurt performance.

Most large orgs have VMs with more vRAM than they need. The organizational process of getting vRAM resized is tedious (customer, file this form and the IT department will review and respond within x days, you need managment approval, etc.). So customers err on the side of too much. Or, maybe only a few “models” of VM are even offered (1 GB, 2 GB, 4 GB, etc.). The result: many VMs with excess vRAM. In this case, the amount of stuff sitting in swap files (and not being swapped back in) just illustrates how ESX is efficiently using scarce pRAM even though the VMs aren’t properly sized.