What is thrashing and how do you deal with it?
Assesses fundamental understanding of Operating Systems conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
Thrashing is when a system spends more time paging than doing useful work. It happens when the total working set of active processes exceeds physical memory, so pages are evicted and immediately faulted back in. CPU utilisation collapses and disk I/O saturates.
Signs include high page-fault rates, low CPU utilisation, long run queues and heavy swap activity.
Causes and fixes:
- Too many processes for the available RAM: reduce the degree of multiprogramming or add memory.
- A poor replacement policy: use a good approximation of LRU such as clock, and keep frequently reused pages resident.
- A hot loop touching more data than fits in cache or memory: improve locality of reference.
- Aggressive swapping: tune swap behaviour, though on SSDs swapping can still destroy latency.
The working-set model keeps each process's recently used pages resident and refuses to admit a process that would push the total past available frames, which is a standard admission-control remedy.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.