uptime显示的load average是1/5/15分钟平均负载，表示就绪或不可中断睡眠态进程数，需与逻辑核心数对比判断是否过高；top第三行wa>20%表明IO瓶颈，id高但系统卡提示内存不足或swap频繁，vmstat中b>0且r持续超核数指向I/O或CPU瓶颈。
uptime 看三秒内负载趋势
直接运行 uptime 是最快确认系统是否“已经卡了”的方式。它输出末尾的三个数字（如 load average: 2.45, 1.89, 1.32）分别代表 1 分钟、5 分钟、15 分钟的平均负载，不是 CPU 使用率，而是“等待或正在使用 CPU 的进程数”平均值。
关键判断依据是和逻辑核心数比：
-
grep 'model name' /proc/cpuinfo | wc -l查出逻辑核心数（含超线程，比如 8 核 16 线程就返回 16） - 若 15 分钟负载
>=逻辑核心数 × 1.0，说明负载持续偏高；超过 × 1.5 就该立刻查进程 - 若
1m > 5m > 15m，说明刚有突发任务；若15m > 5m > 1m，说明问题在恶化
top 里看实时负载 + CPU 分态占用
top 第一行和 uptime 一样显示 load average，但它真正价值在第三行：%Cpu(s): us sy ni id wa hi si st。
CentOS Linux 7.9.2009
下载
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
这里每个字段含义直接影响排查方向：
-
us高（>70%）→ 用户态程序吃 CPU，按P排序找高占用进程 -
wa高（>20%）→ CPU 在等磁盘 I/O，iostat -x 1必跟 -
id高但系统卡 → 不是 CPU 瓶颈，可能是内存不足触发频繁 swap 或网络延迟 - 按
1键可展开查看每个逻辑核的单独使用率，避免误判“整体不忙但某核打满”
vmstat 1 看负载背后的资源争抢
vmstat 1 每秒刷新一次，比 top 更轻量，适合后台挂起观察。重点关注这几列：
-
r：当前就绪但没分配到 CPU 的进程数。如果长期 > 逻辑核心数，说明 CPU 确实不够用 -
b：不可中断睡眠进程数（通常是 I/O 等待）。>0 且持续存在，配合高wa基本锁定磁盘瓶颈 -
cs（上下文切换）和in（中断次数）异常高 → 可能是软中断风暴或大量短生命周期进程 -
swpd非零 +si/so持续波动 → 内存不足，swap 开始拖慢整体响应
free 和 iostat 补充验证瓶颈类型
单看 load average 容易误判。必须交叉验证：
- 运行
free -h，重点看available列。如果远小于total，且buff/cache也没法回收，说明内存真紧张 - 运行
iostat -x 1，盯住%util（设备利用率）和await（平均 I/O 等待毫秒）。%util > 90%且await > 50ms就是磁盘扛不住了 - 别只信
load average数字本身——它不区分是 CPU 密集型、I/O 密集型还是内存换页导致的排队，必须结合这三类命令输出一起读
us 和 wa 都不高，此时大概率是大量进程卡在不可中断状态（D 状态），ps aux | awk '$8 ~ /D/ {print}' 能快速揪出它们，这类进程通常和存储驱动、NFS 挂载或内核模块异常有关。 
