Linux服务器故障排查实战命令详解

凌晨三点，监控红灯亮起，服务器负载飙升到天际，这种场景对运维人来说简直是家常便饭。与其在那一刻手忙脚乱地百度，不如平时就将那些能救命的排查命令刻进肌肉记忆里。真正的排查高手，不是靠运气，而是靠一套严密的逻辑链条和精准的工具使用。

抓住“凶手”：CPU与进程排查

很多人看到CPU飙升，第一反应是top命令。没错，但这只是入门。top虽然直观，但在高负载下它本身消耗的资源也不容忽视，而且它的默认视图容易误导新人——看到的往往是多个核心的平均值。

更专业的做法是结合mpstat和pidstat。mpstat -P ALL 1能让你看清每个核心的“脾气”，如果是单核被打满，那大概率是某个单线程程序在死循环；如果是所有核心都飘红，那就要考虑系统层面的调度问题或并发过载了。定位到具体进程后，pidstat -u -p <PID> 1能比top提供更细腻的波动数据。

如果遇到系统响应极慢，连top都敲不进去的情况，不妨试试ps -eo pcpu,pid,user,args | sort -k 1 -r | head -10，这招能瞬间揪出占用CPU最高的几个“嫌疑人”。

内存泄露的“侦探”工作

内存问题最棘手，因为它往往具有欺骗性。看到free -h里used一栏居高不下，先别急着喊内存泄露。linux的内存管理机制决定了它会尽可能多地利用内存做缓存，真正需要关注的是available这一列。

如果确认是应用进程在疯狂吞噬内存，top里的RES（常驻内存）和VIRT（虚拟内存）是关键指标。但若想追查泄露源头，光看数值没用。这时候需要祭出gdb或pmap。pmap -x <PID>能列出进程详细的内存映射，观察其增长趋势。对于Java应用，jmap和jstack是标配；而对于C/C++程序，Valgrind才是终极杀器，虽然跑起来慢，但能精准定位到没有释放的代码行。

磁盘IO的瓶颈定位

服务器变慢，有时候CPU和内存都没问题，那就是IO在作怪。iostat -x 1是诊断磁盘健康的听诊器。重点关注%util（利用率）和await（平均等待时间）。如果%util长期接近100%，说明磁盘带宽已经跑满；如果await远大于svctm（服务时间），说明IO请求排队严重，磁盘性能已成瓶颈。

这时候，iotop是个好帮手，它能像top显示CPU那样显示进程的IO使用情况，一眼就能看出是谁在疯狂读写磁盘。不过要注意，iotop需要root权限，且在某些容器环境中可能无法正常工作，这时pidstat -d可以作为替代方案。

网络连接的“透视眼”

网络问题最考验耐心。ping通了不代表服务没问题，端口开了不代表连接能建立。netstat作为经典工具，虽然功能强大，但在现代linux发行版中已逐渐被ss取代。ss -s能快速给出TCP连接的统计摘要，ss -lntp则能列出所有监听端口及其对应的进程。

遇到“Connection refused”错误，先用telnet或nc测试端口连通性；遇到“Connection timeout”，则要检查防火墙规则和路由表。tcpdump是网络排查的核武器，虽然命令复杂，但tcpdump -i eth0 -nn port 80这种基础用法足以应对大部分HTTP服务故障。抓下来的包用Wireshark分析，能看到三次握手是否成功，数据包是否丢失，应用层响应是否正常。

排查故障就像破案，现场保护最重要。切忌一上来就重启服务或清空日志，这无异于销毁证据。保留现场，按图索骥，才是工程师的专业素养。