Virtual Memory Calculator
Calculate virtual address space size and mapping requirements for a process.
About Virtual Memory Calculator
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
Worked example
With the default values below, Virtual Memory Calculator returns Physical + Swap Capacity (MB) of 24,576.00. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Physical RAM (MB)minimum 1
- 16,384
- Swap Space (MB)minimum 0
- 8,192
- Committed Memory / CommittedAS (MB)minimum 0
- 20,000
- vm.overcommit_memory Policyone of 0 — Heuristic overcommit (default), 1 — Always overcommit (no checking), 2 — Strict accounting (no overcommit beyond ratio)
- 0 — Heuristic overcommit (default)
- vm.overcommit_ratio (%, used when policy = 2)accepts 0–200
- 50
Results
- 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
- 1Values used
- 2Strict commit limit
- 3Physical + Swap Capacity (MB)= 24,576.00
- 4Committed / (RAM+Swap) Ratio= 0.814
- 5Commit Limit Under Strict Policy (MB)= 16,384.00
- 6Overcommit 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.
Assumptions and limits
- The result is derived only from the 5 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 3 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.