Linux PSI 指标怎么判断 CPU 内存与 I/O 压力

判断 Linux CPU、内存和 I/O 是否真的形成压力，不要只看利用率，而要看任务因资源竞争而停止推进的时间。PSI（Pressure Stall Information）把这种停顿按资源类型记录在 /proc/pressure/cpu、/proc/pressure/memory 和 /proc/pressure/io 中。

官方文档：https://docs.kernel.org/accounting/psi.html

实用判断法是：先用 some 判断是否已有部分任务被资源拖住，再用 full 判断工作负载是否接近整体停摆；用 avg10 看突发、avg60 看趋势、avg300 看基线，最后把变化与业务延迟、吞吐及同一时间范围内的系统指标对齐。不存在适合所有主机的统一 PSI 百分比阈值。

先把 PSI 看成等待时间比例

PSI 不是 CPU 使用率、剩余内存或磁盘带宽。它回答的是另一个问题：在最近一段时间里，有多少墙上时钟时间因为 CPU、内存或 I/O 竞争，导致任务无法继续做有效工作。

# 同时读取三类系统级压力，先保留原始字段，不用 grep 提前丢信息
for resource in cpu memory io; do
  echo "===== ${resource} ====="
  cat "/proc/pressure/${resource}"
done

# 每两秒观察一次短窗口变化，适合复现问题时与业务请求同步对照
watch -n 2 'cat /proc/pressure/cpu; cat /proc/pressure/memory; cat /proc/pressure/io'

典型输出有 some 和 full 两行，每行包含 avg10、avg60、avg300 和 total。前三个值是最近 10 秒、60 秒和 300 秒窗口内的停顿时间比例，单位是百分比；total 是自启动以来累计停顿时间，单位是微秒。

一个容易踩坑的例外是系统级 cpu full。Linux 内核文档明确说明，它在 system level 没有定义；从 Linux 5.13 起为了兼容仍会展示，但值固定为 0。因此主机级 CPU 压力主要看 cpu some，不要因为 cpu full=0 就断言 CPU 没有竞争。

模式命名：三窗口、两范围、一业务基线

可以把 PSI 判断方法记成“三窗口、两范围、一业务基线”。它不是内核规定的告警标准，而是一种运维判断模式：

• 三窗口：avg10 突然抬高而 avg60、avg300 仍低，通常是短突发；三者一起升高，说明压力已持续并逐渐成为基线。
• 两范围：some 高说明部分工作受阻，full 同时高说明所有非空闲任务都被同一资源卡住，后者对内存和 I/O 更值得紧急处理。
• 一业务基线：PSI 的意义要由请求延迟、超时率、队列长度或任务吞吐来确认。同一个比例对批处理节点和在线 API 节点可能代表完全不同的风险。

这套模式适合“利用率看起来还行，但应用偶尔变慢”“同一台机器混跑多种任务，不知道谁在互相挤压”“容器没有 OOM，却频繁出现尾延迟”这些场景。它不替代火焰图、块设备延迟或内存回收统计，而是帮助你先确定应该往哪个资源方向深入。

把压力类型映射到排查方向

CPU：重点看 cpu some 是否和调度等待一起上升

cpu some 上升，表示有可运行任务想获得 CPU，却没有及时获得运行时间。它更接近“调度等待”而不是“CPU 利用率”。如果 CPU 利用率高但 PSI 很低，机器可能只是忙，却仍能及时调度任务；如果利用率未满而 PSI 升高，则要继续检查 CPU 配额、绑核、窃取时间、优先级或局部热点。

典型实现是同时观察 cpu some avg10、运行队列、容器 CPU throttling 和业务尾延迟。只有当这些信号在同一时间段相互印证，才把根因暂定为 CPU 竞争。

内存：some 看局部回收，full 看严重抖动

memory some 上升说明至少有部分任务因内存不足而停顿，常见关联包括直接回收、缺页和交换；memory full 上升则表示所有非空闲任务同时被内存压力拖住，往往比“可用内存还剩多少”更能揭示性能已经受损。

继续排查时，要把 PSI 与 reclaim、major fault、swap I/O、工作集变化和 OOM 事件对齐。只有 MemAvailable 偏低而 memory PSI 不升，不能单独证明应用正在遭受内存压力；反过来，memory PSI 持续升高即使尚未 OOM，也说明用户体验可能已经受影响。

I/O：some 是部分阻塞，full 是所有有效工作都在等

io some 表示部分任务因 I/O 无法推进，io full 表示所有非空闲任务同时处于 I/O 停顿。后者持续出现时，机器可能还有空闲 CPU，但工作负载已经没有可运行的有效工作。

进一步应检查块设备延迟、队列深度、吞吐、文件系统回写以及网络存储状态。PSI 能告诉你“等待已影响任务”，却不能告诉你是哪块盘、哪个挂载点或哪个请求造成了等待。

典型实现：同时采样比例和 total 增量

平均值便于看趋势，但很短的停顿尖峰可能被平滑掉。内核同时提供 total，因此监控系统可以保存相邻采样点的差值，再除以采样间隔，获得自定义窗口里的停顿比例。这里的关键是用计数器增量，而不是比较自启动以来的绝对总数。

# 记录两次 memory PSI 原始值；total 是累计微秒计数器，应在监控端计算差值
cat /proc/pressure/memory
sleep 5
cat /proc/pressure/memory

# 查看 cgroup v2 中目标工作负载自身的压力，避免只看整机平均值
CGROUP_DIR="/sys/fs/cgroup/your-service"
cat "${CGROUP_DIR}/cpu.pressure"
cat "${CGROUP_DIR}/memory.pressure"
cat "${CGROUP_DIR}/io.pressure"

在启用 cgroup v2 的系统中，每个 cgroup 目录可以暴露 cpu.pressure、memory.pressure 和 io.pressure，格式与系统级文件相同。主机 PSI 高但目标 cgroup PSI 低，说明压力可能来自邻居工作负载；两者同时高，则更值得检查该服务自身的资源需求或限制。

需要事件驱动告警时，可以在压力文件上注册 trigger，再用 select()、poll() 或 epoll() 等待事件。触发器格式是 。阈值应来自本地压测或历史数据，例如先找出服务延迟开始恶化时的 PSI 区间，再留出告警提前量；不要把内核文档中的演示数字直接当生产阈值。

反例：四种看似省事但会误判的做法

• 只看一个瞬时值：一次 avg10 抬高可能只是批任务启动。后果是告警频繁抖动，团队逐渐忽略真正故障。
• 给所有机器统一阈值：在线服务、数据库和离线计算对停顿的容忍度不同。后果是关键节点告警太晚，批处理节点却持续误报。
• 把 PSI 当利用率：CPU 很忙不等于任务被卡住，磁盘吞吐高也不等于 I/O 压力。后果是扩容方向错误，资源增加后延迟仍不改善。
• 只看主机不看 cgroup：整机平均值会混合多个租户。后果是无法区分自身资源不足、配额过紧和 noisy neighbor。

一份可落地的判断清单

1. 先确认是哪一类文件升高：cpu、memory 还是 io。
2. 看 some 是否持续，再检查内存与 I/O 的 full 是否同步上升；系统级 CPU 不使用 full 作判断。
3. 比较 avg10、avg60、avg300，区分刚发生、持续扩大和长期基线。
4. 用 total 增量补捉平均值可能漏掉的短尖峰。
5. 把 PSI 与同一时间段的 P95/P99 延迟、吞吐、超时和队列长度对齐。
6. 在 cgroup v2 中对照目标工作负载，确定压力来自自身、限制还是同机邻居。
7. 最后才根据历史基线和服务 SLO 设置告警持续时间、阈值与恢复条件。

常见问题

PSI 为 0 是否代表资源绝对充足？

不一定。它只表示采样窗口里没有观测到对应的任务停顿，不能证明未来没有压力，也不能替代容量趋势。系统级 cpu full 固定为 0 更是接口语义，不是 CPU 无竞争的证据。

avg10、avg60、avg300 应该优先看哪个？

复现故障时先看 avg10，判断是否持续时看 avg60，做容量和基线比较时看 avg300。三者不是互相替代，而是描述不同时间尺度。

some 很高但 full 很低，需要处理吗？

需要结合业务判断。这表示已有部分并发任务受阻，但系统仍有任务在推进。若尾延迟或吞吐已经恶化，就应排查；若业务无感且很快恢复，可以作为容量趋势记录。

为什么 PSI 高却找不到单个高利用率设备？

PSI 聚合的是任务停顿，不定位具体设备或进程。还可能存在 CPU 配额、内存回收、分层存储、远程文件系统等局部瓶颈，需要继续结合调度、内存和块层指标定位。

结论

Linux PSI 最有价值的地方，是把“资源很忙”改写成“任务因此停了多久”。判断时先分清 CPU、内存和 I/O，再用 some/full 看影响范围，用三档平均窗口看持续性，用 total 看短尖峰，最后以业务 SLO 和 cgroup 范围确认影响。这样建立的是可解释的压力判断，而不是一条脱离工作负载的魔法阈值。