Systems Programming Deep Dive

Series context. This article is part of an ongoing series on Linux internals. We’ve covered memory allocators, process creation, and lock primitives. Now we look at what happens when memory runs out — how the kernel decides what to kill, and how to see it coming before it does.

---

Part I — The Article

---

Advanced Monitoring Tools for Memory Usage and OOM Prevention

The OOM killer firing in production is almost always a surprise. Not because memory ran out suddenly—it didn’t. Exhaustion built over hours, and nobody noticed because they were watching the wrong metrics.

---

Why RSS Lies

top shows your process at 500MB RSS. Sum every process on the box: 8GB. The machine has 4GB of RAM. That math doesn’t work, and it’s not because top is broken.

RSS (Resident Set Size) counts every mapped physical page, including shared library mappings. libc, libpthread, the C++ runtime—counted once per process. On a box running 20 Java services linking the same libraries, you’ll overcount physical memory by 3–4×. The number you actually want is PSS: Proportional Set Size. PSS divides each shared mapping by the number of processes sharing it, giving an honest view of physical consumption.

Read it from /proc/<pid>/smaps_rollup (kernel 4.14+):

Pss:            47832 kB
Private_Clean:   8192 kB
Private_Dirty:  39640 kB

Private_Dirty is what you’ll actually lose when the process dies. PSS is your capacity planning number.

---