You see your load average creeping up and the server feels sluggish, but free reports you still have a gigabyte of RAM left. You restart the app, clear the caches, and check the logs. It feels like a ghost in the machine. But the kernel isn’t guessing; it is tracking exactly how long tasks are waiting for memory resources, and it is almost certainly buried in the PSI files.

Why top is lying to your face

Most of us still use traditional metrics like active versus inactive memory. The problem is that swapping isn’t a binary state anymore. Modern kernels use pressure stall information to tell you when tasks are actually blocked waiting for memory pages. If you ignore these, you are looking at utilization when you should be looking at contention.

cat /proc/pressure/memory

• some avg10 shows the percentage of time tasks were stalled over the last ten seconds
• full avg10 tells you when all non-idle tasks were blocked, which is your real emergency
• Compare these numbers to your application latency spikes to find the correlation

Finding the specific offender

If you are running systemd, you can drill down into specific slices to see which cgroup is causing the thrashing. Don’t waste time checking global system health when one background worker is hogging everything. If you see high stall rates in a cgroup, that is the specific process that needs its memory limits tuned or its garbage collector tweaked. Checking these stats before you reach for a reboot will save you an hour of blind troubleshooting.