刚接手一台性能异常的Linux服务器时,新手常会陷入"盲人摸象"的困境。去年处理某电商大促期间的服务器卡顿问题时,我发现80%的故障其实集中在CPU、内存、硬盘和网络四个核心子系统。掌握这四类故障的排查方法,就像获得了服务器诊疗的"听诊器"。
当终端响应变慢,首先应该检查CPU健康状况。我习惯用组合拳命令:
bash复制top -H -p $(pgrep -d',' -f "关键进程名") # 监控特定进程的线程级CPU占用
mpstat -P ALL 1 5 # 每颗CPU核心的详细利用率统计
经验:当%sys系统态CPU超过30%时,往往说明内核态存在瓶颈,可能是系统调用频繁或锁竞争
上周处理的一个典型案例:某Java应用CPU占用持续100%。通过perf工具采样发现是正则表达式回溯导致:
bash复制perf record -F 99 -p <PID> -g -- sleep 30
perf report --no-children # 查看调用火焰图
其他典型场景包括:
strace -p <PID>跟踪系统调用perf lock分析锁等待cat /proc/interrupts查看中断分布内存泄漏就像水管暗漏,初期难以察觉。我的排查三板斧:
bash复制watch -n 1 'free -m' # 实时监控内存变化
cat /proc/meminfo | grep -E 'MemAvailable|SwapCached' # 可用内存精确统计
valgrind --leak-check=full ./program # 应用级内存检测
去年排查的Python内存泄漏案例:由于循环引用导致GC无法回收,最终用objgraph可视化引用关系定位。
当看到Out of memory: Kill process日志时:
dmesg | grep -i oom确认被杀进程/proc/<pid>/oom_score了解评分机制echo -17 > /proc/<pid>/oom_adj重要:避免随意调整vm.overcommit_memory参数,不当设置可能导致系统不稳定
怀疑磁盘瓶颈时,先用fio进行基准测试:
bash复制fio --name=randread --ioengine=libaio --rw=randread --bs=4k \
--numjobs=16 --size=1G --runtime=60 --time_based --group_reporting
关键指标解读:
某MySQL实例响应缓慢,通过iotop发现是大量临时文件写入:
bash复制iotop -oP # 只显示实际I/O进程
lsof +L1 # 查找被删除但仍占用的文件
最终发现是未优化的GROUP BY语句导致临时表写入磁盘。
网络问题排查的黄金命令组合:
bash复制ss -tulnp # 比netstat更高效的连接查看
ethtool -S eth0 # 网卡级统计信息
nstat -az # 内核网络协议栈统计
遇到网络抖动时,我的标准排查流程:
ping -f -c 1000 <IP> 快速丢包测试mtr --report <IP> 路由级追踪tcpdump -ni eth0 -w capture.pcap 抓包分析曾用此方法定位到某K8s集群的CNI插件ARP缓存问题。
SystemTap实战示例(需内核调试符号):
bash复制stap -e 'probe vfs.read {
if (pid() == target())
printf("%s\n", stack())
}' -x <PID>
使用FlameGraph生成CPU火焰图:
bash复制perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg
我的常用工具集:
把这些命令存在本地~/bin/tools目录下,紧急情况时能快速调用。记住,好的系统管理员不是死记硬背命令,而是建立系统化的排查思维。每次故障都是一次学习机会——我习惯把典型案例记录在Wiki中,形成自己的"故障模式库"。