服务器卡死排查流程

以下是 Linux 物理机/云服务器系统卡死的标准化排查流程（兼顾命令行/桌面环境、Docker/服务部署场景），按「紧急恢复→日志溯源→资源排查→深度定位→预防优化」五步执行，直接复制命令即可操作，覆盖 90% 常见卡死场景：

一、紧急恢复：先解决「连不上」的问题（5分钟内）

系统卡死时优先恢复可操作性，再排查根因：

1. 物理机/云服务器区分处理 ：

   • 物理机：直接按电源键强制重启（无其他办法）；
   • 云服务器：通过控制台「强制重启」→ 用网页/VNC终端登录（避免 SSH 依赖）。

2. 单用户模式应急（可选，针对重启后仍卡） ：
   重启时按 Shift 进入 GRUB 菜单→选中系统→按 e 编辑→在 linux 行末尾加 init=/bin/bash→Ctrl+X 启动：

   mount -o remount,rw /  # 挂载根目录为可写
   # 临时禁用可能冲突的服务（如显卡驱动、Docker）
   echo "modprobe.blacklist=amdgpu" > /etc/modprobe.d/emergency.conf
   systemctl disable --now docker  # 若怀疑容器占用资源
   exec /sbin/init  # 恢复正常启动

二、日志溯源：定位卡死前的异常（核心步骤，10分钟）

系统重启后，优先通过日志找「卡死瞬间的关键报错」，重点看 上一次启动周期的日志：

1. 系统内核/全局日志（最核心）

# 查看上一次启动的完整日志（卡死前的所有记录）
sudo journalctl -b -1 --no-pager | tee last_boot.log
# 过滤关键错误关键词（快速定位）
sudo journalctl -b -1 | grep -E "oom|kill|panic|error|warn|I/O error|soft lockup" --color=auto

2. 关键服务日志（按场景筛选）

• SSH 无响应 ：

  sudo journalctl -u sshd -b -1  # SSH 服务日志
  sudo grep sshd /var/log/auth.log.1  # 登录日志备份

• 桌面环境卡死 ：

  sudo journalctl -u gdm -b -1  # GNOME 显示管理器日志
  sudo cat /var/log/Xorg.0.log.old  # X 服务器日志

• Docker/容器相关 ：

  sudo journalctl -u docker -b -1  # Docker 服务日志
  docker logs --tail 100 可疑容器ID  # 容器异常日志

3. 日志关键词对应根因表

关键词	大概率根因	应急处理
Out of memory: Killed	内存耗尽（OOM）	限制进程内存/增加Swap/优化程序
kernel panic	内核崩溃（驱动/硬件冲突）	回滚内核/禁用冲突驱动
CPU soft lockup	CPU 死锁（内核/进程异常）	杀死占用CPU的进程/更新内核
I/O error	磁盘故障/挂载异常	检查磁盘健康/重新挂载分区
drm 重复初始化	显卡驱动异常（如 amdgpu）	调整驱动参数（如 runpm=0）
max sessions reached	SSH 连接数耗尽	增加 SSH 最大连接数限制

三、资源排查：确认是否「资源耗尽」导致卡死（5分钟）

系统卡死最常见原因是 CPU/内存/磁盘耗尽，重启后通过工具回溯历史状态：

1. 内存/CPU 历史占用（需 sysstat 工具）

# 安装 sysstat（若未安装）
sudo apt install sysstat -y
# 查看上一次启动的 CPU 占用（%idle 接近0=CPU耗尽）
sudo sar -u -f /var/log/sysstat/sa$(date +%d -d "yesterday")
# 查看上一次启动的内存占用（%memused 接近100%=内存耗尽）
sudo sar -r -f /var/log/sysstat/sa$(date +%d -d "yesterday")

2. 磁盘空间与健康状态

# 查看磁盘占用（/ 分区满=卡死常见原因）
df -h
# 查找大文件（日志/缓存暴增）
sudo find / -type f -size +1G -mtime -1  # 1天内新增的1G+文件
# 检查磁盘健康（物理机）
sudo apt install smartmontools -y
sudo smartctl -a /dev/sda  # 替换 /dev/sda 为系统磁盘

3. 进程异常排查（重启后仍高负载）

# 实时查看高负载进程
top  # 按 P 排序CPU，按 M 排序内存
# 查看历史占用最高的进程
ps aux --sort=-%cpu | head -10  # CPU 最高
ps aux --sort=-%mem | head -10  # 内存最高

四、深度定位：针对高频场景的专项排查（10分钟）

若基础排查无结果，按场景专项定位：

1. 显卡驱动异常（桌面环境/物理机）

# 查看显卡驱动状态
sudo lshw -C display  # 确认驱动是否加载
dmesg | grep -i "drm"  # 驱动初始化日志
# 若驱动重复初始化，添加优化参数（如 amdgpu）
sudo vi /etc/default/grub  # 追加 amdgpu.runpm=0 等参数
sudo update-grub && sudo reboot

2. Docker/容器资源泄漏

# 查看容器资源限制与占用
docker stats --no-stream  # 实时资源占用
docker inspect 容器ID | grep -i "memory"  # 查看内存限制
# 排查容器日志暴增
docker system df  # 查看容器/镜像占用
sudo du -sh /var/lib/docker/containers/*  # 容器日志大小

3. 内核/硬件兼容性问题

# 查看内核版本
uname -r
# 查看内核错误日志
dmesg | grep -i "bug\|warn\|error"
# 检查硬件温度（物理机）
sudo apt install lm-sensors -y
sudo sensors  # CPU/显卡温度过高=卡死风险

4. 服务死锁/端口占用

# 查看服务状态
sudo systemctl list-units --type=service --state=failed  # 失败服务
# 查看端口占用（避免端口冲突导致服务异常）
sudo netstat -tulpn | grep -E ":22|:80|:3306"  # 常用端口

五、预防优化：避免再次卡死（长期保障）

排查完后，执行以下优化避免复发：

1. 资源限制 ：
   • Docker 容器添加内存/CPU限制：docker run --memory=4G --cpus=2 ...；
   • 给进程设置 OOM 优先级：echo "-1000" > /proc/进程ID/oom_score_adj（避免核心服务被杀死）。
2. 日志管理 ：
   • 配置 logrotate 自动轮转日志（避免日志占满磁盘）；
   • 限制 Docker 容器日志大小：docker run --log-opt max-size=100m --log-opt max-file=3 ...。
3. 监控告警 ：
   • 安装 zabbix/prometheus 监控 CPU/内存/磁盘；
   • 简单脚本告警（示例：内存占用超 90% 发邮件）。
4. 内核与驱动 ：
   • 物理机使用 LTS 内核（如 Ubuntu 22.04 的 5.15 内核）；
   • 显卡驱动优先使用官方稳定版，避免盲目更新。

总结：排查流程速记（按优先级）

1. 紧急重启→网页/VNC登录；
2. 查上一次启动日志（journalctl -b -1）；
3. 用 sar 看资源占用历史；
4. 按场景专项排查（驱动/Docker/磁盘）；
5. 优化配置避免复发。

按此流程，可在 30 分钟内定位 90% 以上的系统卡死问题，且所有操作均为命令行执行，无需复杂工具，适合技术人员快速落地。