Heap Size Calculator
Calculate recommended heap size for a process based on workload and object allocation rate.
About Heap Size Calculator
The recommended heap size must exceed the peak live object set by enough margin to accommodate allocator fragmentation (wasted space between allocated blocks) and garbage collector or allocator headroom (space needed for concurrent allocation during GC pauses or to avoid frequent compaction). A common rule of thumb is heap = peak_live × fragmentation_factor / (1 - headroom_fraction), targeting 2-3x the peak live set.
Formula
Recommended heap
heap = (peak_live × fragmentation_factor) / (1 - headroom%)
- L
- peak live object size
- f
- fragmentation factor
- h
- headroom fraction
Worked example
With the default values below, Heap Size Calculator returns Recommended Heap Size of 951. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Peak Live Object Setminimum 1 MB
- 512 MB
- Fragmentation Factoraccepts 1–3
- 1.3
- GC/Allocator Headroomaccepts 0–80 %
- 30 %
Results
- Recommended Heap Size
- 951 MB
- Recommended Heap Size
- 0.93 GB
- Fragmentation Overhead
- 153.6 MB
- GC/Allocator Headroom
- 285.3 MB
Step by step
- 1Peak live objects= 512 MB
- 2With fragmentation= 665.6 MB
- 3Recommended heap (with headroom)= 951 MB (0.93 GB)
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax or compounding frequency into account.
- Figures are rounded for display to 2 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
What is a good fragmentation factor for malloc?
For glibc malloc under typical workloads, fragmentation is usually 1.2-1.5x. For languages with GC (Java, Go), the GC compacts the heap periodically so fragmentation is lower, but you need more headroom for GC working space.
What happens if the heap is too small?
Frequent garbage collections (GC thrashing) in managed languages, or failed allocations (OOM) in C/C++. The process spends increasing time in memory management rather than useful work, severely degrading throughput.