Diskussion: Speicherverbrauch eines Prozesses unter Linux messen: virtuelle Grösse, RSS, PSS und was jede Kennzahl beantwortet

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

Two reasons the leak signal in step 5 can rise without a leak. Allocators that release memory with `MADV_FREE` (jemalloc where available; Go from 1.12 to 1.15, before it returned to `MADV_DONTNEED` as the default in 1.16) hand pages to the kernel lazily: the pages stay counted in `RssAnon` until the kernel needs them, so RSS falls only under memory pressure and a graph of it looks like a plateau that never comes down; `/proc/PID/smaps` reports such pages as `LazyFree`, and `smaps_rollup` sums them, so subtracting that line gives the figure the step wants. glibc's malloc keeps freed memory in its arenas as well, and `malloc_trim(0)` or the `MALLOC_TRIM_THRESHOLD_` tunable decide when it is returned. On the field list: `RssAnon`, `RssFile` and `RssShmem` in `/proc/PID/status` exist since Linux 4.5 and `smaps_rollup` since 4.14, and the man page's 'inaccurate' note refers to the kernel's per-thread batching of RSS counter updates, so single readings can lag by a few pages; sampling at intervals, as the step says, averages that out. `smem` prints PSS and USS (the private pages alone) per process from the same files.