Linux服务器性能排查实战5个命令组合拳精准定位瓶颈凌晨3点服务器告警铃声刺破夜空。监控大屏上API响应时间从50ms飙升到2000ms用户投诉如潮水般涌来。作为运维负责人你需要的不是逐个命令的机械检查而是一套精准打击性能瓶颈的组合拳。本文将揭示如何像老手一样用top、vmstat、iostat、free、iftop这五个命令构建立体化诊断矩阵在3分钟内锁定问题根源。1. 性能排查的战术思维性能诊断不是命令的堆砌而是证据链的构建过程。资深工程师与初学者的区别在于前者知道每个命令输出的数据如何交叉验证后者只会孤立地看单个指标。我们建立以下排查原则三明治法则先看整体负载top再分层检查CPU/内存/磁盘/网络最后微观分析具体进程时间维度区分瞬时峰值1分钟负载与持续问题15分钟负载指标联动当CPU的wa升高时必须同步检查磁盘util当内存free减少时需确认swap交换频率关键提示永远不要依赖单一命令下结论。例如top显示CPU空闲可能隐藏着IO等待队列的深度阻塞。2. 第一击全局态势感知top执行top -c -o %CPU后按1展开所有CPU核心此时界面呈现7个关键战区%Cpu0 : 8.3 us, 1.7 sy, 0.0 ni, 89.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 15.2 us, 3.1 sy, 0.0 ni, 81.4 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st Tasks: 231 total, 2 running, 229 sleeping, 0 stopped, 0 zombie KiB Mem : 16G total, 1.2G free, 5.3G used, 9.5G buff/cache KiB Swap: 2G total, 2G free, 0K used. 10G avail Mem异常特征快速解码表指标组合潜在问题下一步行动us 70% load CPU核心数计算密集型瓶颈用P按CPU排序定位问题进程wa 20% idle 30%存储IO瓶颈立即检查iostat的await和utilbuff/cache持续减少内存泄漏征兆用E切换内存单位观察趋势swap used 0内存不足检查free的si/so是否持续交换实战案例某电商大促期间top显示MySQL进程CPU占用仅15%但wa达到40%。新手可能误判CPU空闲老手会立即关联磁盘状态——后续iostat证实是SSD写入达到极限带宽。3. 第二击资源压力透视vmstat在另一个终端执行vmstat 1 10动态观察10秒内的资源波动procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 1 244728 352304 132512 1023344 0 0 1024 256 789 1567 15 3 78 4 0 3 0 244728 351876 132516 1023348 0 0 2048 0 1234 2345 18 4 74 4 0关键字段作战手册死亡三角需立即干预b 5阻塞进程堆积si/so 0持续发生swap交换cs 10000上下文切换风暴性能衰减信号r CPU逻辑核心数CPU调度队列积压wa连续 10存储子系统过载in突增可能是网络包洪水攻击内存诊断技巧用watch -n 1 vmstat -s观察细分内存消耗特别是active memory与inactive memory的比例异常往往早于OOM发生。4. 第三击磁盘IO刑侦iostat执行iostat -xmt 1开启带时间戳的扩展视图2023-08-20 03:15:45 avg-cpu: %user %nice %system %iowait %steal %idle 8.12 0.00 2.12 23.45 0.00 66.31 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 5.00 50.00 200.00 1.25 10.00 90.00 4.50 18.00 5.00 25.00 4.00 98.00磁盘健康度四象限分析吞吐瓶颈rMB/s wMB/s接近磁盘物理带宽如SATA SSD约500MB/sIOPS瓶颈r/s w/s达到设备极限如云盘通常3000 IOPS延迟异常await svctm的2倍说明队列堆积隐性风险%util 70%持续5分钟需扩容高级技巧对NVMe设备使用iostat -dxctz 1显示完整64字节队列深度观察aqu-sz是否常驻高水位线。5. 第四击内存法医分析free组合使用free -h与smem -t -ktotal used free shared buff/cache available Mem: 62G 5.2G 1.1G 356M 56G 55G Swap: 2.0G 0B 2.0G PID User Command Swap USS PSS RSS 4729 mysql /usr/sbin/mysqld 1.2G 2.3G 2.5G 3.1G内存真相三层解剖表面层available才是真实可用内存free低可能是cache策略进程层PSSProportional Set Size反映实际内存占用内核层slabtop查看内核对象占用如dentry缓存爆炸血泪教训某次Kubernetes节点频繁OOM最终发现是/proc/sys/vm/overcommit_memory设为1导致内存超售而free显示正常误导了诊断。6. 第五击网络流量缉凶iftop执行iftop -nNPB -i eth0显示带端口号的实时流量18.3Kb 36.5Kb 54.8Kb 73.0Kb 91.3Kb └─────────────┴─────────────┴─────────────┴─────────────┴───────────── 192.168.1.2:443 10.2.3.4:55682 15Kb 30Kb 45Kb 192.168.1.2:443 10.2.3.4:55682 7.5Kb 15Kb 22Kb网络异常特征识别单边流量只有TX或RX说明应用层协议异常端口扩散同一IP的随机端口激增可能是扫描行为带宽突变对比nethogs确认进程级流量某次线上事故中iftop发现某边缘节点持续向境外IP发送数据最终定位到被入侵挖矿。常规监控未能触发告警因为总带宽占用不到5%。7. 组合拳实战演练假设收到告警API响应延迟1s按以下流程排查第一分钟top -c -o %CPU vmstat 1 5发现wa高达35%CPU idle仅45%第二分钟iostat -xmt 1 | grep -A1 %util确认磁盘util持续100%await达50ms第三分钟smem -t -k | head -10发现MySQL的PSS异常高达20G最终结论慢查询导致大量临时表写入磁盘解决方案优化SQL增加tmpfs这套组合拳的威力在于从发现问题到定位根因不超过3分钟而传统方法可能需要反复执行多个命令才能拼凑出完整证据链。
别再只会用top看CPU了！Linux服务器性能排查，这5个命令组合拳才是关键
Linux服务器性能排查实战5个命令组合拳精准定位瓶颈凌晨3点服务器告警铃声刺破夜空。监控大屏上API响应时间从50ms飙升到2000ms用户投诉如潮水般涌来。作为运维负责人你需要的不是逐个命令的机械检查而是一套精准打击性能瓶颈的组合拳。本文将揭示如何像老手一样用top、vmstat、iostat、free、iftop这五个命令构建立体化诊断矩阵在3分钟内锁定问题根源。1. 性能排查的战术思维性能诊断不是命令的堆砌而是证据链的构建过程。资深工程师与初学者的区别在于前者知道每个命令输出的数据如何交叉验证后者只会孤立地看单个指标。我们建立以下排查原则三明治法则先看整体负载top再分层检查CPU/内存/磁盘/网络最后微观分析具体进程时间维度区分瞬时峰值1分钟负载与持续问题15分钟负载指标联动当CPU的wa升高时必须同步检查磁盘util当内存free减少时需确认swap交换频率关键提示永远不要依赖单一命令下结论。例如top显示CPU空闲可能隐藏着IO等待队列的深度阻塞。2. 第一击全局态势感知top执行top -c -o %CPU后按1展开所有CPU核心此时界面呈现7个关键战区%Cpu0 : 8.3 us, 1.7 sy, 0.0 ni, 89.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st %Cpu1 : 15.2 us, 3.1 sy, 0.0 ni, 81.4 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st Tasks: 231 total, 2 running, 229 sleeping, 0 stopped, 0 zombie KiB Mem : 16G total, 1.2G free, 5.3G used, 9.5G buff/cache KiB Swap: 2G total, 2G free, 0K used. 10G avail Mem异常特征快速解码表指标组合潜在问题下一步行动us 70% load CPU核心数计算密集型瓶颈用P按CPU排序定位问题进程wa 20% idle 30%存储IO瓶颈立即检查iostat的await和utilbuff/cache持续减少内存泄漏征兆用E切换内存单位观察趋势swap used 0内存不足检查free的si/so是否持续交换实战案例某电商大促期间top显示MySQL进程CPU占用仅15%但wa达到40%。新手可能误判CPU空闲老手会立即关联磁盘状态——后续iostat证实是SSD写入达到极限带宽。3. 第二击资源压力透视vmstat在另一个终端执行vmstat 1 10动态观察10秒内的资源波动procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 2 1 244728 352304 132512 1023344 0 0 1024 256 789 1567 15 3 78 4 0 3 0 244728 351876 132516 1023348 0 0 2048 0 1234 2345 18 4 74 4 0关键字段作战手册死亡三角需立即干预b 5阻塞进程堆积si/so 0持续发生swap交换cs 10000上下文切换风暴性能衰减信号r CPU逻辑核心数CPU调度队列积压wa连续 10存储子系统过载in突增可能是网络包洪水攻击内存诊断技巧用watch -n 1 vmstat -s观察细分内存消耗特别是active memory与inactive memory的比例异常往往早于OOM发生。4. 第三击磁盘IO刑侦iostat执行iostat -xmt 1开启带时间戳的扩展视图2023-08-20 03:15:45 avg-cpu: %user %nice %system %iowait %steal %idle 8.12 0.00 2.12 23.45 0.00 66.31 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 5.00 50.00 200.00 1.25 10.00 90.00 4.50 18.00 5.00 25.00 4.00 98.00磁盘健康度四象限分析吞吐瓶颈rMB/s wMB/s接近磁盘物理带宽如SATA SSD约500MB/sIOPS瓶颈r/s w/s达到设备极限如云盘通常3000 IOPS延迟异常await svctm的2倍说明队列堆积隐性风险%util 70%持续5分钟需扩容高级技巧对NVMe设备使用iostat -dxctz 1显示完整64字节队列深度观察aqu-sz是否常驻高水位线。5. 第四击内存法医分析free组合使用free -h与smem -t -ktotal used free shared buff/cache available Mem: 62G 5.2G 1.1G 356M 56G 55G Swap: 2.0G 0B 2.0G PID User Command Swap USS PSS RSS 4729 mysql /usr/sbin/mysqld 1.2G 2.3G 2.5G 3.1G内存真相三层解剖表面层available才是真实可用内存free低可能是cache策略进程层PSSProportional Set Size反映实际内存占用内核层slabtop查看内核对象占用如dentry缓存爆炸血泪教训某次Kubernetes节点频繁OOM最终发现是/proc/sys/vm/overcommit_memory设为1导致内存超售而free显示正常误导了诊断。6. 第五击网络流量缉凶iftop执行iftop -nNPB -i eth0显示带端口号的实时流量18.3Kb 36.5Kb 54.8Kb 73.0Kb 91.3Kb └─────────────┴─────────────┴─────────────┴─────────────┴───────────── 192.168.1.2:443 10.2.3.4:55682 15Kb 30Kb 45Kb 192.168.1.2:443 10.2.3.4:55682 7.5Kb 15Kb 22Kb网络异常特征识别单边流量只有TX或RX说明应用层协议异常端口扩散同一IP的随机端口激增可能是扫描行为带宽突变对比nethogs确认进程级流量某次线上事故中iftop发现某边缘节点持续向境外IP发送数据最终定位到被入侵挖矿。常规监控未能触发告警因为总带宽占用不到5%。7. 组合拳实战演练假设收到告警API响应延迟1s按以下流程排查第一分钟top -c -o %CPU vmstat 1 5发现wa高达35%CPU idle仅45%第二分钟iostat -xmt 1 | grep -A1 %util确认磁盘util持续100%await达50ms第三分钟smem -t -k | head -10发现MySQL的PSS异常高达20G最终结论慢查询导致大量临时表写入磁盘解决方案优化SQL增加tmpfs这套组合拳的威力在于从发现问题到定位根因不超过3分钟而传统方法可能需要反复执行多个命令才能拼凑出完整证据链。
