Proxmox memory overcommit planner
Add up what the guests are allowed to take, subtract what the host and ARC need, and find out before the swapping starts.
The host
GiB, as the host reports it.
GiB for the kernel, services and headroom.
GiB. On a ZFS root Proxmox defaults this to half of RAM unless you set zfs_arc_max. Zero if the host is not on ZFS.
The verdict
- Allocated against available
- —×
- Available to guests
- —GiB
- Allocated to guests
- —GiB
- Headroom
- —GiB
- Guests defined
- —
The guests
| What it is | GiB each | How many | Total | Remove |
|---|
Reading the ratio
- Under 1.0 you are not overcommitted at all — every guest could take everything it is allowed and the host would still be fine. That is the right target for anything you depend on.
- Between 1.0 and about 1.3 is ordinary for a lab, provided the guests are mostly idle, page sharing is on, and the balloon driver is installed so the host can ask for memory back. Take any one of those away and the margin goes with it.
- Past that, swap is not a risk, it is a plan. The host will page to disk to keep its promises, and everything gets slow at once rather than one guest failing cleanly.
- Allocated is not used. The fix is usually not more RAM: it is finding the guest configured with 16 GB whose committed memory has never passed 5. Check with qm config <id> against what the guest itself reports before you buy anything.
- ARC counts, and it is bigger than you think. On a ZFS root Proxmox will take half the host's memory for cache unless told otherwise. It does give it back under pressure, but slowly enough to matter.
- Page sharing rewards similarity. A dozen guests from the same Linux template deduplicate well; Windows guests and anything with large pages enabled barely at all.
Everything on this page is worked out in your browser. Nothing you type is submitted, stored or logged, and the page makes no requests after it loads.