Course contentsShow
← Linux
Lesson 1549 of 1,81913. Containerization Primitives and NamespacesFree lesson

Profiling Page Fault Rates

Investigate memory paging performance within constrained container memory environments.

In this lesson, you will learn how to measure the frequency of page faults within constrained container environments to identify memory pressure and performance bottlenecks.

The Cost of Paging in Containers

When a process inside a container accesses a virtual memory address that isn't mapped to physical RAM, the kernel triggers a page fault. While minor faults (remapping existing pages) are routine, major faults—where the kernel must fetch data from disk—severely degrade performance. In a containerized environment, if a cgroup’s memory limit is tight, the kernel may aggressively reclaim pages, forcing the container into a cycle of constant paging, known as "thrashing."

Profiling with perf

To profile these events, we use perf, which hooks into the kernel’s memory management tracepoints. Specifically, we look for exceptions:page_fault_user and exceptions:page_fault_kernel.

You can monitor the page fault rate for a specific process (or all processes within a container) using the following command:

# Profile page faults for a specific process ID inside a container
perf stat -e page-faults -p <pid> sleep 10

# Aggregate page faults globally to see the system impact
perf record -e exceptions:page_fault_user -a -g -- sleep 5
perf report

Analyzing Memory Pressure

When monitoring, look for a high ratio of page faults relative to the container’s memory.stat values. If you notice a high count of pgmajfault in /sys/fs/cgroup/memory/memory.stat alongside a high perf page-fault rate, your container is likely oversubscribed.

Because containers share the same physical memory management hardware, a "noisy neighbor" or an improperly sized container limit can force the kernel to evict pages constantly. By using perf to capture the call graph (-g), you can pinpoint exactly which code paths—such as large object allocations or inefficient file I/O—are triggering these faults, allowing you to optimize memory access patterns or adjust your cgroup limits accordingly.

Key Takeaway: Monitoring page fault rates allows you to distinguish between healthy, expected memory allocation and performance-killing disk thrashing caused by strict container memory limits.