Stop wondering why your IO latency spikes during heavy swaps

Technical Briefing | 9/20/2026

You see the system load average creep up, the disk queue depth looks fine, but your application latency is completely trashed. Everyone usually blames the database or the network, but often it is just the kernel thrashing as it reclaims memory. I have wasted hours chasing phantom network issues only to realize that page faults were hammering the swap partition, effectively serializing every single thread waiting on a memory map.

Seeing the silent thrashing

Most tools like top will show you the swap usage, but they don’t show you the velocity of that usage. You need to see how many pages are actually moving in and out of the swap space per second. If you aren’t looking at major and minor faults, you are missing the signal in the noise. This bit me in prod when a Java heap allocation triggered a massive page reclaim cycle that essentially locked the kernel’s memory management path for a few hundred milliseconds.

sar -B 1 10

• pgpgin/s tells you how many kilobytes are being swapped in from disk
• pgpgout/s shows the pages getting pushed out when the kernel is desperate for free RAM
• majflt/s indicates the process actually hitting the disk because the page wasn’t in memory

Why you should care about major faults

If you see your major fault rate climbing while your application response time tanks, stop looking at the NIC. The kernel is busy blocking your application threads while it fetches memory from the swap partition. Sometimes the fix is just tuning swappiness, but if you have a massive memory leak, you’re just delaying the inevitable. Next time your latency spikes, check your fault rates before you go hunting for non-existent network packet loss.