Imagine a service has a 20 GiB virtual address space and an 8 GiB resident set, but neither number directly answers the most important performance question:
How much memory does the service need for the pages it is actively using now?
A process rarely uses every mapped page with equal frequency. It moves through phases: parsing input, updating an index, running a query, serializing a response, or performing background maintenance. Each phase repeatedly touches a smaller collection of pages.
That actively used collection is the process's working set.
When physical memory can hold the working sets of active workloads, most references hit resident pages and execution makes progress. When it cannot, the operating system repeatedly evicts pages that are needed again almost immediately. Fault handling and data movement begin to dominate useful work.
That failure mode is thrashing.
Thrashing occurs when a workload has too few frames for its active pages and spends most of its time faulting, reclaiming, and restoring pages instead of executing useful instructions.
Working sets explain why a process can have a huge address space yet run efficiently, while a much smaller process can perform terribly under memory pressure.
This chapter defines and calculates working sets, relates them to RSS and frame demand, follows the thrashing cycle, and explains page-fault-frequency control, refault evidence, mitigation, and capacity planning.