Mem.MinFreePct and Memory Reclamation in vSphere 5
October 13, 2011 1 Comment
It feels good to be back..
Recently, Frank published a blog about new sliding scale based estimation for minimum free memory % in vSphere 5. An interesting read for anyone looking to estimate memory capacity for his/her vSphere based virtual infrastructure. My good friend YP Chien from Kingston ran some tests to understand the memory reclamation techniques [ballooning, compression and host-swapping] in vSphere 5. But, he noticed that the host free memory levels at which various memory reclamations kicked-in were quite different from what it should have been based on sliding scale logic mentioned in Frank’s blog. YP immediately brought this to my attention (Thanks YP!). I dug a bit on this and found the issue. Instead of commenting on Frank’s blog, I thought of offering a deeper explanation here:
I will use the same example that was used in Frank’s blog. Consider a server configured with 96GB of RAM. The MinFreePct threshold will be set at 1597.36MB based on a sliding scale shown in the following table:
Threshold Range (MB) Reserved Free Memory (MB)
6% 0 – 4091 245.76
4% 4092 – 12287 327.68
2% 12288 – 28671 327.68
1% Remaining 696.32 (in this case)
Total Free Mem 1597.36
For the host considered in the above example, various memory reclamation techniques kick-in at different thresholds as explained below:
Free Memory State Threshold (% of MinFree) Threshold in MB Reclamation Type
Soft to High 64 to 100 1022.31 – 1597.36 Balloon
Low to Hard 16 to 64 255.57 – 1022.31 Balloon, Compression and/or Swap
Please note:
- There is no separate reclamation target for Memory Compression. It uses ‘Swap Target’ to reclaim memory.
- The choice of using memory compression [when enabled] or host-swap is dynamic. vSphere tries to use memory compression, but if it cannot reclaim enough memory soon it will resort to host swapping.
- Decrease in memory pressure doesn’t mean that the respective reclamation targets are set to zero immediately. vSphere constantly monitors the memory pressure in the host and gradually reduces a reclamation target if it finds memory pressure to have reduced. On the other hand, memory states could change as soon as the memory pressure in the host changes. Hence, it is possible for you to see some memory reclamation (balloon or swap) for extended time till the respective reclamation targets become zero even after the memory states indicate no or reduced memory pressure.
Hope this helps you understand when a specific type of memory reclamation kicks-in and why you would see it even when you don’t expect to see it. Feel free to throw in your comments or questions 🙂