Fast triage

1 — Record when and what is slow

date -Is
uptime

2026-09-09T19:14:32+05:30
 19:14:32 up 18 days,  6:21,  2 users,  load average: 9.84, 6.12, 3.47

What to check: the 1/5/15-minute load trend and the exact incident time. Here the recent load is rising sharply relative to the longer windows, which tells you pressure increased recently—but not whether CPU or I/O caused it. Next: inspect CPU states and processes in top.

Record whether the problem is login latency, HTTP requests, database calls, batch jobs or the whole host. The timestamp lets you correlate application and infrastructure logs later.

2 — Look at CPU states and top consumers

top

%Cpu(s): 18.2 us,  4.1 sy,  0.0 ni, 42.7 id, 34.4 wa,  0.0 hi,  0.6 si,  0.0 st

    PID USER      %CPU %MEM COMMAND
  2187 postgres   31.4 12.8 postgres
 18421 app        18.7  7.1 java

What to check: CPU states plus whether one process dominates. In this example CPU is not saturated; wa=34.4 is the stronger clue, so investigate I/O rather than blaming the busiest process. Next: continue to memory/filesystem checks, then use vmstat/iostat if I/O remains the leading hypothesis.

Use the CPU-state and process sections first; see Understanding the Linux top Command for every field. If user/system CPU is saturated and a process dominates, continue with High CPU Usage. If load is high but CPU is mostly idle or I/O wait is elevated, do not stop at CPU.

3 — Check memory pressure

free -h
cat /proc/swaps

               total        used        free      shared  buff/cache   available
Mem:            15Gi         9Gi       610Mi       220Mi        5.4Gi        5.0Gi
Swap:          2.0Gi       128Mi       1.9Gi

Filename  Type  Size     Used   Priority
/swapfile file  2097148  131072 -2

What to check: available memory first, then swap activity—not merely low free. This snapshot still has about 5 GiB available, so it does not support severe memory pressure by itself. Next: if available memory is low or swapping is active, follow the memory runbook; otherwise continue.

Focus on available memory and whether swap use/pressure is consistent with the slowdown. If processes are disappearing or memory is exhausted, use High Memory / OOM Killed.

4 — Rule out a full filesystem or inode exhaustion

df -h
df -i

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       100G   91G  4.0G  96% /

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/sda2      6553600  812400 5741200   13% /

What to check: identify the affected mount and compare byte usage with inode usage. Here / is critically high on bytes while inodes are healthy, so the next branch is disk-capacity investigation—not inode cleanup. Next: use the Disk Usage runbook to find which directory/file/process owns the growth.

A nearly full filesystem can cause application failures, logging problems and database issues. If capacity or inodes are constrained, continue with Disk Usage / No Space Left.

5 — Take a short system-wide sample

vmstat 1 5

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  4      0 412000  88000 912000    0    0  8240  1532 3120 5510 18  5 42 35  0

After the first historical row, inspect the interval rows. r is runnable work, b is tasks blocked on I/O, si/so show swap activity, and wa is I/O wait. Persistent blocked tasks plus I/O wait is a reason to inspect storage rather than CPU.

6 — Check pressure information when available

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

some avg10=1.20 avg60=0.74 avg300=0.22 total=...
some avg10=0.00 avg60=0.00 avg300=0.00 total=...
some avg10=18.42 avg60=11.06 avg300=4.31 total=...
full avg10=7.18 avg60=3.22 avg300=1.10 total=...

What to check: compare recent avg10 pressure across resources and look for a signal that matches the incident window. Here I/O pressure is far stronger than CPU or memory pressure. PSI is supporting evidence, not a universal threshold. Next: correlate with vmstat/iostat and the user-visible slowdown.

PSI measures time workloads are stalled because resources are contended. Compare CPU, memory and I/O pressure to help identify which resource is actually delaying work.

7 — Route the incident

Verify

Verify the original user-visible symptom—not just a metric. Confirm the affected request/job/login is healthy and the resource signal that led you to the root cause has returned to its normal baseline.