Offensive Security Researcher & Quantum Cryptography Analyst

What is thrashing in the context of memory management

Abdul Wahab Junaid
What is thrashing in the context of memory management

If you’ve ever watched a computer’s disk activity light blink furiously while the whole system crawls to a near-standstill — mouse lagging, windows freezing, everything unresponsive — you’ve witnessed thrashing firsthand. It’s one of the most frustrating performance problems in computing, and understanding why it happens requires digging into how virtual memory and paging actually work under the hood.

Defining Thrashing

Thrashing is a condition in virtual memory systems where a process (or the system as a whole) spends more time swapping pages in and out of memory than it does executing actual instructions. The CPU utilization paradoxically drops even though the system appears extremely busy, because most of the “work” being done is disk I/O for paging, not useful computation.

In simple terms: the system is so overcommitted on memory that it can’t keep the “working set” of any process resident in RAM long enough to make progress before that memory gets reclaimed for another process’s pages.

The Root Cause: Over-Commitment of Memory

To understand thrashing, you need to understand the basic promise of virtual memory: it lets processes believe they each have access to a large, contiguous address space, even though physical RAM is limited and shared among all running processes. The operating system uses demand paging to bring pages into physical memory only when they’re actually accessed, and evicts pages back to disk (the swap space or page file) when memory runs low.

This works beautifully — until too many processes are active simultaneously, each with a working set (the set of pages it actively uses) that doesn’t fit comfortably in available RAM. When that happens:

  1. Process A needs a page not currently in RAM → page fault occurs
  2. The OS must evict some other page to make room
  3. It evicts a page belonging to Process B, which B needed
  4. Process B then faults, needing that page back
  5. To bring B’s page back in, the OS evicts a page from Process A (or C, or itself)
  6. Repeat, indefinitely

This cycle is thrashing: pages get evicted right before they’re needed again, causing a constant, unproductive stream of page faults and disk I/O.

The Belady Curve — CPU Utilization vs Degree of Multiprogramming

Operating systems textbooks illustrate this with a classic graph, often attributed to the study of multiprogramming levels:

CPU
Utilization
   ^
   |          ____
   |        /      \
   |      /          \
   |    /              \___________
   |  /                             \___
   | /                                  \___
   |/____________________________________________\___> Degree of
   0                                                    Multiprogramming
        (increasing number of active processes)

As you add more processes to the system (increasing the “degree of multiprogramming”), CPU utilization initially rises — more processes means the CPU is less likely to sit idle waiting on I/O. But past a certain point, there isn’t enough physical memory to hold each process’s working set. Page fault rates spike, and CPU utilization collapses, because the CPU and I/O subsystem are now overwhelmed swapping pages rather than executing code. This inflection point is exactly where thrashing begins.

Why Adding More Processes Makes It Worse (Not Better)

This is the counterintuitive part that trips up a lot of students. You’d think that if the CPU looks idle, the OS scheduler should launch more processes to keep it busy. But if the system is already thrashing, adding more processes only intensifies competition for the same scarce physical memory, deepening the crisis. Each new process needs its own set of resident pages, further starving existing processes and increasing the total page fault rate.

The Working Set Model

Peter Denning’s Working Set Model (1968) is the classical framework for understanding and preventing thrashing. The working set of a process at time t, denoted WS(t, Δ), is defined as the set of pages referenced by the process during the time interval [t - Δ, t], where Δ is the “working set window.”

The core idea for avoiding thrashing:

Page Fault Frequency (PFF) as an Alternative Strategy

A more direct approach than tracking working sets is monitoring the page fault frequency for each process:

This creates a feedback loop that dynamically balances frame allocation to keep every active process just below its thrashing threshold.

Real-World Symptoms of Thrashing

Thrashing Across Platforms

Linux/UNIX

Linux mitigates thrashing partly through its OOM killer, which terminates processes when memory pressure becomes severe enough that thrashing is imminent, and through cgroups-based memory limits in containerized environments (Docker, Kubernetes), which prevent a single container from starving the whole host. The vm.swappiness kernel parameter also lets administrators tune how aggressively the kernel prefers swapping over reclaiming cache.

Windows

Windows relies on its Memory Manager to dynamically size the working set of each process and uses the pagefile.sys for overflow. Severe thrashing on Windows is often visible through Resource Monitor’s memory tab, showing high “hard fault” counts. Windows Server editions also expose System Resource Manager policies to cap process memory usage in shared environments.

Android and iOS

Mobile OSes take a different philosophy: rather than allowing heavy swapping (which is especially punishing on flash storage and battery life), both Android and iOS aggressively kill background processes under memory pressure instead of thrashing. Android’s lmkd and iOS’s Jetsam mechanism both terminate low-priority apps well before the system would start heavily swapping, essentially trading a worse user experience (app restarts) for avoiding the far worse experience of a thrashing device.

Real-World Case: Thrashing on Overcommitted Cloud VMs

A very common modern instance of thrashing occurs in cloud environments where virtual machines are overcommitted — e.g., a hypervisor allocates more total virtual RAM to guest VMs than the physical host actually has. If several VMs simultaneously spike in memory usage, the hypervisor’s own paging/ballooning mechanisms can trigger thrashing at the host level, degrading every VM on that host simultaneously — a phenomenon sometimes called “double paging,” since both guest OS and host hypervisor are swapping independently.

How to Fix and Prevent Thrashing

  1. Add more physical RAM — the most direct fix if the workload’s total working set genuinely exceeds available memory.
  2. Reduce the number of concurrently active processes — close unnecessary background applications or services.
  3. Tune the degree of multiprogramming — in server contexts, limit the number of concurrent worker processes/threads to match available memory.
  4. Implement working-set-aware or PFF-based scheduling at the OS level.
  5. Use memory limits and cgroups in containerized deployments to prevent noisy-neighbor effects.
  6. Optimize application memory footprint — reduce unnecessary caching, fix memory leaks, and use memory-efficient data structures.
  7. Monitor proactively using tools like vmstat, sar, Windows Performance Monitor, or cloud provider memory metrics, and set alerts before thrashing begins rather than after.

Troubleshooting Checklist

Summary

Thrashing is what happens when a system’s memory demand outstrips its physical memory supply so severely that it spends nearly all its time paging rather than computing. It’s a direct consequence of virtual memory management gone wrong under excessive multiprogramming, and it’s counterintuitive precisely because adding more work makes performance collapse rather than improve. Classical solutions like Denning’s Working Set Model and page-fault-frequency-based load control remain foundational to how modern operating systems avoid this trap, while modern platforms like Android and iOS sidestep it almost entirely by killing processes before thrashing can take hold. Understanding thrashing isn’t just academic — it directly explains why your machine sometimes grinds to a halt when you open one too many browser tabs.

Frequently Asked Questions

Q: Is thrashing the same as high CPU usage? No — in fact it’s often the opposite symptom in disguise. During thrashing, reported CPU usage may look high because the kernel is busy handling page faults, but useful CPU work (actual application progress) is near zero.

Q: Can an SSD eliminate thrashing? An SSD reduces the severity of thrashing because page fault service time is much lower than on spinning disks, but it doesn’t eliminate the underlying problem — if working sets genuinely exceed RAM, thrashing (in a milder form) can still occur.

Q: Does thrashing only happen with multiple processes? No. A single process with a very large working set relative to available RAM can thrash entirely on its own, faulting on its own pages repeatedly.

Q: How is thrashing different from normal, healthy paging? Some paging is completely normal and expected in a virtual memory system. Thrashing specifically refers to the pathological case where paging activity dominates over actual computation, causing throughput to collapse.

Q: Why do Android and iOS avoid swapping to the same degree as desktop OSes? Flash storage on mobile devices wears out with repeated writes, and swapping is I/O- and battery-intensive. Both platforms prefer killing and later restarting apps over risking sustained thrashing.

References

Exit mobile version