Check: Linux memory

Every process has its own virtual address space. The CPU translates an address from it into a physical one through the MMU, using the process's page table, and keeps recent translations in the TLB. Memory is split into pages, usually 4 KiB on x86-64, though ARM sometimes uses 16 or 64 KiB. getconf PAGE_SIZE shows the size on your machine. More detail in the lesson on virtual memory and pages.

VSZ (VmSize in /proc/<PID>/status) includes everything the process has reserved: mapped libraries, heap that's been allocated but never touched, large mmap regions. A physical page only shows up on first access (demand paging), and only then does it count toward RSS (VmRSS). That's why VSZ is usually bigger, sometimes by tens of times, and on its own that's not a warning sign.

The kernel keeps files it has read in page cache as long as nothing else needs the memory. Clean cache pages get freed without writing to disk the moment processes need memory. The margin left for new processes is shown by available (the MemAvailable line in /proc/meminfo), not by free. Inside a container, free shows the whole machine's memory; the container sees its own usage in /sys/fs/cgroup/memory.stat, in the anon and file lines.

A clean file-backed page (program code, cache) the kernel can simply drop: a copy exists in the file. An anonymous page (heap, stack) has nowhere else to go, so anonymous pages that haven't been touched in a while get swapped out. How eagerly the kernel does this instead of evicting cache is set by vm.swappiness.

The score grows with how much memory the process uses: RSS, swap, page tables. The result shows up in /proc/<PID>/oom_score. oom_score_adj shifts the score: +1000 means "kill this one first", -1000 takes the process out of the running. Any process can raise its own adj value; lowering it below the starting value needs CAP_SYS_RESOURCE. In a container with a limit, the choice is made among the processes in its cgroup.

An exit code above 128 means the process was killed by the signal numbered "code minus 128". SIGKILL can't be caught, so the process never gets a chance to write anything. The next step is the kernel log (dmesg, journalctl -k), and inside a container the file /sys/fs/cgroup/memory.events: the oom_kill counter shows how many processes in the cgroup the OOM killer has killed. If Docker had stopped the container, it wouldn't still be in Up status.