Why does a forked Python worker's memory climb even when it only reads inherited data?

## The promise and the leak `fork` is cheap because the kernel does not copy the parent's memory; it marks the pages shared and read-only and copies a page only when someone writes to it. The appealing conclusion is that you can load a 2.4 GB working set once in a parent process, fork eight workers, and pay for it once. Watch the resident memory of a real triage service doing this and you see something else: each worker's RSS climbs steadily over the first minutes and settles at a large fraction of the parent's, even though no worker ever mutates the data. ## Why reading is a write in CPython CPython manages object lifetime with reference counting, and the count lives in the object's own header, right next to its data. Every time a name is bound to an object, an object is pushed on the evaluation stack, or a container is iterated, that count is incremented and later decremented. From the kernel's point of view those are ordinary writes to ordinary pages. Reading one dictionary out of a list of millions touches the list's page, the dictionary's page, the pages of its keys and values, and each of those touches converts a shared page into a private copy. Pages are typically 4 KB, and Python's small objects are scattered across them, so touching a modest fraction of the objects can dirty most of the pages. That is the mechanism behind the slow climb: it is not a leak, it is copy-on-write doing exactly what it promises, applied to a runtime that writes everywhere. ## The garbage collector makes it systematic Reference counting alone cannot free cycles, so CPython also runs a generational cyclic collector. When it runs, it walks every tracked container — every list, dict, instance, tuple-of-containers — and writes bookkeeping into each object's GC header as it computes reachability. A single full collection in the child can therefore touch the entire inherited heap and dirty essentially all of it at once, even if the application never read those objects at all. This is what `gc.freeze()` addresses. Called after your data is loaded and immediately before forking, it moves every currently tracked object into a permanent generation that the collector does not traverse. The inherited objects then stay untouched by collections in the children, and only objects allocated after the fork are collected normally. `gc.unfreeze()` reverses it and `gc.get_freeze_count()` reports how many objects are parked there. Pair it with `gc.disable()` in short-lived workers when the work allocates little and exits quickly. Since Python 3.12 some objects are immortal — `None`, `True`, `False`, small integers, interned strings — and their reference counts are never modified, so they no longer dirty pages. That helps at the margins; it does nothing for your own millions of dicts and lists. ## The real fix: fewer objects Freezing the collector removes one source of writes; reference counting remains. The durable fix is to stop representing bulk data as millions of Python objects at all. One large `bytes` object, an `array.array`, or a `memoryview` over a `multiprocessing.shared_memory.SharedMemory` block holds its payload in a single allocation with exactly one reference count, so reading element three million writes nothing. A file mapped with `mmap.mmap` is better still: the pages are backed by the kernel page cache, genuinely shared between processes, and evictable under memory pressure rather than counting against every worker. ## Two things that make this a 3.14 conversation First, you may not be forking at all any more. On Python 3.14 the default start method is `forkserver` on Unix other than macOS, and `spawn` on macOS and Windows, so a child no longer inherits the parent's heap unless you explicitly ask for `fork` via `multiprocessing.get_context("fork")`. A design that depended on inherited data silently stops working on upgrade — it does not get slower, the data is simply not there. Second, requesting `fork` explicitly is increasingly a liability: forking a process that already has threads is unsafe and has emitted a `DeprecationWarning` since 3.12, and plenty of libraries start threads behind your back. ## Measuring it Python-level tools mislead here. `tracemalloc` accounts for allocations the interpreter made, not for pages the kernel copied, so a worker that dirties inherited pages looks innocent. Measure at the OS level — resident and proportional set size per process — and compare shared against private mappings. A worker whose private memory grows while its Python-level allocations stay flat is the signature of copy-on-write being undone.