为什么使用率正常也会慢
服务响应慢、CPU/内存/磁盘使用率却都不高时，要把视角换成延迟：内核 PSI（Pressure Stall Information）直接量化“因为有任务在等 CPU、IO 或内存而被卡住”的时间占比，比使用率更贴近用户体感；再进一步可以用 eBPF 工具看调度与块设备的延迟分布。PSI 需要内核 4.20 及以上，老内核要用 sar 与 vmstat 的替代指标。
基本信息
| 适用平台 | Linux；PSI 需内核 4.20+（一般默认开启） |
|---|---|
| 权限要求 | 读 /proc/pressure 普通用户即可；eBPF 工具需 root |
| 查看方式 | cat /proc/pressure/{cpu,io,memory}、sar -q、vmstat |
| 进阶工具 | bpftrace/bcc 的 runqlat、biosnoop（需内核特性支持） |
| 替代指标 | sar -q 的 runq-sz/ldavg、vmstat 的 r 与 b 列 |
典型使用场景
- 接口偶发变慢但各项使用率看着正常时的标准排查路径
- 判断卡点是在 IO 排队还是 CPU 排队：PSI 的 io 与 cpu 分开看
- 容器平台里评估 cgroup 配额耗尽与宿主机争抢各自的影响
- 长尾延迟治理：先量化争抢程度，再决定升配还是改架构
- 变更前后用同一窗口的 PSI 数值做效果对比
常用示例
常用示例
cat /proc/pressure/cpu /proc/pressure/io /proc/pressure/memory # 4.20+ 内核的 PSI 视图
# some=至少一个任务被卡住的时间占比；full=所有可运行任务都被卡住
# avg10/avg60/avg300 是三个时间窗，用来区分突发与持续
cat /proc/pressure/io | grep full # IO 是否把整体吞吐卡死，优先关注
sar -q 1 5 # 老内核替代方案：runq-sz 与 ldavg-1/5/15
vmstat 1 5 # r 列（运行队列）与 b 列（阻塞进程）
runqlat 1 5 2>/dev/null || echo 'bpftrace/bcc 未安装' # 调度延迟直方图，毫秒分桶
biosnoop 2>/dev/null | head -n 20 # 块设备 IO 的延迟与所属进程指标对照
| 指标 | 反映什么 | 怎么用 |
|---|---|---|
| PSI some | 至少一个任务因该资源被卡住的时间占比 | 判断“有没有人被卡”，用于定位资源类型 |
| PSI full | 全部可运行任务都被卡住的时间占比 | 已经影响整体吞吐，优先级最高 |
| avg10/avg60/avg300 | 10/60/300 秒窗口均值 | 短窗口高是突发，长窗口也高说明容量持续不足 |
| runq-sz / r 列 | CPU 运行队列长度 | 老内核与需要关联具体进程时的替代指标 |
| runqlat 直方图 | 任务在队列中等待的毫秒分布 | 长尾延迟的直接证据，比均值更有说服力 |
PSI 输出的是时间占比而不是负载值：同样是 1%，io 的 full 与 cpu 的 some 对业务的影响完全不同，必须结合业务类型解读。
sar -q 的 ldavg 把不可中断的任务（多为 IO 阻塞）也算进去，所以“负载高”经常不等于 CPU 忙；下结论前用 vmstat 的 r/b 与 PSI 交叉验证。