Limits: Space_Overhead Tuning for Low‑Traffic OCaml 5 Services

The goal is to lower the cloud bill for a native‑compiled OCaml service that receives only a handful of requests per hour. The primary knob is Gc.set’s space_overhead parameter, which controls how aggressively the major GC runs: a higher value means fewer collections but a larger heap, while a lower value forces more frequent collections and a smaller heap.

In OCaml 5 the major GC runs concurrently, so adjusting space_overhead can alter both memory residency and latency spikes in ways that differ from OCaml 4. The trade‑off is unclear: does a smaller heap reduce the memory‑based cost sufficiently to outweigh the extra CPU cycles and potential latency introduced by more frequent collections?

Because the hosting pricing model may weight memory and CPU differently, the optimal space_overhead is not obvious. We need to decide whether to prioritize memory savings or CPU efficiency, but no documented threshold or recommendation exists for low‑traffic workloads.

What is the impact of setting space_overhead to 100, 150, or 200 on both resident memory and CPU usage for a typical low‑traffic OCaml 5 service? How does this translate into cost under a pricing model that charges per GB‑hour versus per CPU‑second? At what point does the increased GC CPU time negate the savings from reduced memory usage?