Linux PSI 怎么定位 CPU、内存和 IO 压力：/proc/pressure 与阈值告警实战

线上接口偶发变慢时，top 观测到的 CPU 使用率只有 35%，磁盘也没有明显打满，但请求延迟已经从 80ms 涨到 900ms。这个时候只看 load average 或单个进程的 CPU 百分比，很容易把“正在等待资源”的时间漏掉。Linux PSI（Pressure Stall Information）正是用来统计：有多少任务在等 CPU、内存或 IO，以及这种等待已经持续了多久。

为什么 CPU 不高，接口仍然会被拖慢

CPU 使用率回答的是“处理器正在忙多少”，而 PSI 关注“任务因为资源不足而停了多久”。例如线程在等待内存回收、磁盘请求完成或可运行任务获得 CPU 时间片时，业务延迟会继续增加，但瞬时 CPU 曲线未必同步升高。

PSI 把这种影响按最近 10 秒、60 秒和 300 秒的窗口计算成百分比，并把累计停顿时间放在 total 中。它不是某个进程的耗时，也不是磁盘利用率；它更像一张“业务生产时间被资源等待吃掉了多少”的统计账单。

先读懂 /proc/pressure 的四组字段

先在一台启用 PSI 的 Linux 主机上执行：

for f in /proc/pressure/cpu /proc/pressure/memory /proc/pressure/io; do
  echo "--- $f"
  cat "$f"
done

CPU 通常只有 some 行，内存和 IO 还会提供 full 行。字段的含义可以先按下面的方式记：

full 不是“压力更大”的简单别名。它表示所有非空闲任务同时被卡住；如果 memory 的 full avg10 持续抬头，通常比单独看到 some 更值得优先处理。

把 PSI 读数接到一次真实排查里

建议按“资源类型—持续时间—业务症状”的顺序判断。一次采样只说明一个瞬间，至少连续读取几次，观察 avg10 是否和接口延迟同时上升。

watch -n 1 'date; cat /proc/pressure/cpu; cat /proc/pressure/memory; cat /proc/pressure/io'

CPU PSI 上升：先区分调度争用与单进程忙

cpu some 上升说明有任务没有及时拿到 CPU，但不代表某个进程已经失控。继续看 vmstat 1 的运行队列、上下文切换和 steal 时间；虚拟机里的 steal 偏高时，根因可能在宿主机资源争用。只有把 PSI、运行队列和业务延迟对齐，才适合决定是否迁移实例或降低批任务优先级。

memory PSI 上升：不要直接等同于 OOM

内存压力可能来自回收、匿名页换入换出或工作集超过当前余量。先看 memory.current、memory.events（如果使用 cgroup v2）和 vmstat 1 的 swap 活动，再检查应用是否在同一时间出现 GC 或缓存抖动。PSI 告诉你“等待变多了”，它本身不能证明已经发生 OOM kill。

io PSI 上升：把等待与设备队列对上

io full 持续上升时，所有非空闲任务都可能在等 IO。用 iostat -xz 1 对照设备的 await、队列长度和利用率；如果只有一个批处理任务制造大量同步写入，可以先调整它的并发和优先级，而不是给整台机器增加无关的 CPU。

用 PSI 触发器把“变慢”变成可处理事件

内核 PSI 文档定义的触发器格式是 。例如下面的设置表示：内存在任意 1 秒窗口内累计有 150ms 的 some 停顿时，等待文件描述符收到事件。

psi-monitor --file /proc/pressure/memory \
  --trigger "some 150000 1000000" \
  --event POLLPRI --action shed-batch

生产环境不要把上面的示例直接当成万能阈值。阈值应该来自业务基线：先记录正常高峰的 avg10、接口 P95 和批任务完成时间，再把“持续异常 + 可执行动作”绑定起来。比如内存 PSI 触发后暂停低优先级压缩任务，恢复后再放开；如果没有对应的降级动作，告警只会变成噪声。

cgroup v2 场景下，为什么要看 memory.pressure

整机的 /proc/pressure/memory 可能看起来平稳，但某个容器或服务已经被自己的内存边界拖慢。启用 cgroup v2 后，每个 cgroup 文件夹可以提供同样格式的 cpu.pressure、memory.pressure 和 io.pressure。这时要同时记录服务所属 cgroup 的路径、内存上限和 PSI，避免把单个租户的问题误判成整机故障。

systemctl show --property=ControlGroup batch-worker.service
cat /sys/fs/cgroup//memory.pressure
cat /sys/fs/cgroup//memory.events

如果 cgroup 的 memory.pressure 持续升高而整机指标正常，优先检查该服务的内存上限、缓存策略和并发配置；如果两者都升高，再扩大到主机容量和同机任务的资源分配。

常见问题：PSI 指标怎么避免误读

PSI 的 avg10 是 CPU 使用率吗？

不是。它是最近 10 秒内任务因指定资源停顿的时间比例，和 CPU busy、磁盘利用率是不同维度。

看到 memory full 就一定会 OOM 吗？

不一定。memory full 说明所有非空闲任务同时受到内存压力影响，是否 OOM 还要结合 memory.events、内核日志和实际回收情况判断。

为什么只看 avg300 会错过故障？

300 秒窗口会把短时尖峰摊平。突发延迟排查应先看 avg10，再用 avg60 和 avg300 判断事件是否持续。

所有 Linux 都有 /proc/pressure 吗？

取决于内核是否启用了 PSI 配置以及运行环境是否暴露该接口。文件不存在时先确认内核配置和发行版限制，不要用空值代替零压力。

把 PSI 纳入日常排查清单

• 先采集 CPU、memory、io 三个文件的 some，再按需看内存和 IO 的 full。
• 把 avg10 与接口 P95、队列长度、批任务耗时放在同一时间轴上。
• 使用 vmstat、iostat、memory.events 做交叉验证，不根据 PSI 单项指标下结论。
• 只有在触发器对应明确的限流、迁移、暂停或恢复动作时，才把它接入自动化处理。

PSI 的价值不在于再增加一条监控曲线，而是把“机器看起来没满，但业务已经在等”变成可以量化和定位的证据。先找到是哪一种等待在吞噬生产时间，再针对性调整调度、内存、IO 或业务负载，排查路径会比盯着 load average 更短。