What is thrashing in an operating system, and how can it be prevented?
Thrashing is when a system spends most of its time moving pages between RAM and disk instead of running programs, because the running processes together need more memory than is available. It is prevented by giving each process enough frames for its working set, controlling page-fault rate, and reducing the number of running processes.
Explain it simply
Imagine studying for an exam at a tiny desk that holds only two books, while the chapter you are on needs five. You open book A, then you need book B, so you put A back on the shelf. Then you need A again, so B goes back. You spend the whole evening walking to the shelf and almost no time reading. That is thrashing.
In an OS, the desk is RAM and the shelf is the disk. When processes do not have enough frames for the pages they are actively using, almost every memory access causes a page fault. The disk becomes the bottleneck, the CPU sits idle waiting, and the whole machine becomes extremely slow.
Example
A server with 8 GB of RAM is running a few services that together need about 6 GB. Someone starts four more memory-heavy jobs, so the combined active memory becomes about 12 GB.
- Each process keeps faulting because its pages were just evicted to make room for another process.
- The disk light stays on, and
vmstatshows high swap-in and swap-out. - CPU utilisation drops, because processes are waiting for disk.
vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 9 2310456 51204 1200 60232 9120 8840 12400 9300 3100 4200 4 6 3 87 0Here si and so (swap in and out, KB per second) are high, b shows 9 processes blocked, and wa (time waiting for I/O) is 87%. Very little real work (us 4%) is happening.
How it works
A program does not touch all of its memory evenly. Over any short period it mostly uses a small set of pages; this is called locality of reference, and that set is its working set.
As long as the sum of all working sets fits in RAM, page faults are rare. Once it does not fit, processes start stealing each other's frames, and fault rates shoot up.
The classic trap: an old-style scheduler sees CPU utilisation falling and thinks the CPU is under-used, so it admits more processes. That increases memory pressure further, which lowers CPU utilisation again. If you plot CPU utilisation against the number of processes (the degree of multiprogramming), it rises, peaks, and then falls sharply. The falling part is thrashing.
Real-world use
- A laptop with too many browser tabs and an IDE open freezes and the disk runs continuously.
- In containers, a memory limit set too low can make an app spend its time reclaiming memory instead of serving requests.
- Database servers are tuned so their buffer cache plus everything else fits in RAM with margin.
Common mistakes
- Thinking more swap space fixes thrashing. More swap only lets you over-commit further; the problem is too little RAM for the active pages.
- Confusing a high page-fault count at program start (normal, pages loading for the first time) with thrashing (sustained high faults with low useful work).
- Assuming a faster CPU helps. The CPU is idle; the bottleneck is disk I/O.
What to say in the interview
"Thrashing is a state where the system spends more time servicing page faults than executing processes. It happens when the total working set of the active processes is larger than physical memory, so pages are constantly evicted and immediately needed again. The sign is very high paging activity with falling CPU utilisation. It is prevented by using the working set model to give each process enough frames, by page-fault frequency control, which adds frames when a process faults too often and takes them away when it faults rarely, and by suspending or swapping out whole processes to reduce the degree of multiprogramming. Using local rather than global page replacement also limits the damage to the process that is short of memory."
Follow-up questions
- What is the working set model, and how is the window size chosen?
- Explain page-fault frequency (PFF) control.
- What is the difference between local and global page replacement?
- How does the Linux OOM killer relate to thrashing?
Go deeper
Read these once the basics above feel easy.
Working set model. The working set WS(t, Δ) is the set of pages a process referenced in its last Δ memory references. If the total demand D = Σ |WSᵢ| is greater than the number of frames m, the OS suspends a process and frees its frames. Δ too small misses the real locality; Δ too large covers several localities and wastes frames. Tracking exact working sets is costly, so it is approximated with reference bits sampled on a timer.
Page-fault frequency. A simpler, direct control: set an upper and lower bound on each process's fault rate. Above the upper bound, give it more frames; below the lower bound, take some away. If no free frames exist when a process needs more, suspend a process.
Local vs global replacement. With global replacement a process can take frames from any other process, so one memory-hungry process can push everyone into thrashing. Local replacement takes victims only from the faulting process's own frames, which keeps the problem contained but can leave other frames under-used.