Linux performance / Basic: measurement and resource signals / Lesson 4
Read memory use without fearing cache
Distinguish address space, resident pages, shared mappings, cache, and page faults before diagnosing memory scarcity.
On this page
Lesson goals
- Interpret virtual, resident, proportional, and available memory.
- Separate reclaimable cache from unreclaimable demand.
- Use faults and swap activity as contextual evidence.
Allocation is not the same as residency
Virtual address space describes mappings and reservations rather than a direct claim on the same quantity of physical RAM. A large virtual size can be normal for a runtime that reserves an address range. Resident set size counts currently resident pages but includes shared pages, so adding process RSS values can double count shared memory. Proportional set size divides shared pages among their mappings and supports a different accounting question. Always state whether the investigation concerns process growth, host availability, or a cgroup limit; these boundaries need different measurements.
Cache is useful work retained in memory
Linux uses otherwise available memory to cache file data and metadata. Low completely free RAM can therefore coexist with healthy availability. Some cache can be reclaimed, but dirty pages need writeback and reclaim has cost; available memory is an estimate rather than a guarantee of zero-latency allocation. Anonymous memory belongs to allocations such as heaps and stacks and follows a different reclaim path. Do not clear caches to make a dashboard look empty. That destroys a useful baseline, changes storage demand, and can create the slowdown being investigated.
grep -E '^(MemTotal|MemFree|MemAvailable|Cached|Dirty|Writeback|SwapTotal|SwapFree):' /proc/meminfoFields are read-only observations with documented units. Compare Dirty and Writeback with I/O evidence; this command neither drops caches nor changes VM policy.
Faults describe mapping work, not always disk errors
A page fault occurs when an access needs the kernel to resolve a mapping or obtain a page. Minor faults can be satisfied without the major-fault path, while major faults commonly require backing-store I/O. Neither category is a hardware failure merely because it is called a fault. Initializing a fresh application can legitimately cause many minor faults. Look at rates, application phase, and latency correlation. A cumulative lifetime fault count cannot prove present pressure, and a major-fault increase needs interpretation alongside file access, swap traffic, and storage response.
cat /proc/4242/smaps_rollup
vmstat 1 5PID 4242 represents a prepared lab process. smaps_rollup availability and access depend on the kernel and permissions; vmstat interval rows help distinguish ongoing swap traffic from old allocated swap.
Swap allocation and swap activity differ
Nonzero used swap can remain after earlier pressure and does not by itself prove current thrashing. Repeated page movement, sustained reclaim, and user-visible stalls provide stronger evidence. Storage backing for swap and application access patterns influence the cost. A host can have available RAM while a container reaches its own memory boundary. Conversely, apparent process growth may reflect shared mappings or file cache accounting. Compare the appropriate memory scope over time and preserve the workload phase before proposing any change to swap or swappiness; no universal value fits every latency and recovery objective.
Ask what becomes unavailable and to whom
Track process allocation, working set, available host memory, cgroup events, and pressure at matching intervals. A growing heap suggests a different investigation from a stable heap whose cache is repeatedly evicted. Inspect application retention and concurrency before adjusting global VM behavior. Establish a healthy comparison and decide whether reclaim is merely present or actually harms the stated service objective. Keep any experiment on a disposable copy and preserve enough capacity for diagnostics and recovery. The goal is sustained useful work, not maximizing free memory at the expense of every cache hit.
Common errors and fixes
Calling low free RAM a leak
- Why it happens
- Reclaimable cache was included without category analysis.
- How to fix it
- Inspect availability, mappings, and growth over time.
- Prevent it next time
- Define the memory boundary and categories in alerts.
Adding RSS as exact unique host usage
- Why it happens
- Shared resident pages were counted repeatedly.
- How to fix it
- Use proportional or scope-appropriate accounting.
- Prevent it next time
- Document what each process metric includes.
Treating allocated swap as current thrashing
- Why it happens
- A stored quantity was confused with activity.
- How to fix it
- Correlate interval swap movement, reclaim, and latency.
- Prevent it next time
- Keep rates and gauges separate.
Check your understanding
1. A host has little free memory, large cache, healthy available memory, and no stalls. Is clearing cache justified?
Show worked solution
No evidence identifies harmful pressure. Cache can be useful and reclaimable; clearing it changes the workload and causes extra reads. Preserve the baseline and compare application latency, reclaim activity, and scope-specific limits before proposing a change.
2. Two processes each report 500 MiB RSS and share many pages. Can you claim exactly 1 GiB unique consumption?
Show worked solution
No. RSS includes shared pages in both processes. Inspect PSS and the required host or cgroup accounting boundary, remembering that other kernel memory and page-cache usage may also matter to the total capacity question.
Key takeaways
- Separate reservations, resident pages, cache, and active pressure.
- Measure rates and user impact before changing VM policy.