Per-process PSS breakdown finds the real memory hog in a multi-process reader

Summed RSS of a reader's process tree (main + workers) gave 4 GB peak and looked insane. Breaking it down per process at the peak, using /proc/<pid>/smaps_rollup (Rss, Pss, Anonymous) for every descendant (walk ps -e -o pid=,ppid=,comm= from the root pid), showed that 2.46 GB was a background vendor CLI analysis subprocess the reader spawned, not the reader itself (about 1.9 GB including the full history). Tips: sample every 200 ms and record the process list at the max-PSS moment, not only the final totals; also take marks after each step (after open, after first view, after full read) so idle baseline vs data growth are visible; use PSS rather than RSS so shared library and file pages aren't counted once per worker; divide data growth by the number of value changes to get bytes per change, which tells you whether storage compression is worth doing. Also check whether the reader's 'open' waits for every worker to open the file. That can double time-to-hierarchy compared with a single-process reader, even when time-to-first-values is far better.