PSI 是 Linux 内核 4.20 引入的压力停滞信息机制，可通过精确统计任务因 CPU、内存或 IO 资源不足而产生停滞的时间占比，更真实地反映系统资源争用与性能瓶颈，相比 CPU 利用率和 load a verage 判断更准确。
在 Linux 系统中判断资源是否“拥堵”或“紧张”，只看 CPU 利用率、内存使用率其实远远不够。这些指标只能告诉你“资源用了多少”，却无法回答更重要的问题：业务任务究竟“等待了多久”。真正能够准确衡量系统资源争用压力的，是 PSI（Pressure Stall Information，压力停滞信息）。该指标会直接统计任务因为缺少 CPU、内存或 IO 而发生阻塞、停顿的时间占比。
PSI 是什么，为什么比 load a verage 更准
PSI 从 Linux 内核 4.20 开始默认启用，像 Ubuntu 20.04+、RHEL 8+ 这样的主流 Linux 发行版基本都已支持。它与依赖采样和估算的传统监控指标不同，采用更贴近系统真实运行状态的方式：直接在调度器和内存子系统中埋点，把任务实际发生的等待时间精确记录下来，包括：
- CPU：任务已经处于就绪状态，但暂时分配不到 CPU 执行的那段时间
- memory：任务在内存分配、内存回收，或等待 swap-in 时被阻塞的时间
- io：任务等待块设备 I/O 完成的时间
和 load a verage 相比，区别非常明显。后者主要反映就绪队列长度，容易被进程数量影响，无法准确说明性能是否真正下降；而 PSI 的 some 和 full 指标则可以更清晰地区分系统只是“变慢了”，还是已经出现明显“卡顿”：
- some > 5%：表示系统延迟已经开始升高，例如 GC 更频繁、page reclaim 压力增大
- full > 1%：说明问题不再是轻微波动，通常意味着系统吞吐量已经受到明显影响，例如大量进程都在等待 swap
快速查看 PSI 的三个命令
PSI 指标数据暴露在 /proc/pressure/ 目录下，无需额外安装软件包即可直接查看：
cat /proc/pressure/cpu—— 查看 CPU pressure 的 10s/1m/5m 滑动平均值（some和full）cat /proc/pressure/memory—— 同样用于查看压力数据，但对内存资源紧张更敏感（OOM 前几秒full往往会快速上升）cat /proc/pressure/io—— 需要注意：在没有 I/O 竞争时该值可能长期为 0，这并不代表磁盘健康状态良好，只表示当前没有明显阻塞
输出格式示例：some=0.50 full=0.05 a vg10=0.12 a vg60=0.08 a vg300=0.03 total=123456789，其中 a vg10 单位是毫秒，表示过去 10 秒内有 123ms 处于 some 压力状态。
用 psi-monitor 实时观察压力趋势
系统原生提供的 PSI 输出本质上是静态快照，如果想持续观察 Linux 系统资源压力趋势，就需要定时轮询。这里推荐使用轻量级工具 psi-monitor（非系统自带，需要手动编译或下载二进制文件）：
- 它会每秒读取一次
/proc/pressure/并计算增量，省去自己编写 while 循环解析文本的麻烦 - 支持阈值告警，例如
psi-monitor -m "memory:full>0.5"可在内存full压力超过 0.5% 时触发通知 - 注意：不要直接使用
watch -n1 cat /proc/pressure/memory—— 高频轮询会增加 scheduler 开销，反而可能抬高 PSI 指标值
PSI 和传统命令的配合逻辑
单独查看 PSI 只能知道“系统堵得有多严重”，如果要进一步定位“具体堵在哪里”，还需要结合传统 Linux 性能排查命令一起分析：
- 当
memory:full偏高 → 立即执行cat /sys/fs/cgroup/memory/memory.pressure（若使用 cgroup v2）确认是否由某个容器引发；再通过ps aux --sort=-%mem | head -5找出内存占用最高的进程 - 当
io:some持续 > 10% → 使用iostat -x 1查看%util是否接近 100%，并同时关注await是否显著飙升（这通常说明 I/O 响应变慢，不一定意味着磁盘空间已满） - 当
cpu:some偏高但top中 %CPU 并不高 → 很可能存在短时突发任务，例如 cron job、日志刷盘等，此时可使用pidstat -u 1捕获 1 秒粒度的 CPU 峰值
PSI 的核心价值在于它能真实反映任务等待时间，不会被表面指标误导：load a verage 可能因为大量 sleep 进程而虚高，free 看起来内存充足却依然可能发生 OOM——而只有 PSI 能直接告诉你“任务到底被卡住了多久”。在生产环境和服务器性能排查中，它应当成为优先检查的系统资源压力指标，而不是最后才想到的参考项。
