OS & Systems Fundamentals • Memory Management & Virtual MemoryMedium⏱️ ~3 min
Memory Overcommit and Copy-On-Write (COW) Trade-offs
Memory overcommit allows processes to allocate more virtual memory than physical RAM available. The kernel relies on Copy On Write (COW) and the observation that many allocations are never fully used. When a process forks or maps shared pages, the kernel marks pages read only and shares the physical frames. On the first write, the kernel copies the page to a new frame, making it private. This defers allocation and copying until necessary, improving density and startup speed.
COW enables fast process creation. Chrome's zygote model preloads hundreds of megabytes of libraries and then forks child processes for tabs. Initially, all children share the parent's code and data pages via COW, consuming minimal additional RAM. Only when a child writes (like modifying JavaScript objects or building the Document Object Model) does the kernel allocate new pages. This reduces memory footprint by 80%+ compared to independent processes and cuts startup latency from hundreds of milliseconds to tens of milliseconds.
The risk is Out Of Memory (OOM) situations. If many processes simultaneously dirty their COW pages, committed memory can explode beyond physical RAM plus swap. The kernel's OOM killer selects a victim process and terminates it, which is catastrophic for stateful services like databases. Overcommit works well when workloads have predictable memory behavior and strong admission control. It is risky for bursty allocators or systems without memory headroom.
Production practice balances overcommit with guardrails. Google's Borg and Kubernetes style schedulers treat memory as a hard constraint with reserved headroom. Services set cgroup memory limits below physical capacity, isolating failures and preventing system wide OOM. Operators monitor Resident Set Size (RSS), committed memory, and page in/out rates, alerting when committed memory exceeds physical headroom by more than 10% to 20% or when sustained paging activity indicates pressure. Amazon and Netflix similarly constrain memory and disable or limit swap for latency critical tiers to avoid major faults.
💡 Key Takeaways
•Copy On Write (COW) marks shared pages read only. On first write, the kernel copies the page to a new physical frame, making it private. This defers allocation and copying until necessary.
•Fast forking via COW: Chrome zygote preloads libraries, forks children that initially share pages. Memory usage grows only on writes, reducing footprint by 80%+ and cutting startup from 200 ms to 20 ms.
•Overcommit allows virtual allocations beyond physical RAM, relying on sparse usage and COW. Improves density but risks Out Of Memory (OOM) when many processes dirty pages simultaneously.
•OOM killer terminates a victim process when committed memory exceeds reclaimable capacity. Catastrophic for stateful services. Overcommit requires strict limits, headroom, and monitoring.
•Google Borg and Kubernetes set per service memory limits below physical RAM, leaving 10% to 20% headroom for kernel and page cache. This isolates failures and prevents system wide OOM.
•Track Resident Set Size (RSS), committed memory, and page fault rates. Alert when committed exceeds physical headroom or sustained paging indicates memory pressure.
📌 Examples
Chrome zygote process consumes 300 MB with preloaded libraries. Forking 50 tab processes initially shares these pages via COW, using 300 MB total instead of 15 GB. Writes over time grow usage to 2 GB, still a 7x savings.
A microservice fleet on Kubernetes sets memory limits to 8 GB per pod on 10 GB nodes, reserving 2 GB headroom. One pod leaks memory and hits its limit, triggering OOM kill of that pod only, not system wide failure.
A batch job forks 100 worker processes after loading a 2 GB dataset. Initially, all workers share the dataset via COW. If all workers write to the dataset simultaneously, committed memory jumps from 2 GB to 200 GB, exceeding physical RAM and triggering OOM killer.