预约咨询 提交工单

Linux SRE 运维手册:生产服务器高负载故障排查实战

面向 SRE 的实用指南,系统地诊断和解决 Linux 生产服务器高负载问题,包含命令、风险控制和升级建议。

Linux SRE 运维手册:生产服务器高负载故障排查实战
DevOps 6min 11 浏览 2026-08-06
LinuxSRE高负载生产环境故障排查

Linux SRE 运维手册:生产服务器高负载故障排查实战

场景

凌晨 2 点,你的寻呼机响了。一台关键应用服务器的负载平均值在 16 核机器上达到了 30。客户请求开始超时。本手册将指导你系统地诊断和解决此类问题,避免事态升级。

症状

  • 负载平均值持续超过 CPU 核数(用 nproc 检查)。
  • SSH 会话反应迟钝,命令需要数秒才能返回。
  • 应用延迟飙升,健康检查开始失败。
  • uptime 显示 1 分钟、5 分钟和 15 分钟的平均负载都很高。

诊断步骤

  1. 快速快照
    运行 uptimecat /proc/loadavg 确认负载,同时记录 CPU 核数(nproc)。这是基线。

  2. 查找最热的进程
    使用 top -b -n 1 | head -30 获取快照,或使用交互式 htop(如果已安装)。更清晰的列表可用: bash ps -eo pid,ppid,user,cmd,%cpu,%mem --sort=-%cpu | head 查找消耗最多 CPU 的进程。如果没有明显嫌疑,接下来检查 I/O 和内存。

  3. 判断是 CPU 密集还是 I/O 密集
    运行 vmstat 1 5。关键列是 us(用户)、sy(系统)和 wa(I/O 等待)。如果 wa 持续很高(例如 >30%),问题在磁盘 I/O。如果 us/sy 占主导,则是 CPU 密集。

  4. 深入磁盘 I/O
    对于 I/O 密集型系统,使用 iostat -x 1 查看每个设备的利用率和队列长度。iotop(如果可用)显示每个进程的 I/O。注意那些日志守护进程、数据库检查点或备份任务是否在猛刷磁盘。

  5. 检查内存压力
    使用 free -m 并检查交换分区使用情况。一个正在大量交换的系统看起来负载很高。查看 dmesg 中的 oom-killer 消息。高内存压力也会导致操作系统级别的颠簸。

  6. 查看系统日志
    查看最近几分钟的错误: bash journalctl -p err -n 100 --since "10 min ago" 查找磁盘错误、systemd 服务失败或重复崩溃。

  7. 追踪进程
    如果某个特定进程陷入循环,小心地附加 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 测量延迟。
  • vmstatiostat 观察 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、数据库或监控系统出现类似问题,可以提交日志和配置文件,我们帮你远程诊断。

工单 WhatsApp 联系 咨询