救火指南!Linux 服务器出问题了怎么办?这篇万能排查手册请收好

在运维和开发的日常工作中，最让人头疼的时刻莫过于：“服务器突然卡死了！”、“服务访问不通了！”、“磁盘空间莫名其妙满了！”

面对一个冰冷的终端窗口，很多初学者容易陷入“盲目重启”或“随机尝试”的误区。其实，Linux 故障排查有一套标准的方法论。今天，我们就把这套“救火指南”毫无保留地分享给大家，涵盖最常见的故障场景及解决手段，让你在面对线上事故时能保持冷静，精准出击！

🛠 第一部分：故障排查的“通用心法”

在动手敲命令之前，请记住这个四步法：

1. 现象确认：发生了什么？（是响应慢、完全不通，还是报错 500？）

2. 范围锁定：是单机问题还是集群问题？是网络问题还是应用问题？

3. 证据搜集：查看日志 

    检查资源 

    抓包分析。

4. 验证修复：修改配置 

    重启服务 

    监控观察。

🔍 第二部分：四大常见故障场景及解决手段

1. CPU 飙升（系统卡顿）

症状： 响应缓慢，SSH 登录延迟，uptime 显示 load average 极高。

• 排查工具： top, htop, vmstat

• 解决路径：

• 使用 top 定位占用 CPU 最高的进程。

• 如果是 Java 应用，使用 top -Hp <pid> 找到最忙的线程，再通过 printf "%x\n" <tid> 转换成 16 进制，配合 jstack 定位到代码行。

• 检查是否由于频繁的上下文切换（Context Switch）引起。

2. 内存溢出 (OOM)

症状： 进程莫名其妙被 kill 掉，日志中出现 Out of memory: Kill process。

• 排查工具： free -m, vmstat, dmesg

• 解决路径：

• free -m 查看可用内存和 Swap 分区使用情况。

• dmesg | grep -i oom 确认是否触发了内核的 OOM Killer。

• 检查是否有内存泄漏（Memory Leak）或 JVM 堆内存配置过大/过小。

3. 磁盘空间/Inode 耗尽

症状： 无法创建新文件，数据库报错 No space left on device，但 df -h 显示还有空间。

• 排查工具： df -h, du -sh, df -i, lsof

• 解决路径：

• df -h 查看空间占用 du -sh * 逐级定位大文件。

• 坑点： 如果 df -h 有空间但报错，请检查 df -i（Inode 节点可能被大量小文件耗尽）。

• 坑点： 文件删除了空间没释放？用 lsof | grep deleted 找到被进程占用但已删除的文件，重启该进程即可。

4. 网络不通/延迟高

症状： 无法访问服务，端口连接超时，丢包严重。

• 排查工具： ping, telnet, netstat/ss, tcpdump, mtr

• 解决路径：

• ping 检查物理连通性 telnet/curl 检查端口开放情况。

• ss -ntlp 查看服务是否在监听正确端口。

• iptables -L 或 ufw status 检查防火墙是否拦截。

• 使用 tcpdump 抓包分析三次握手是否完成。

🧪 第三部分：故障模拟实战（手把手带你练）

为了让大家有体感，我们模拟三个经典故障场景。你可以自己在虚拟机上尝试。

场景 A：诡异的“磁盘空间不足”

【模拟】：你删除了一个 10G 的日志文件 rm -f access.log，但 df -h 显示空间依然被占用。

• 原因：该文件仍被某个进程（如 Nginx）打开，内核直到进程关闭文件句柄才会真正释放空间。

• 排查：lsof | grep deleted 

   发现 nginx 进程持有该文件。

• 解决：systemctl reload nginx 或 kill 重启进程。

场景 B：服务启动失败，但没有报错

【模拟】：执行 ./start.sh 没有任何输出，但服务没起来。

• 原因：错误信息被重定向到了 /dev/null 或日志文件权限不足。

• 排查：

1. ps -ef | grep service_name 确认进程是否真的没起。

2. tail -f /var/log/syslog 或 journalctl -u service_name 查看系统级日志。

3. 检查 dmesg 看是否有 Segfault（段错误）。

• 解决：修复权限或配置错误。

场景 C：CPU 负载高，但 CPU 使用率低

【模拟】：top 显示 Load Average 是 10，但 %Cpu(s) 的 us (用户态) 只有 5%。

• 原因：这种情况通常是 I/O 等待 (Wait) 过高，CPU 在等磁盘读写。

• 排查：top 中查看 %wa 指标  iostat -x 1 10 查看磁盘利用率 %util。

• 解决：优化数据库查询，检查磁盘是否有坏道，或更换 SSD。

📚 第四部分：常用排查命令清单（建议收藏）

💡 结语

Linux 故障排查没有所谓的“银弹”，核心在于“由浅入深，由表及里”。先看整体资源，再看具体进程，最后分析系统调用和网络包。

建议每一位运维/开发人员在自己的笔记中建立一个“故障库”：现象  原因  解决方案  预防措施。

只有经历过足够多的“救火”现场，你才能在面对故障时，一眼看出问题的症结所在！