适用范围与版本边界
本手册用于 Linux 主机响应变慢、资源告警或吞吐下降时的第一轮只读诊断，配合「Linux 主机监控」场景使用。示例按 GNU/Linux、procps-ng 与 sysstat 常见接口编写；BusyBox、容器内视图和不同发行版可能缺少选项，先核对本机帮助。PSI 需要内核相应配置，文件不存在应标记为不可用，不能当成压力为零。本文未在你的目标主机执行，验证状态为待验证。
前提、目标与采样预算
先确定主机资产标识、业务进程、故障开始时间、时区、业务延迟和最近变更。优先复用既有监控中的历史曲线，再在授权主机短时取样；一次异常截图不能代表持续瓶颈。诊断账号只需相应监控读取权限，不临时安装软件，不提权读取无关进程环境变量、命令行密钥或用户文件。日志和进程名离开值班通道前应脱敏。
每次先执行少量、有限次采样，间隔由故障压力和采集规范决定。下列 1 5 是一次短观察，不应被直接包装成永久高频任务。若命令不存在，记录缺失并使用既有监控，安装工具应另走变更。
第一步：固定主机与时间基线
date -u '+%Y-%m-%dT%H:%M:%SZ'
hostname
uname -r
uptime
nproc
vmstat 1 5记录采样是否在宿主机或容器内，以及 nproc 可见 CPU 是否受 CPU 亲和性、cpuset 等约束。uptime 中负载不是 CPU 使用率；vmstat 第一组通常是开机以来的统计，后续组才对应采样间隔。将运行队列、阻塞任务、交换活动与业务异常时间对齐，暂不据单个数字判定“必须扩容”。
第二步：区分 CPU 竞争与等待
mpstat -P ALL 1 5
pidstat -u 1 5
ps -eo pid,ppid,comm,stat,pcpu,pmem --sort=-pcpu | head -n 21用分 CPU 视图识别单核热点，用进程采样找到同一时间正在消耗 CPU 的对象。ps 的 CPU 占比不是与前两个命令完全相同的瞬时口径。若业务变慢同时运行队列增长、多个核忙且 CPU 压力升高，优先调查工作量、线程竞争或限额；若 CPU 有空闲但阻塞任务、IO 等待同步上升，继续检查存储和内存，不能把所有高负载都归为计算不足。虚拟机的 steal 增长应连同宿主侧证据交给平台团队。
第三步：核对可用内存和回收压力
free -h
awk '/^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree):/' /proc/meminfo
ps -eo pid,comm,rss,vsz,pmem --sort=-rss | head -n 21MemAvailable 是内核对无需交换即可供新应用使用内存的估计，不能仅凭 MemFree 较小断定内存耗尽。RSS 排名用于定位进程，不宜直接相加当作唯一物理内存账本；共享页、缓存以及容器限额会影响解释。把 RSS 增长、swap in/out、OOM 事件和业务延迟一起分析，区分长期增长、短时批处理与缓存变化。相关字段定义见 Linux /proc 文档。
若主机已提供 PSI，可只读观察：
for OPS_RESOURCE in cpu memory io; do
if test -r "/proc/pressure/$OPS_RESOURCE"; then
printf '\n%s pressure\n' "$OPS_RESOURCE"
sed -n '1,2p' "/proc/pressure/$OPS_RESOURCE"
fi
donesome 表示部分任务等待该资源的时间比例；内存或 IO 的 full 可帮助识别更严重的整体停滞。系统级 CPU full 不能按内存 full 的方式判断。对比 avg10、avg60、avg300 趋势和业务基线，不设置适用于所有主机的固定阈值。字段语义见 内核 PSI 指南。
第四步：区分空间、inode 与设备时延
将示例路径替换为已经确认的应用目录，不使用整个根目录递归扫描：
OPS_APP_PATH='/REPLACE_WITH_CONFIRMED_APP_PATH'
df -hT -- "$OPS_APP_PATH"
df -i -- "$OPS_APP_PATH"
iostat -xz -y 1 5df 针对路径所在文件系统核对块空间和 inode，两者需要分别验收；同一挂载点的空闲与应用配额、保留空间也可能不同。iostat 的 -y 跳过开机累计首报；await 包含排队与服务时间，应与设备类型、历史吞吐和队列共同看待，NVMe 或阵列上不能仅靠 %util 接近某个值证明饱和。GNU df 和 sysstat iostat 分别解释这两类口径。
空间紧张时先查已知业务目录的容量曲线和保留策略。需要 du 时仅扫描经确认的小范围目录，并明确 IO 预算；进程持有已删除文件、快照和容器层占用可使 du 与 df 不一致。不要为了让告警消失而删除日志或重启进程。
判断分支与下一步交接
- CPU 持续繁忙而 IO、内存压力较低：交给应用负责人比对请求量、热点线程和并发限额，是否采集性能剖析另行审批。
MemAvailable下降且回收、交换、OOM 与延迟相关：确认进程或 cgroup 范围及新增负载，再评估限流、容量或代码问题。- 空间或 inode 紧张但设备延迟正常：优先确认数据归属、增长源及配额；“空间不足”不是“磁盘性能不足”。
- 设备延迟、队列与 IO 压力共同升高：按实际挂载设备交接存储团队，核对云盘限额、阵列事件或后台任务。
- 主机指标正常但业务仍异常：回到网络、依赖和应用层，避免为了得到主机根因而扩大无关扫描。
验收、停止与恢复边界
诊断完成应能说明受影响时间、资源类别、证据可信度和尚未排除的原因，而不是仅给出“CPU 高”。后续处置由授权负责人执行，验收需覆盖代表性负载下的业务延迟、错误率、资源趋势和告警恢复。只读查询本身没有配置回滚；诊断中不执行 drop_caches、删除数据、关闭 swap、修改 sysctl 或强制终止进程。若取样明显加重延迟、出现 IO 错误或 OOM 连续发生，停止扩大取样范围并升级事故响应，恢复方案应来自对应变更单。
案例证据记录模板
- 事件编号、主机资产标识、采样位置、系统与工具版本：待填。
- 业务症状、开始时间和时区、最近变更、受影响范围：待填。
- 同窗口 CPU、内存、IO、文件系统与进程证据：填写时间戳、来源和脱敏结果。
- 当前假设、支持与反证、仍缺少的观测：待填。
- 下一步负责人、变更授权、停止条件及验收窗口：待填。
不要将本文示例直接填写为已执行记录；没有实测数据时保留待验证状态。