Virtual Memory Calculator
Calculate virtual address space size and mapping requirements for a process.
Inputs
Physical + Swap Capacity (MB)
24,576.00
Committed / (RAM+Swap) Ratio
0.814
Commit Limit Under Strict Policy (MB)
16,384.00
Overcommit Policy Note
Policy 0 (heuristic) — the kernel estimates whether an allocation is 'reasonable' using heuristics rather than strict accounting; large but sparse allocations (e.g. malloc without full use) are usually allowed.
Step by step
Values used
Physical RAM (MB) = 16,384; Swap Space (MB) = 8,192; Committed Memory / CommittedAS (MB) = 20,000; vm.overcommit_memory Policy = 0 — Heuristic overcommit (default); vm.overcommit_ratio (%, used when policy = 2) = 50
Strict commit limit
CommitLimit = swap + physical_RAM × overcommit_ratio%
Physical + Swap Capacity (MB)
= 24,576.00
Committed / (RAM+Swap) Ratio
= 0.814
Commit Limit Under Strict Policy (MB)
= 16,384.00
Overcommit Policy Note
= Policy 0 (heuristic) — the kernel estimates whether an allocation is 'reasonable' using heuristics rather than strict accounting; large but sparse allocations (e.g. malloc without full use) are usually allowed.
How it works
Virtual memory lets processes reserve address space far beyond physical RAM, since most allocated virtual memory is never fully touched (sparse allocations, unused stack/heap headroom, shared library mappings). Linux governs how aggressively it allows this via vm.overcommit_memory: policy 0 (default) uses heuristics to permit 'reasonable' overcommit; policy 1 disables checking entirely; policy 2 enforces a strict CommitLimit = swap + RAM × overcommit_ratio%, refusing allocations that would exceed it regardless of how much would actually be used.
Formula
Strict commit limit
CommitLimit = swap + physical_RAM × overcommit_ratio%
- S
- swap space
- R
- physical RAM
- k
- overcommit_ratio fraction
Frequently Asked Questions
Why does 'top' show virtual memory (VIRT) much larger than physical RAM for a single process?
VIRT counts all address space a process has reserved — including memory-mapped shared libraries, unused malloc arena headroom, and memory-mapped files — most of which is never simultaneously resident in physical RAM. RES (resident set size) is the more meaningful figure for actual physical memory consumption.
What's the risk of vm.overcommit_memory=1?
With checking disabled, allocations that the system can never actually back with real memory still succeed at allocation time, deferring the failure to when the memory is actually touched — at which point the OOM killer may need to terminate a process, potentially one unrelated to the actual over-allocator.
When should I use strict overcommit (policy 2)?
On systems where predictable failure (a refused allocation) is preferable to unpredictable OOM kills later — for example, memory-critical services where you'd rather an allocation fail cleanly and be handled in application code than have the OOM killer choose an arbitrary victim process under pressure.