Thrashing in Operating Systems: Causes, Mechanisms, and Control

Thrashing is a severe virtual memory performance collapse in which the operating system spends most of its time handling page faults and swapping pages between RAM and secondary storage instead of executing instructions.2 In practical terms, a process or system is said to be thrashing when paging overhead dominates useful computation, so throughput falls sharply even while memory and disk activity surge.2

Thrashing is tightly connected to the idea of a process working set—the pages it is actively using over a recent interval.2 When the combined working sets of active processes cannot fit into available physical frames, page replacement becomes extremely frequent, and the system repeatedly evicts pages that will soon be needed again.2 This creates a self-reinforcing cycle of high page-fault rates, long I/O waits, and poor CPU productivity.2

A concise way to express the risk is:

$$D = \sum_i WSS_i$$

where $WSS_i$ is the working-set size of process $i$, and $D$ is total frame demand. If

$$D > m$$

where $m$ is the number of available physical frames, then at least one process is likely to thrash because memory demand exceeds available memory.

Footnotes

1. Thrashing (computer science) - Defines thrashing as overwhelming time spent resolving page faults rather than computing. ↩

2. What is Thrashing in OS? Causes, Effects, and Solutions - codeCake - Explains thrashing as excessive swapping due to insufficient memory frames. ↩ ↩²

3. Thrashing - Memory Management - Introduction to Operating Systems - Notes that a thrashing process spends more time paging than executing. ↩ ↩²

4. Operating System - Thrashing - Describes symptoms such as high page-fault rates and low CPU utilization. ↩ ↩²

5. Thrashing and Working Sets - Stanford CS 140 - Connects thrashing to overcommitted memory and the working-set idea. ↩ ↩²

6. Operating Systems: Virtual Memory - UIC Course Notes - Presents the working-set model and the condition $D > m$ for thrashing. ↩ ↩² ↩³

What Thrashing Looks Like in a System

Thrashing is not merely “slow memory”; it is a pathological operating state. The classic symptoms are a very high page-fault rate, intense paging disk activity, and low effective CPU utilization for useful work.2 Historically, early schedulers sometimes misread low CPU utilization as a sign that the machine could admit more processes, but adding processes increased memory pressure further and made thrashing even worse.

The underlying reason is the locality of reference property of programs. Programs usually access a limited set of pages for a while, called a locality. If RAM can hold the pages of the current locality, execution proceeds with few faults. If not, each access may trigger eviction of another soon-needed page, causing a cascade of faults.2

A simplified comparison is shown below:

This is why thrashing is often described as a collapse of the balance between computation and memory service.2

Footnotes

1. Operating System - Thrashing - Describes symptoms such as high page-fault rates and low CPU utilization. ↩ ↩²

2. Operating Systems: Virtual Memory - UIC Course Notes - Presents the working-set model and the condition $D > m$ for thrashing. ↩ ↩² ↩³ ↩⁴ ↩⁵

3. Thrashing and Working Sets - Stanford CS 140 - Connects thrashing to overcommitted memory and the working-set idea. ↩

4. Thrashing (computer science) - Defines thrashing as overwhelming time spent resolving page faults rather than computing. ↩

Main Cause of Thrashing

The main cause of thrashing is memory overcommitment: the system allows too many active processes, or processes with too large a memory footprint, so that the total demand for frames exceeds available physical memory.2 In more formal terms, thrashing begins when the sum of current working sets is larger than the frame supply:

$$\sum_i WSS_i > m$$

When this happens, the system cannot keep each active process's current locality resident in memory.

This cause is often expressed operationally as an excessively high degree of multiprogramming.2 If more processes are admitted into memory than RAM can support, each process receives too few frames. Then page replacement becomes destructive: the system removes pages that remain part of active localities, guaranteeing more future faults.2

Several contributing factors may intensify the problem, but they are usually secondary to the core issue of insufficient frames for active demand:

• Too many simultaneously active processes.2
• Too little physical memory for current workloads.2
• Global replacement policies that let one process steal frames from others, spreading instability system-wide.2
• Sudden spikes in page demand from memory-intensive programs.

In short, the principal cause is not paging itself; it is admitting more active memory demand than the machine can hold.2

Footnotes

1. Thrashing and Working Sets - Stanford CS 140 - Connects thrashing to overcommitted memory and the working-set idea. ↩ ↩² ↩³

2. Operating Systems: Virtual Memory - UIC Course Notes - Presents the working-set model and the condition $D > m$ for thrashing. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

3. Operating System - Thrashing - Describes symptoms such as high page-fault rates and low CPU utilization. ↩ ↩² ↩³

4. What is Thrashing in OS? Causes, Effects, and Solutions - codeCake - Explains thrashing as excessive swapping due to insufficient memory frames. ↩

5. Thrashing - Memory Management - Introduction to Operating Systems - Notes that a thrashing process spends more time paging than executing. ↩

6. Thrashing (computer science) - Defines thrashing as overwhelming time spent resolving page faults rather than computing. ↩

How We Can Limit the Effects of Thrashing

Operating systems limit thrashing by ensuring that active processes have enough frames to hold their current localities and by reducing memory pressure when they do not.2 The two classical control techniques are the working-set model and page-fault frequency.2

1. Working-Set Control

The working-set model estimates the pages a process has used in a recent window of execution. The OS then tries to keep those pages in memory. If the total working-set demand of all active processes exceeds available frames, the OS reduces the active set of processes by suspending or swapping out some of them.2 This idea is sometimes described using a balance set.2

2. Page-Fault Frequency Control

Instead of explicitly estimating the full working set, the OS can monitor each process's page-fault rate.2 If the rate is too high, the process is given more frames. If free frames do not exist, the system must reclaim them or suspend some processes. If the rate is very low, some frames can be taken back and reassigned efficiently.

3. Lower the Degree of Multiprogramming

If the machine is overloaded, the most direct corrective action is to run fewer active processes at once.2 This reduces total frame demand and often breaks the thrashing cycle quickly.

4. Prefer Local Replacement in Critical Cases

Local replacement can limit the spread of damage because one badly faulting process cannot steal arbitrary pages from others.2 Although local policies do not eliminate thrashing by themselves, they can contain its impact.

5. Increase Physical Memory

Adding RAM increases the number of frames available to satisfy working sets.2 This is not always the only solution, but it is often the simplest hardware-level remedy when workloads have outgrown the current memory capacity.

Footnotes

1. Thrashing and Working Sets - Stanford CS 140 - Connects thrashing to overcommitted memory and the working-set idea. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

2. Operating Systems: Virtual Memory - UIC Course Notes - Presents the working-set model and the condition $D > m$ for thrashing. ↩ ↩² ↩³ ↩⁴ ↩⁵

3. Thrashing - Memory Management - Introduction to Operating Systems - Notes that a thrashing process spends more time paging than executing. ↩ ↩² ↩³ ↩⁴

4. Operating System - Thrashing - Describes symptoms such as high page-fault rates and low CPU utilization. ↩ ↩²

5. What is Thrashing in OS? Causes, Effects, and Solutions - codeCake - Explains thrashing as excessive swapping due to insufficient memory frames. ↩

Exam-Oriented Conclusion

Thrashing is a condition of excessive paging in which the system spends more time moving pages between memory and disk than performing useful computation.2 Its main cause is excessive memory demand—usually due to too high a degree of multiprogramming—so that the combined working sets of active processes exceed available physical frames.2 The standard methods to limit its effects are to use the working-set model, control page-fault frequency, reduce the degree of multiprogramming, prefer local replacement where appropriate, and increase physical memory when necessary.3

Footnotes

1. Thrashing (computer science) - Defines thrashing as overwhelming time spent resolving page faults rather than computing. ↩

2. Thrashing - Memory Management - Introduction to Operating Systems - Notes that a thrashing process spends more time paging than executing. ↩ ↩²

3. Thrashing and Working Sets - Stanford CS 140 - Connects thrashing to overcommitted memory and the working-set idea. ↩ ↩²

4. Operating Systems: Virtual Memory - UIC Course Notes - Presents the working-set model and the condition $D > m$ for thrashing. ↩

5. What is Thrashing in OS? Causes, Effects, and Solutions - codeCake - Explains thrashing as excessive swapping due to insufficient memory frames. ↩