How to check memory pressure in Linux

A Linux host can feel slow before it runs out of memory because tasks pause while the kernel reclaims pages. Checking memory pressure separates harmless page cache use from stalls that are already delaying workloads, pushing pages into swap, or warning that a memory limit is too tight.

Pressure Stall Information, or PSI, reports how much wall-clock time tasks lose while waiting on memory reclaim. The system-wide file at /proc/pressure/memory shows host pressure, while cgroup v2 exposes matching memory.pressure files for containers, slices, and services.

Use free and vmstat beside PSI so the pressure reading has context. MemAvailable shows how much memory can be used without immediate swapping, si and so show live swap-in and swap-out activity, and avg10 or avg60 in the pressure files shows whether reclaim stalls are happening during the same window as the slowdown.

Steps to check memory pressure in Linux:

  1. Check available memory and configured swap.
    $ free -h
                   total        used        free      shared  buff/cache   available
    Mem:            11Gi       769Mi       8.1Gi        29Mi       3.1Gi        10Gi
    Swap:          4.0Gi          0B       4.0Gi

    available estimates memory that can be allocated without swapping. Low free memory alone is not pressure when available remains high because cache can be reclaimed.

  2. Sample live swap activity with vmstat.
    $ vmstat --no-first 1 3
    procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
     0  0      0 8466896 657428 2571808    0    0     0     0  963 1345  0  0 99  0  0  0
     1  0      0 8464628 657428 2571808    0    0     0     0  494  659  0  0 100  0  0  0
     0  0      0 8464628 657428 2571808    0    0     0     0  217  262  0  0 100  0  0  0

    --no-first omits the since-boot average. Sustained non-zero si means pages are being swapped in from disk during the sampled interval.

  3. Read system-wide memory PSI.
    $ cat /proc/pressure/memory
    some avg10=0.00 avg60=0.00 avg300=0.00 total=2410
    full avg10=0.00 avg60=0.00 avg300=0.00 total=2069

    some means at least one task stalled on memory reclaim. full means all non-idle tasks were stalled at the same time. avg10, avg60, and avg300 are recent percentages, while total is cumulative stall time in microseconds.

  4. Repeat the PSI read while the workload is slow.
    $ cat /proc/pressure/memory
    some avg10=0.00 avg60=0.00 avg300=0.00 total=2410
    full avg10=0.00 avg60=0.00 avg300=0.00 total=2069

    A low idle reading does not rule out earlier pressure. Capture the file during the alert window, failed request, slow build, or batch job that raised the concern.

  5. Check pressure inside the current cgroup v2 memory scope.
    $ cat /sys/fs/cgroup/memory.pressure
    some avg10=0.00 avg60=0.00 avg300=0.00 total=0
    full avg10=0.00 avg60=0.00 avg300=0.00 total=0

    Use the same file name under a service or container cgroup path when the host-wide reading is quiet but one workload still feels constrained.

  6. Check cgroup memory limit events when pressure belongs to a constrained workload.
    $ cat /sys/fs/cgroup/memory.events
    low 0
    high 0
    max 0
    oom 0
    oom_kill 0
    oom_group_kill 0

    Growing high counts mean the cgroup crossed its configured high throttle boundary. Growing oom or oom_kill counts mean allocations reached the hard failure path for that cgroup.

  7. Match the readings to the reported slowdown.

    Sustained non-zero avg10 or avg60, non-zero full pressure, repeated si in vmstat, or rising cgroup high events all point to memory contention. Zero PSI averages, zero swap-in, and unchanged cgroup events during the affected window point elsewhere, such as CPU run queue, storage I/O wait, or application-level locking.