One of the topics in the VMware vSphere Optimize and Scale course is how the amount of RAM is calculated that your host should have available as a minimum before processes such as ballooning and swapping become active.
The course material provides this table that shows us how this minimal free memory is calculated:
Memory Installed | Free State Threshold Range |
---|---|
0 through 4 GB (first 4 GB) | 6% |
4 through 12 GB (next 8 GB) | 4% |
12 through 28 GB (next 16 GB) | 2% |
Remaining memory | 1% |
But how exactly does this relate to the actual server's memory and the values we see in esxtop?
Let me add the values from my own server with 128 GB RAM to show you how this works:
Memory Installed |
Free State |
Calculation | Actual memory |
---|---|---|---|
0 through 4 GB (first 4 GB) | 6% | 6% of 4096 MB | 245.76 MB |
4 through 12 GB (next 8 GB) | 4% | 4% of 8192 MB | 327.68 MB |
12 through 28 GB (next 16 GB) | 2% | 2% of 16384 MB | 327.68 MB |
Remaining memory (128 GB - 28 GB) (see my esxtop image for vmkmem value, which is 130607 MB) |
1% |
1% of 128GB-28GB) |
1019.35 MB |
1920.47 MB |
Where do the values come from? The first three rows are simple, they come from the defaults and will be the same for any host with up to 28 GB RAM. The remaining memory would be 128 GB - 28 GB = 100 GB but you have to be accurate and use the amount of RAM that is actually available to the VMKernel, which is available from esxtop as the value represented by VMKMEM/MB, which in my case is 130607 MB. So I subtract 28 GB, or 28672 MB) and that gives me 101935 MB, of which 1% = 1019.35 MB. All values together add up to 1920.47 MB, which is rounded down to 1920 that matches the value of 1920 minfree from esxtop.
This is the default behavior that can be changed by modifying the value of the Mem.MemMinFreePct parameter in the advanced settings of your ESXi host. The default is 0 which means that the value is automatically calculated with the procedure described before. You can configure a fixed percentage to set the amount of RAM that must be available as a minimum before memory reclamation techniques are executed.
The last thing to look into is at which amount of RAM the memory reclamation techniques are executed. The course material for the VMware vSphere Optimize and Scale training provides these numbers:
Memory State | Threshold | Actions |
---|---|---|
High | 300% of minFree * | Break Large Pages (wait for next TPS run) |
Clear (new in v6) | 100% of minFree | Break Large Pages and active call TPS to collapse pages |
Soft | 64% of minFree | TPS + Balloon |
Hard | 32% of minFree | TPS + Compress + Swap |
Low | 16% of minFree | Compress + Swap + Block |
* There are reports that this value is 400% but I stick with the numbers from the official course materials.
When I add the numbers that I have calculated before for my host (1920 MB minFree) and do the math then you can see at which amount of RAM available these reclamation techniques are in effect:
Memory State | Threshold | Actions | Calculate | Actual memory |
---|---|---|---|---|
High | 300% of minFree | Break Large Pages (wait for next TPS run) |
300% of 1920MB |
5760 MB (5.6 GB) |
Clear (new in v6) |
100% of minFree |
Break Large Pages |
100% of 1920MB | 1920 MB |
Soft | 64% of minFree | TPS + Balloon | 64% of 1920MB | 1228.8 MB |
Hard | 32% of minFree | TPS + Compress + Swap | 32% of 1920MB | 614.4 MB |
Low | 16% of minFree | Compress + Swap + Block | 16% of 1920MB | 307.2 MB |