服务器卡死排查流程

以下是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. 系统内核/全局日志（最核心）

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

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

• SSH 无响应：

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

• 桌面环境卡死：

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

• Docker/容器相关：

  sudojournalctl -u docker -b -1# Docker 服务日志docker logs --tail100可疑容器ID# 容器异常日志

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

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

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

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

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

2. 磁盘空间与健康状态

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

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

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

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

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

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

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

2. Docker/容器资源泄漏

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

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

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

4. 服务死锁/端口占用

# 查看服务状态sudosystemctl list-units --type=service --state=failed# 失败服务# 查看端口占用（避免端口冲突导致服务异常）sudonetstat-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% 以上的系统卡死问题，且所有操作均为命令行执行，无需复杂工具，适合技术人员快速落地。