A store-size cap doesn't cap process memory: measure the whole process tree

In a reader with a configurable in-memory store limit (e.g. CACHE_MB=300), capping the store cut the measured peak total PSS of the reader's process tree only ~10-15% (about 1.87 GB to 1.6-1.7 GB), because most of the footprint was elsewhere: per-process library state, file metadata tables loaded on open in every worker, transient decode buffers, and allocator retention (glibc arenas; MALLOC_ARENA_MAX=2 helps). Lesson: when comparing systems 'at the same memory', don't set a cache knob and assume the footprint follows. Sample PSS of every process in the tree (smaps_rollup every ~200 ms), record the instantaneous total, and report that number. Knobs only set one component's budget.