1. Linux服务器故障急救指南概述
当Linux服务器出现CPU、内存或磁盘满载时，系统性能会急剧下降，甚至导致服务不可用。作为运维人员，我们需要快速定位问题根源并采取有效措施。本文将分享我在处理这类故障时的实战经验，涵盖从基础检查到高级诊断的全套流程。
服务器资源满载通常表现为：响应缓慢、SSH连接困难、服务异常退出等。此时我们需要保持冷静，按照优先级处理——先恢复服务可用性，再深入分析根本原因。记住一个原则：在故障现场尽量少做破坏性操作，优先收集诊断信息。
2. CPU满载问题排查与处理
2.1 快速定位高CPU进程
当CPU使用率达到100%时，首先通过top命令查看整体情况：
bash复制top -c -o %CPU
重点关注：
- 第一行的load average值（1/5/15分钟平均负载）
- %CPU列显示各进程的CPU占用率
- COMMAND列显示完整命令行参数
如果发现某个进程异常占用CPU，可以进一步用perf工具采样：
bash复制perf top -p <PID>
2.2 Java应用CPU高的专项处理
对于Java应用，常规的top命令可能只能看到Java进程本身占用高，需要使用线程级分析：
bash复制# 显示Java进程的线程CPU使用
top -H -p <Java_PID>
# 或使用jstack配合线程ID转换
jstack <Java_PID> | grep -A 20 <nid>
常见原因：
- 死循环或低效算法
- 锁竞争激烈
- GC频繁（可通过jstat -gcutil观察）
2.3 应急处理措施
当确定问题进程后，根据情况选择：
- 如果是非关键业务进程：用kill -9立即终止
- 如果是核心服务：先保留现场信息再重启
bash复制# 保存进程内存映射 pmap -x <PID> > /tmp/pmap_<PID>.log # 保存线程栈 jstack <PID> > /tmp/jstack_<PID>.log - 如果是突发流量导致：考虑临时限流
bash复制# 使用tc限制某个进程的网络带宽 tc qdisc add dev eth0 root handle 1: htb tc class add dev eth0 parent 1: classid 1:1 htb rate 1mbit tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1: cgroup
3. 内存耗尽问题解决方案
3.1 内存使用分析
使用free命令查看内存概况：
bash复制free -h
重点关注：
- available字段（真正可用的内存）
- buffers/cache的使用情况
更详细的分析可以使用smem工具：
bash复制smem -s swap -r
3.2 找出内存泄漏进程
常见内存泄漏检测方法：
- 监控进程的RSS增长趋势：
bash复制watch -n 1 'ps -eo pid,comm,rss | sort -k3 -n' - 使用valgrind检测（需重启应用）：
bash复制
valgrind --leak-check=full ./your_app - 对于Java应用，使用jmap生成堆转储：
bash复制
jmap -dump:live,format=b,file=heap.hprof <PID>
3.3 应急释放内存
当内存不足时，可以尝试：
- 清理page cache：
bash复制sync; echo 1 > /proc/sys/vm/drop_caches - 终止内存占用高的非关键进程
- 调整swappiness值临时增加swap使用：
bash复制
sysctl vm.swappiness=60
4. 磁盘空间占满处理流程
4.1 快速定位大文件
使用ncdu工具交互式查看磁盘使用：
bash复制ncdu -x /
或使用find命令查找大文件：
bash复制find / -type f -size +100M -exec ls -lh {} \;
4.2 日志文件处理
常见的日志清理策略：
- 按时间轮转：
bash复制
logrotate -f /etc/logrotate.conf - 清空大日志文件（不要直接删除）：
bash复制
: > /var/log/large.log - 使用journalctl清理系统日志：
bash复制
journalctl --vacuum-size=100M
4.3 特殊文件系统问题
处理inode耗尽的情况：
bash复制df -i # 查看inode使用
find / -xdev -printf '%h\n' | sort | uniq -c | sort -n
处理僵尸文件（已删除但进程仍持有）：
bash复制lsof | grep deleted
5. 综合故障处理技巧
5.1 系统资源监控配置
建议提前部署监控系统，如：
- 基础监控（CPU/内存/磁盘）：
bash复制# 使用sar记录系统指标 sar -u -r -d 1 60 > system_stats.log - 进程级监控：
bash复制
pidstat 1 60
5.2 自动化处理脚本示例
创建资源告警自动处理脚本：
bash复制#!/bin/bash
# CPU监控
if [ $(uptime | awk '{print $NF*1}') -gt 4 ]; then
top -b -n 1 > /tmp/high_load_$(date +%s).log
# 自动重启非核心服务
systemctl list-units --type=service | grep -v 'critical' | awk '{print $1}' | xargs -I{} systemctl restart {}
fi
# 内存监控
if [ $(free -m | awk '/Mem:/ {print $7}') -lt 100 ]; then
sync; echo 1 > /proc/sys/vm/drop_caches
fi
# 磁盘监控
if [ $(df / --output=pcent | tail -1 | tr -d '%') -gt 90 ]; then
find /var/log -type f -name "*.log" -size +10M -exec truncate -s 0 {} \;
fi
5.3 性能优化建议
长期优化方案：
-
CPU密集型应用：
- 使用taskset绑定CPU核心
- 考虑使用cgroups限制资源
-
内存优化：
- 调整透明大页设置：
bash复制echo never > /sys/kernel/mm/transparent_hugepage/enabled - 优化swappiness参数：
bash复制
sysctl vm.swappiness=10
- 调整透明大页设置：
-
磁盘IO优化：
- 使用ionice调整IO优先级：
bash复制
ionice -c 2 -n 0 -p <PID> - 考虑使用deadline调度器：
bash复制echo deadline > /sys/block/sda/queue/scheduler
- 使用ionice调整IO优先级：
6. 常见问题排查实录
6.1 故障现象与解决方案对照表
| 故障现象 | 可能原因 | 解决方案 |
|---|---|---|
| SSH连接缓慢 | 高CPU导致认证延迟 | 通过控制台连接，检查auth日志 |
| 服务频繁OOM | 内存泄漏或配置不足 | 调整JVM参数，添加swap |
| 磁盘写入失败 | inode耗尽 | 删除小文件或迁移数据 |
| 系统卡顿但资源显示充足 | 可能IO等待高 | 使用iostat检查磁盘负载 |
6.2 诊断工具速查表
| 工具 | 用途 | 常用参数 |
|---|---|---|
| top | 实时进程监控 | -c -o %CPU |
| vmstat | 系统整体状态 | 1 5 |
| iostat | 磁盘IO统计 | -x 1 |
| pidstat | 进程级统计 | -urd -p PID |
| strace | 系统调用跟踪 | -p PID -ff -o trace.log |
6.3 避坑经验分享
- 不要在生产环境直接使用kill -9，先尝试kill -15
- 清理日志文件时使用truncate而非rm，避免影响已打开文件的进程
- 高负载时避免执行find /等全盘扫描操作
- 使用maldet定期扫描可能的挖矿病毒
- 对于Docker容器，内存限制可能引发OOM，需合理配置--memory参数