深入解析：Linux服务器崩溃急救攻略

这是一份非常实用的 Linux 服务器崩溃急救指南。当服务器出现无响应、无法通过 SSH 登录、卡死等情况时，请按照以下步骤进行排查和恢复。

核心原则：保持冷静，先诊断，后操作

第一阶段：尝试连接与初步诊断

当发现服务器“崩溃”时，第一步是确认状态，而不是立即重启。

尝试 SSH 登录
尝试从另一台机器 SSH 到服务器。如果成功，说明网络和 SSH 服务正常，问题可能出在特定应用或资源耗尽上。
使用“魔法键”SysRq（如果配置了）
这是最强大的一招，可以在内核完全卡死时获取信息或安全重启。前提是内核配置了
SysRq（System Request）是一个内建在 Linux 内核中的“后门”命令序列，它允许你在系统完全无响应（比如内核恐慌、死锁、负载极高）时，绕过正常系统流程，直接与内核对话，执行一些底层紧急操作。
如何启用和配置 SysRq？
检查是否启用：
```
cat /proc/sys/kernel/sysrq
```
- 0 - 完全禁用
- 1 - 完全启用
- 其他数字是位掩码，代表启用部分功能（例如 176 或 438 是常见值，表示启用了大部分安全操作）。
临时启用（推荐用于急救）：
```
echo 1 > /proc/sys/kernel/sysrq
```
永久启用：
编辑 /etc/sysctl.conf 文件，添加：
```
kernel.sysrq = 1
```
然后执行 sysctl -p 使其生效。
CONFIG_MAGIC_SYSRQ（默认通常开启）。
- 操作方式：依次按下 Alt + SysRq（在大多数键盘上，SysRq 就是 Print Screen 键），然后单独按下另一个键。
- 常用急救序列（REISUB）：这是一个“安全重启”的序列，能让内核以相对有序的方式重启，比直接断电要安全。
  - r：将键盘从 X Server 等程序夺回，交给内核控制。
  - e：向所有进程发送 SIGTERM 信号，要求它们优雅终止。
  - i：向所有进程发送 SIGKILL 信号，强制终止它们。
  - s：同步所有已挂载的文件系统，将缓存数据写入磁盘。
  - u：重新以只读方式挂载所有文件系统。
  - b：立即重启系统。
- 如何操作：如果服务器有 KVM（物理控制台），依次按下：Alt + SysRq（按住） -> r（松开） -> e（松开） -> i（松开） -> s（松开） -> u（松开） -> b（松开）。
- 启用 SysRq（如果默认未开启）：
```
echo "1" > /proc/sys/kernel/sysrq
# 或永久生效，编辑 /etc/sysctl.conf，添加：kernel.sysrq = 1
```
通过控制台连接（适用于云服务器）
如果你是阿里云、AWS、腾讯云等云服务用户，立即使用云平台提供的 VNC 或 Serial Console 功能。这相当于虚拟机的显示器，是诊断卡死问题的关键。

第二阶段：连接成功后的诊断命令

如果能通过 SSH 或 Console 登录，立即运行以下命令来定位问题根源。

检查系统负载和运行时间
```
uptime
```
- 看 load average，如果持续远高于 CPU 核心数，说明负载过高。
检查内存和交换空间
```
free -h
```
- 如果 free 内存几乎为 0，且 swap 被大量使用，说明内存不足，系统因频繁换页而卡死。
检查磁盘空间
```
df -h
```
- 重点检查根分区 / 和 /var、/home 等关键分区。如果使用率 100%，会导致服务崩溃。清理大文件：
```
# 查找大于100M的文件
find / -type f -size +100M -exec ls -lh {} \;
# 检查/var/log下的日志文件
du -sh /var/log/*
```
检查磁盘 I/O
```
iotop
```
- 如果没有 iotop，用 iostat -x 1。如果 %util 持续接近 100%，await 很高，说明磁盘 I/O 是瓶颈。
检查 CPU 和进程
```
top
# 或更强大的
htop
```
- 查看 %Cpu(s) 行：us（用户）高是应用问题，sy（系统）高是内核或系统调用频繁，wa（I/O 等待）高是磁盘瓶颈。
- 查看 %MEM 和 %CPU 列，找出消耗资源最多的进程。
检查内核日志
```
dmesg -T | tail -50
```
- 这是关键！ 内核日志通常会记录崩溃前最后的信息。查找 Oops、Kernel panic、Out of memory（OOM）、CPU#0、segfault 等关键字。
- OOM 表示内存耗尽，内核杀死了进程。
- Kernel panic 是严重的内核错误。

检查系统日志

journalctl -xe --no-pager | tail -100
# 或者对于使用 syslog 的系统
tail -100 /var/log/messages
tail -100 /var/log/syslog

第三阶段：针对性恢复操作

根据诊断结果采取行动。

内存耗尽 (OOM)
- 找到被 killed 的进程。
- 终止消耗内存过多的进程（如果它还在）：kill -9 <PID>。
- 考虑增加交换空间或物理内存。
- 调整应用的内存配置。
磁盘空间满
- 快速清理：
  - 清理日志：journalctl --vacuum-size=500M 或删除 /var/log 下旧的日志文件。
  - 清理包缓存：apt-get clean 或 yum clean all。
  - 查找并删除核心转储文件 (core.*) 或大型临时文件。
- 最直接的方法：删除或移动不需要的大文件。
CPU 或 I/O 瓶颈
- 使用 kill、pkill 或 killall 终止失控的进程。
- 使用 renice 调整进程优先级。
- 如果是业务高峰，可能需要扩容或优化应用。
内核崩溃 (Kernel Panic)
- 记录 dmesg 中的错误信息。
- 通常只能重启。重启后分析日志，查找原因（驱动bug、硬件故障、内核bug）。
个别服务无响应
- 尝试重启该服务：systemctl restart <service_name>。
- 查看该服务的日志：journalctl -u <service_name>。

第四阶段：最后的手段——重启

如果以上所有方法都无效，系统完全无响应，那么只能重启。

发送关机信号
```
shutdown -r now
```
或者
```
reboot
```
强制重启（有风险！）
- 如果 shutdown 命令也卡住，只能通过硬件方式：
  - 物理服务器：按住电源键 5-10 秒强制关机，再开机。
  - 云服务器：在云控制台上执行“强制重启”或“硬重启”。

警告：强制重启可能导致文件系统损坏，重启后可能需要进行 fsck 检查。

第五阶段：事后分析

服务器恢复后，工作并未结束。必须找出根本原因，防止再次发生。

分析日志
- 仔细查看崩溃时间点前后的 /var/log/messages、/var/log/syslog、dmesg 和 journalctl 日志。
检查系统资源使用趋势
- 使用 sar（需要安装 sysstat）查看历史 CPU、内存、I/O 数据。
配置监控告警
- 对磁盘使用率、内存使用率、CPU 负载、关键进程状态设置监控和告警。这是防止“急救”的最好方法。

急救工具箱（建议提前安装）

诊断工具: htop, iotop, iftop（网络）, nethogs
日志工具: journalctl（systemd）, logrotate
性能分析: sysstat（包含 sar, iostat）, perf
网络诊断: netstat, ss, tcpdump

posted on 2025-12-03 16:29 ljbguanli 阅读(0) 评论(0) 收藏举报