Linux SRE 运维手册:生产服务器高负载故障排查实战
场景
凌晨 2 点,你的寻呼机响了。一台关键应用服务器的负载平均值在 16 核机器上达到了 30。客户请求开始超时。本手册将指导你系统地诊断和解决此类问题,避免事态升级。
症状
- 负载平均值持续超过 CPU 核数(用
nproc检查)。 - SSH 会话反应迟钝,命令需要数秒才能返回。
- 应用延迟飙升,健康检查开始失败。
uptime显示 1 分钟、5 分钟和 15 分钟的平均负载都很高。
诊断步骤
-
快速快照
运行uptime和cat /proc/loadavg确认负载,同时记录 CPU 核数(nproc)。这是基线。 -
查找最热的进程
使用top -b -n 1 | head -30获取快照,或使用交互式htop(如果已安装)。更清晰的列表可用:bash ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head查找消耗最多 CPU 的进程。如果没有明显嫌疑,接下来检查 I/O 和内存。 -
判断是 CPU 密集还是 I/O 密集
运行vmstat 1 5。关键列是us(用户)、sy(系统)和wa(I/O 等待)。如果wa持续很高(例如 >30%),问题在磁盘 I/O。如果us/sy占主导,则是 CPU 密集。 -
深入磁盘 I/O
对于 I/O 密集型系统,使用iostat -x 1查看每个设备的利用率和队列长度。iotop(如果可用)显示每个进程的 I/O。注意那些日志守护进程、数据库检查点或备份任务是否在猛刷磁盘。 -
检查内存压力
使用free -m并检查交换分区使用情况。一个正在大量交换的系统看起来负载很高。查看dmesg中的oom-killer消息。高内存压力也会导致操作系统级别的颠簸。 -
查看系统日志
查看最近几分钟的错误:bash journalctl -p err -n 100 --since "10 min ago"查找磁盘错误、systemd 服务失败或重复崩溃。 -
追踪进程
如果某个特定进程陷入循环,小心地附加strace。例如,跟踪系统调用 10 秒并汇总:bash timeout 10 strace -c -p $PID这可以揭示无尽的 futex 调用(锁竞争)或文件 I/O。对于更深层次的内核剖析,perf top(以 root 身份)可能显示热门函数。
风险控制
- 不要盲目杀死进程。 始终用
ps -o user,pid,cmd -p $PID检查它是什么、属于谁。 - 使用
kill -TERM(优雅)优先于kill -KILL。 - 如果进程不关键,用
renice +20 -p $PID降低优先级。 - 对于 I/O 密集进程,用
ionice -c3 -p $PID设置为空闲 I/O 类。 - 修改配置文件前务必先复制备份,使用
cp file file.bak。 - 用
systemd-analyze verify /path/to/service测试任何 systemd 单元更改。
回滚计划
- 如果更改了服务配置,先验证再重启:
systemctl restart my-service。 - 如果删除了可疑的 cron 作业,从备份恢复 crontab。
- 如果安装了临时追踪工具,事件结束后卸载它。
- 始终记录更改了什么、何时更改,以便必要时还原。
验证
- 重新运行
uptime,确认负载平均值回落到健康范围(例如,对于你的工作负载,不超过 CPU 核数的 1.5 倍)。 - 用几个测试请求访问服务:
curl -w "@curl-format.txt" -o /dev/null -s https://your-api/health测量延迟。 - 用
vmstat和iostat观察 5-10 分钟,确保系统稳定。 - 检查日志中是否有新错误:
journalctl -p err --since "5 min ago"。
何时提交 OpsGlobal 工单
OpsGlobal 提供全天候远程 SRE 支持。出现以下情况时提交工单: - 解决了明显的进程或 I/O 问题后负载仍然很高。 - 怀疑内核 bug、驱动问题或文件系统损坏,需要深度专业知识。 - 根本原因不明,而业务正在蒙受损失。 - 你需要在复杂配置或性能调优任务上获得第二意见。
我们的 SRE 可以分析内核崩溃转储、使用高级跟踪工具,并帮助你构建长期修复方案。你还会获得事件后报告,以改进监控。
记住,系统化方法能节省时间。不要慌张,遵循本手册,并知道何时寻求帮助。
适用场景
适合正在处理 DevOps、Linux, SRE, 高负载, 生产环境 相关问题的团队,用于快速建立排查路径和交付标准。
问题背景
面向 SRE 的实用指南,系统地诊断和解决 Linux 生产服务器高负载问题,包含命令、风险控制和升级建议。
排查步骤
先确认影响范围和最近变更,再收集日志、配置、指标和链路数据,最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名,并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径,避免扩大故障影响。
回滚方案
保留原配置和发布版本;如修复后指标异常,立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题?
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题,可以提交日志和配置文件,我们帮你远程诊断。