How to Monitor Linux Page Cache Hit Ratios per Process in Real-Time Using cachetop

In high-throughput Linux environments, the kernel page cache acts as the primary buffer between fast system memory and comparatively slow physical storage drives. When applications read and write data, servicing requests from DRAM page cache yields microsecond responses, whereas page cache misses force blocking I/O calls to underlying NVMe or SATA storage. While system-wide tools like cachestat display aggregate hit and miss ratios across the entire OS, they cannot identify which specific workloads are causing cache thrashing. The cachetop tool from the BCC (BPF Compiler Collection) suite provides an interactive, top-like display showing real-time page cache read hits, writebacks, and hit ratios broken down per process.

How cachetop Instruments the Linux Page Cache

The Linux page cache stores file-backed memory pages in 4 KiB chunks. When an application attempts a file read, the kernel enters page lookup routines (such as add_to_page_cache_lru and mark_page_accessed). Using dynamic eBPF kprobes, cachetop hooks directly into these core memory management routines without altering running binaries.

Every time a process requests a page, cachetop checks whether the page was already resident in memory (a cache hit) or had to be read from disk (a cache miss). It simultaneously tracks memory writeback operations where dirty pages are queued to disk. By calculating hit percentages for every active process, cachetop highlights whether database engines or background file transfers are exhausting available cache capacity.

Installing Prerequisites and BCC Packages

To run cachetop, your Linux host needs kernel header packages matching your running kernel and the BCC tools suite. On Debian or Ubuntu systems, install the packages using apt:

sudo apt update && sudo apt install -y bpfcc-tools linux-headers-$(uname -r)

On enterprise distributions such as Red Hat Enterprise Linux, Rocky Linux, or Fedora, use dnf:

sudo dnf install -y bcc-tools kernel-devel-$(uname -r)

The utility installs to /usr/sbin/cachetop or /usr/sbin/cachetop-bpfcc. Because eBPF programs monitor privileged kernel functions, running cachetop requires root or sudo execution rights.

Running cachetop in Real-Time Interactive Mode

To launch the live monitoring interface, execute the utility in terminal:

sudo cachetop

The terminal clears and presents a dynamic screen refreshed every second:

14:35:10 Buffers: 248MB / Cached: 14210MB
PID      UID      CMD              HITS     MISSES   DIRTIES  READ_HIT%  WRITE_HIT%
1420     1000     postgres         84210    120      412      99.9%      95.2%
3102     0        dockerd          1402     4        18       99.7%      100.0%
9820     1000     rsync            5120     1840     3200     73.6%      62.1%
1104     33       nginx            18920    2        0        100.0%     0.0%

The status header displays total buffer and page cache allocations. The tabular columns detail:

  • PID / UID: Process ID and user ID running the workload.
  • CMD: Name of the active process.
  • HITS: Total number of page cache read hits during the sampling interval.
  • MISSES: Total page cache misses requiring physical disk reads.
  • DIRTIES: Number of newly written memory pages modified in the cache.
  • READ_HIT%: Percentage of read operations satisfied directly from memory.
  • WRITE_HIT%: Proportion of write requests successfully cached before flushing.

Adjusting Refresh Intervals

By default, cachetop polls and recalculates statistics every second. In production environments where sampling overhead must be kept to an absolute minimum, or when monitoring steady-state background trends, you can pass an interval in seconds as a command-line argument:

sudo cachetop 5

This command refreshes the display every 5 seconds, providing a smoothed average of cache efficiency that prevents short burst spikes from skewing your analysis.

Diagnosing Cache Thrashing and Disk Saturation

A healthy Linux server typically maintains a READ_HIT% above 95% for production database and web services. When you observe a process dropping below 80% with climbing MISSES, that application is actively thrashing memory and forcing frequent disk reads.

When investigating poor hit ratios, pair cachetop with other specialized eBPF tools to gain full-stack visibility. Use biosnoop to observe physical disk latency when cache misses hit the drive queue, examine kernel execution delays with funclatency, and verify whether memory allocation pressure is draining buffers via slabratetop.

Press Ctrl + C at any time to exit the cachetop dashboard and return to your terminal prompt.

Get the best tech tips delivered straight to your inbox.

Join thousands of readers mastering Apple, Google, Microsoft, and Linux.