Operating Systems Practice Question 7: Thrashing Working Sets
Operating Systems · Test 1 · question 7 of 10
A batch server runs 40 worker processes. After the job size grew, the combined memory each worker actively uses is now well above the machine's physical RAM. Monitoring shows the swap device busy 100% of the time, a very high page-fault rate, and CPU utilization that has fallen to about 10%. Jobs finish far slower than before.
An operator suggests adding more workers "to use the idle CPU". What should be done instead?
Show answer and explanation
Answer:
This is thrashing: memory is oversubscribed, so the system constantly pages; each process evicts pages another process is about to need, and everyone spends most of their time waiting for page faults to be served from disk. The CPU is idle *because* every process is blocked on paging. The classic response is admission control: run only a subset of processes, so the working sets (pages actively in use) of the ones that run fit in memory and they make real progress. OSTEP's summary is that it is sometimes better to do less work well than to try to do everything at once poorly. Adding RAM would also help, but among the options, D is the one that addresses the cause.
Option A is the classic trap: more processes means more memory demand, more page faults, and even lower CPU utilization. The idle CPU is a symptom of memory pressure, not spare capacity.
Option B is wrong: the workers are not waiting for the CPU; they are waiting for the disk. Shorter slices add context-switch overhead and switch in yet more working sets per second.
Option C is wrong: low CPU utilization here means the CPU is *not* the bottleneck. A faster CPU would simply sit idle waiting on the same page faults.
Reference: OSTEP - Beyond Physical Memory: Policies