别再只会用top了！Linux服务器性能排查，这5个命令组合拳才是王道
Linux服务器性能排查实战：5个命令组合拳精准定位瓶颈
当服务器突然变慢，告警短信接连不断时，新手运维往往手忙脚乱地反复执行top命令，却找不到问题根源。真正的高手会像老中医把脉一样，通过一套组合命令快速定位系统瓶颈。本文将分享一套经过实战检验的Linux性能排查SOP，用top、vmstat、iostat、free、iftop五个命令构建完整的诊断闭环。
1. 性能排查的黄金起点：top命令深度解读
top命令是大多数工程师接触的第一个性能工具，但90%的用户只停留在看CPU百分比的层面。让我们拆解其关键指标：
top - 14:23:45 up 32 days, 8:47, 3 users, load average: 1.25, 0.98, 0.72 Tasks: 231 total, 2 running, 229 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.3 us, 5.6 sy, 0.0 ni, 81.7 id, 0.4 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 8000000 total, 100000 free, 5000000 used, 2900000 buff/cache KiB Swap: 0 total, 0 free, 0 used. 2500000 avail Mem关键指标解读矩阵：
| 指标组 | 关键字段 | 正常范围 | 异常表现 | 关联问题 |
|---|---|---|---|---|
| 负载 | load average | <CPU核心数 | 持续>核心数2倍 | CPU饱和或IO阻塞 |
| CPU | %wa(io wait) | <2% | >5%持续波动 | 磁盘IO瓶颈 |
| 内存 | buff/cache | 占比30%-70% | cache持续下降 | 内存泄漏 |
| 进程 | D状态进程 | 0 | 长期存在 | 死锁或IO挂起 |
实战技巧：
- 按
1展开多核CPU详情，观察是否有个别核心满载 - 按
M按内存排序，找出内存消耗Top3进程 - 按
R反向排序，快速定位异常进程 - 使用
-p PID监控特定进程资源占用
注意：当发现
%wa持续偏高时，应立即转入磁盘IO分析，这正是iostat的用武之地。
2. 系统级瓶颈定位：vmstat揭示隐藏问题
vmstat以全局视角展示系统资源状态，特别擅长发现隐形瓶颈。建议以2秒间隔采样：
vmstat 2 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 250000 100000 1500000 0 0 100 50 500 2000 15 5 75 5 0关键字段解析：
- procs.r：超过CPU核心数说明存在调度积压
- memory.swpd：交换空间使用量>0需警惕
- io.bi/bo：块设备吞吐量（KB/s）
- system.cs：每秒上下文切换超过10万次需优化
内存压力诊断流程：
- 观察
si/so（swap in/out）是否持续>0 - 检查
free字段是否呈下降趋势 - 对比
buff/cache是否被主动回收
典型异常模式对照表：
| 现象 | 可能原因 | 验证命令 |
|---|---|---|
| cs值过高 | 进程/线程过多 | `ps -eLf |
| b列有值 | 磁盘IO阻塞 | iostat -x 2 |
| si持续输出 | 内存泄漏 | free -h |
3. 磁盘IO终极审判：iostat解剖存储性能
当top显示高%wa或vmstat发现b列阻塞进程时，iostat是定位磁盘问题的终极武器：
iostat -xmd 2 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util vda 0.00 2.50 50.00 30.00 1.20 0.80 35.20 1.50 18.00 15.00 22.00 3.00 24.00关键指标黄金法则：
- %util>70% 表示磁盘接近饱和
- await>10ms 需要优化（SSD应<2ms）
- avgqu-sz>1 存在IO队列堆积
RAID阵列诊断技巧：
iostat -Nd 2 # 观察各物理磁盘util是否均衡云环境特别关注：
- 突发性能实例的baseline限制
- EBS卷的burst credit余额
- 网络存储的延迟波动
4. 内存困局破解：free命令的进阶用法
内存问题往往最具迷惑性，free命令需要配合-h和-w参数使用：
free -hw total used free shared buffers cache available Mem: 7.7G 5.1G 200M 10M 1.2G 1.2G 2.3G Swap: 0B 0B 0B内存健康度三维评估：
- 可用内存：
available值应>总内存20% - 缓存效率：
cache占比在30%-60%最佳 - 交换风险：
swap used>0即需处理
OOM预警检查清单：
- 执行
dmesg | grep oom-killer - 监控
/proc/meminfo的CommitLimit - 设置
vm.overcommit_memory=2
5. 网络流量透视：iftop揪出带宽杀手
当应用响应慢但系统资源充足时，网络往往是罪魁祸首。iftop能实时显示带宽占用：
iftop -nNP # 按T键显示流量TopN关键操作指南：
- 按
B切换字节/比特显示 - 按
P冻结当前状态 - 按
t切换流量显示模式
网络瓶颈排查路径：
- 确认带宽是否饱和（对比
ethtool显示的速度） - 检查是否有异常IP（如扫描攻击）
- 分析TCP重传率（
ss -ti）
6. 实战演练：电商大促故障排查实录
场景复现： 凌晨2点，订单系统响应时间从200ms飙升到5s，监控显示：
- CPU使用率70%
- 内存available仅剩500MB
- 磁盘util持续90%
排查过程：
top发现MySQL进程CPU占用40%且%wa达15%vmstat显示cs超过15万/s，b列有3个阻塞进程iostat -xmd 2确认磁盘await高达120msfree -h发现cache被回收至100MB以下iftop排除网络问题
根因定位： MySQL临时表暴涨导致大量磁盘随机写，同时连接数激增引发线程频繁切换。最终通过调整tmp_table_size和优化连接池解决。