IT运维实战：服务器突然卡死怎么办？5分钟定位根因
凌晨三点的电话
服务器告警响起，CPU 100%、磁盘IO爆满、SSH连接超时……这是每个运维人最不想面对的场景。今天教你一套"5分钟定位法"，快速找到故障根因。
第一步：确认是否还能SSH登录（30秒）
先尝试SSH连接：
ssh -v user@server_ip
三种情况：
现象 | 可能原因 | 下一步
---|---|---
完全无响应 | 内核崩溃或网络故障 | 联系机房重启
连接后卡住 | CPU/内存耗尽 | 强制中断后进单用户模式
能登录但很慢 | CPU/IO高负载 | 继续排查
第二步：查看系统负载（1分钟）
登录后立即执行：
# 查看负载
uptime
# 查看CPU占用TOP10
top -b -n 1 | head -20
# 查看IO占用
iostat -x 1 3
关键指标解读：
指标 | 正常值 | 异常值 | 常见原因
---|---|---|---
load average | < CPU核数 | > CPU核数*2 | 进程堆积
%us | < 70% | > 90% | CPU密集型任务
%sy | < 30% | > 50% | 内核开销大
%iowait | < 10% | > 30% | 磁盘瓶颈
%id | > 20% | < 5% | 资源耗尽
第三步：定位罪魁祸首（1分钟）
找到异常进程：
# 按CPU排序
top -o %CPU
# 按内存排序
top -o %MEM
# 查看进程详情
pidstat -p <PID> 1 5
常见异常进程：
进程名 | 可能原因 | 处理方式
---|---|---
java | 内存泄漏/GC频繁 | 分析日志，重启服务
mysql | 慢查询/死锁 | 查看slow log
python | 死循环/大文件处理 | 检查脚本逻辑
kworker | 内核线程异常 | 检查内核版本
[kswapd0] | 内存不足 | 释放内存或扩容
第四步：分析进程行为（1分钟）
找到可疑进程后，看它在做什么：
# 查看进程打开的文件
lsof -p <PID> | head -50
# 查看进程的系统调用
strace -p <PID> -c
# 查看进程的线程状态
pstack <PID>
典型案例：
案例1：Java进程CPU爆满
# 找到高CPU线程
top -H -p <PID>
# 线程ID转16进制
printf "%x\n" <TID>
# 导出线程栈
jstack <PID> | grep -A 50 <HEX_TID>
常见原因：死循环、频繁GC、正则回溯
案例2：MySQL进程IO爆满
# 查看当前查询
mysql -e "show processlist"
# 查看慢查询日志
mysqldumpslow -s t /var/log/mysql/slow.log | head -10
常见原因：全表扫描、大表JOIN、无索引查询
第五步：快速止血（1.5分钟）
方案A：优雅处理
# 发送SIGTERM，进程可优雅退出
kill <PID>
# 如果30秒后还在，强制终止
kill -9 <PID>
方案B：紧急降级
# 限制进程CPU使用
cpulimit -p <PID> -l 50
# 限制进程内存
systemctl set-property <SERVICE> MemoryLimit=2G
方案C：服务重启
# 重启服务
systemctl restart <SERVICE>
# 如果服务卡住，强制终止后重启
systemctl kill <SERVICE> --kill-who=main
systemctl start <SERVICE>
实战案例复盘
场景：Nginx服务器CPU 100%
现象：
- CPU持续100%
- 网站响应缓慢
- SSH能登录但卡顿
排查过程：
# 1. 查看负载
uptime
# 输出：load average: 32.15, 28.10, 25.05 (严重过载)
# 2. 查看TOP进程
top -b -n 1 | head -20
# 发现：nginx进程占满CPU，进程数异常（正常8个，现在200+）
# 3. 查看nginx状态
ss -tunlp | grep nginx
# 发现：大量TIME_WAIT连接，连接数异常
# 4. 查看访问日志
tail -f /var/log/nginx/access.log
# 发现：同一IP高频请求，疑似攻击
# 5. 应急处理
iptables -I INPUT -s <攻击IP> -j DROP
systemctl restart nginx
# 6. 恢复正常
uptime
# 输出：load average: 2.10, 5.20, 8.15 (恢复正常)
根因： 遭受CC攻击，大量恶意请求耗尽worker进程。
长期方案： 配置limit_req模块限制单IP请求频率。
预防措施
1\. 监控要先于故障
监控项 | 告警阈值 | 工具推荐
---|---|---
CPU使用率 | >80%持续5分钟 | Prometheus + Grafana
内存使用率 | >85% | Node Exporter
磁盘IO | >70%持续3分钟 | iostat
网络流量 | >80%带宽 | iftop
2\. 日志要集中存储
# 推荐方案：ELK/Loki
# 关键：日志保留30天，支持全文检索
3\. 预案要提前演练
每个季度进行一次故障演练：
- 模拟CPU满载
- 模拟磁盘满
- 模拟服务崩溃
常用排查命令速查表
# 综合诊断
sar -u 1 5 # CPU使用情况
sar -r 1 5 # 内存使用情况
sar -d 1 5 # 磁盘IO情况
sar -n DEV 1 5 # 网络流量情况
# 进程分析
ps aux --sort=-%cpu | head # CPU占用TOP10
ps aux --sort=-%mem | head # 内存占用TOP10
pgrep -f <关键词> | xargs ps -p # 按关键词查进程
# 网络分析
netstat -tunlp # 监听端口
ss -s # 连接统计
lsof -i :<PORT> # 端口占用
# 磁盘分析
df -h # 磁盘空间
du -sh /* | sort -h # 目录大小
lsof | grep deleted # 已删除但占用空间的文件
总结
服务器卡死排查五步法：
- 确认状态 — SSH能否登录
- 查看负载 — uptime + top + iostat
- 定位进程 — top -o %CPU
- 分析行为 — lsof + strace + pstack
- 快速止血 — kill/restart/limit
记住：先止血再分析，先定位再处理。5分钟内找到根因，10分钟内恢复服务。