K
Systems KeepaliveA Kordish publication
Calibration record

The server is busy. Your repair booking is waiting.

Utilization says the machine is occupied. Linux pressure signals show time lost waiting for resources. The distinction reaches all the way to the person trying to book a repair.

8 minLinux internalsUpdated
  • linux
  • psi
  • cgroup-v2
  • kubernetes

Everyday use

A booking form has a workshop behind it.

A person books a repair on a laptop while tiny backstage workers operate desks. Visual metaphor for software sharing a host.
The workshop represents shared computing resources, not a literal description of a repair company.

You choose a repair slot and press confirm. Behind the form, software competes for processor time, memory and storage access. When those resources are available, the work finishes without a story. A busy host can be serving requests perfectly well. The question is whether work is waiting long enough to affect the booking.

How it works

Busy is not the same as blocked.

A productive clerk works while another waits beside a locked equipment cabinet and a large clock. Visual metaphor for utilization versus resource stalls.
A clock represents accumulated stall time. PSI identifies resource pressure, not its root cause.

Linux Pressure Stall Information, or PSI, measures time work is stalled on CPU, memory or input/output resources. Utilization shows occupation; pressure exposes waiting. Compare the signal with request latency and the affected service. A host-wide reading alone cannot tell you which customer operation was delayed or which workload caused it.

Failure

The confirmation never arrives.

Workers queue for an overloaded shared workbench with a repair request waiting. Visual metaphor for resource contention.
The deadline and lack of a working fallback are assumptions. Pressure does not guarantee a failed booking.

In this example, competing work puts the host under memory pressure. The booking service stalls while memory is reclaimed. If that delay exhausts the request deadline, the customer may see an error instead of confirmation. They now have to retry or phone the office. No civilization-ending cascade required; a wasted afternoon will do.

Recovery

Give useful work room to finish.

An operator reduces the incoming job pile so a worker has room to finish. Visual metaphor for reducing contention.
Recovery means requests complete again. A quieter pressure graph is supporting evidence, not the whole outcome.

First match pressure with the slow service and its request queue. Reducing competing work or adding genuinely available capacity can help once the constraint is understood. Admission limits and isolated resource budgets can contain future contention. Before inviting customers to retry, verify completed bookings and check for uncertain earlier outcomes to avoid duplicates.

Operator notebook · mechanism, safe drill, commands and diagnostic signals

Core mechanism

Measure the time runnable work could not run

Pressure Stall Information reports the share and cumulative duration of time that work was delayed because CPU, memory, or I/O was unavailable.

Each resource file exposes some and full. Some means at least one task stalled while other work could continue. Full means every non-idle task stalled together; for memory or I/O, sustained full pressure is the shape of thrashing.

The avg10, avg60, and avg300 fields are recent percentages. The total field is cumulative microseconds, which makes short bursts visible even when they barely dent a long average. Utilization tells you the resource was occupied. PSI tells you useful work paid for the wait.

Operational consequence
Correlate PSI with latency and workload queues before adding capacity. A rising total during a latency spike is evidence of contention, not merely a busy machine.
Boundary
PSI names the constrained resource and quantifies delay. It does not identify the responsible process, cgroup, lock, device, or dependency by itself.

Rust removal

MemFree is a trivia answer

Linux uses otherwise idle RAM for page cache. MemFree counts pages doing almost nothing; MemAvailable estimates memory that can satisfy new work without swapping, including reclaimable cache.

Low MemFree beside stable MemAvailable can be healthy. Low MemAvailable plus growing memory pressure deserves investigation. The first number is housekeeping. The pair describes risk.

Still matters: Alerting on MemFree alone can mistake productive cache for memory shortage. Correlate available memory with pressure and request latency.

Break it safely

Scope memory pressure without creating more of it

Goal: Confirm PSI support and read the host signal. Then decide whether a systemd unit's cgroup is accumulating the same stall time.

Assumptions

  • Use a Linux host where /proc/pressure is readable.
  • Per-cgroup inspection requires cgroup v2 and a kernel built with PSI support.
  • The commands are read-only; set UNIT to a service that exists on the host.

Procedure

  1. Confirm the cgroup filesystem type before interpreting per-cgroup paths.
  2. Read CPU, memory, and I/O pressure at the host scope.
  3. Choose one systemd service and resolve its actual control-group path.
  4. Compare the unit's pressure totals with the host while the symptom is occurring.
  5. Write down what changed before proposing a limit, restart, or larger node.
Confirm the hierarchy and read host PSIbash
set -eu
printf 'cgroup fs: '
stat -fc '%T\n' /sys/fs/cgroup

for resource in cpu memory io; do
  printf '\n[%s]\n' "$resource"
  sed -n '1,2p' "/proc/pressure/$resource"
done

cgroup2fs confirms the unified hierarchy. Read both lines and keep cumulative totals as well as recent averages.

Resolve one service and read its pressurebash
set -eu
unit="${UNIT:-ssh.service}"
cg=$(systemctl show --property=ControlGroup --value "$unit")
printf 'unit=%s cgroup=%s\n' "$unit" "$cg"

for resource in cpu memory io; do
  path="/sys/fs/cgroup${cg}/${resource}.pressure"
  if test -r "$path"; then
    printf '\n[%s] %s\n' "$resource" "$path"
    sed -n '1,2p' "$path"
  fi
done

Resolve the cgroup path from systemd rather than guessing from the unit name.

Watch short windows while reproducing the symptombash
watch -n 2 'grep -H "^\(some\|full\)" /proc/pressure/{cpu,memory,io}'

Run this only while a known workload or symptom is active. Compare the moving averages and note which cumulative totals advance.

Model to carry

Capacity is inventory; pressure is waiting

Capacity says how much resource exists. Utilization says how much was occupied. Pressure says how much runnable work lost time because demand could not be served.

Picture the host as several service stations with separate queues. A full station can be efficient, while a queue whose oldest work keeps aging is a latency problem. PSI measures the waiting across CPU, memory, and I/O without pretending those queues have the same cause.

Scope matters. Host PSI describes the machine. Cgroup PSI lets you compare tenants or services. Application queues finish the path by showing which user-visible work absorbed the delay.

Boundary
Pressure is strongest as a corroborating signal. Brief stalls can be harmless when the workload has slack and no latency budget is crossed.
Failure mode
Averaging PSI across long windows can erase the burst that triggered retries. Alerting on any nonzero value creates the opposite problem and pages on ordinary contention.

Tooling weather

Kubernetes made PSI ordinary

Kubernetes 1.36 graduated kubelet PSI metrics to general availability. Supported Linux nodes can expose pressure at node, pod, and container scope through the Summary API or the kubelet cAdvisor metrics endpoint without a feature gate.

Why it matters: The GA behavior omits PSI metrics when the node cannot support them instead of exporting convincing zeroes. Kubernetes 1.37 also continues the cgroup v1 exit: kubelets default to refusing v1 nodes, so missing pressure may be a migration finding rather than a quiet workload.

Signal sources2 sources
  1. Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA

    Kubernetes · Published 2026-05-12 · Accessed 2026-09-01

  2. Kubernetes v1.37: Garhwal

    Kubernetes · Published 2026-08-26 · Accessed 2026-09-01

Check your bearings

Three checks before the pager gets a vote

Source ledger5 sources
  1. PSI - Pressure Stall Information

    Linux kernel documentation · Accessed 2026-09-01

  2. The /proc Filesystem

    Linux kernel documentation · Accessed 2026-09-01

  3. About cgroup v2

    Kubernetes · Accessed 2026-09-01

  4. Kubernetes v1.36: PSI Metrics for Kubernetes Graduates to GA

    Kubernetes · Published 2026-05-12 · Accessed 2026-09-01

  5. Kubernetes v1.37: Garhwal

    Kubernetes · Published 2026-08-26 · Accessed 2026-09-01