深入解析：Linux服务器崩溃急救攻略
这是一份非常实用的 Linux 服务器崩溃急救指南。当服务器出现无响应、无法通过 SSH 登录、卡死等情况时，请按照以下步骤进行排查和恢复。
核心原则：保持冷静，先诊断，后操作
第一阶段：尝试连接与初步诊断
当发现服务器“崩溃”时，第一步是确认状态，而不是立即重启。
尝试 SSH 登录
尝试从另一台机器 SSH 到服务器。如果成功，说明网络和 SSH 服务正常，问题可能出在特定应用或资源耗尽上。使用“魔法键”SysRq（如果配置了）
这是最强大的一招，可以在内核完全卡死时获取信息或安全重启。前提是内核配置了SysRq（System Request）是一个内建在 Linux 内核中的“后门”命令序列，它允许你在系统完全无响应（比如内核恐慌、死锁、负载极高）时，绕过正常系统流程，直接与内核对话，执行一些底层紧急操作。
如何启用和配置 SysRq？
检查是否启用：
cat /proc/sys/kernel/sysrq0- 完全禁用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
