psi是linux 5.2+内核原生支持的资源压力指标，直接反映任务因cpu、内存或io争用而停滞的时间占比；/proc/pressure/{cpu,memory,io}文件分别提供some（至少一任务阻塞）和full（所有非空闲任务同时阻塞）指标，avg10/60/300为对应时间窗内百分比均值，total为累计停滞微秒数。
直接看 /proc/pressure/ 下的 PSI 文件
Linux 5.2+ 内核原生支持 PSI（Pressure Stall Information），这是唯一能直接反映“资源争用导致任务停滞”程度的系统级指标，不是利用率，而是真实等待时间占比。它比 top、vmstat 或负载值更贴近业务延迟感知。
-
/proc/pressure/cpu：只提供some指标，表示至少一个可运行任务在等待 CPU 时间片 -
/proc/pressure/memory：同时提供some和full，full>0 表示所有非空闲任务全卡在内存分配上（OOM 前兆） -
/proc/pressure/io：同样含some/full，full持续非零说明磁盘已完全阻塞（如 swap-in 队列堆积）
每行格式统一：some avg10=0.00 avg60=0.00 avg300=0.00 total=1234567，其中 avg10 是过去 10 秒的平均压力百分比，total 是自启动以来的总停滞毫秒数。注意：数值是“占比 × 100”，即 avg10=15.2 表示过去 10 秒内 15.2% 的时间存在该资源争用。
用 pressure.sh 或 cat 快速抓取实时压力值
别依赖第三方工具封装——PSI 数据就在文件里，cat 最直接，watch 可实现刷新：
- 单次查看全部：
cat /proc/pressure/{cpu,memory,io} - 每 2 秒刷新观察趋势：
watch -n 2 'cat /proc/pressure/memory' - 判断是否已达危险阈值：
awk '$2 > 50 {print "HIGH"}' /proc/pressure/memory（avg10>50 即 50% 时间在等内存）
注意：some 值持续 >20 表示延迟明显上升；full 值哪怕只是 0.5，也意味着吞吐量已实质性受损——这点常被忽略，因为传统监控工具根本不暴露 full 维度。
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
psutil、Prometheus 等库读 PSI 的坑
很多 Python 或 Go 监控脚本用 psutil 获取 CPU/内存使用率，但它**不暴露 PSI**；Prometheus 的 node_exporter 默认也不采集 PSI，需手动启用 --collector.pressure 参数并确保内核支持。
- Python 中正确读 PSI 只能靠自己 open
/proc/pressure/memory解析，不能依赖psutil的cpu_percent()或virtual_memory() - 如果
node_exporter启动后node_pressure_*指标为空，先确认：zgrep CONFIG_PSI /proc/config.gz返回y，再检查是否加了--collector.pressure - Kubernetes Pod 级 PSI 需 Cgroup v2 +
memory.pressure文件，不是所有发行版默认启用
PSI 和 load average 的关键区别在哪
load average 统计的是“可运行 + 不可中断状态”的进程数均值，它会把 D 状态（UNINTERRUPTIBLE）进程计入，但无法区分是真卡在 IO 还是短暂同步等待；而 PSI 的 io some 只统计因块设备 IO 完成而停滞的时间，memory full 只统计所有非空闲任务同时等待内存回收/swap-in 的时段——它过滤掉了噪声，直指资源瓶颈本质。
所以当你看到 load average 为 3.2 但 /proc/pressure/cpu some avg10 是 0.0，基本可排除 CPU 争用；反之若 top 显示 %CPU 很低但 memory full avg10=8.7，那问题一定出在内存回收风暴或交换抖动上，而不是 CPU 不够。
