LinuxSRE故障排查性能调优
场景
某生产环境 Linux 服务器（运行 Web 服务）响应缓慢，健康检查失败，用户报告延迟增加。
症状
uptime显示平均负载高于 CPU 核心数（如负载 20，CPU 16 核）。top中进程占用大量 CPU 或内存，或处于 D 状态（不可中断睡眠）。vmstat显示r列（运行队列）持续大于 CPU 核心数，或si/so非零（大量交换）。iostat显示磁盘利用率接近 100% 或 await 时间过高（>100ms）。- 外部 curl 请求超时或返回 5xx。
诊断步骤
- 快速概览：
uptime、free -h、df -h。 - CPU 分析：
top -bn1 | head -20，按 P 排序 CPU，按 M 排序内存。检查是否有异常进程。 - 内存分析：
vmstat 1 5检查交换活动。cat /proc/meminfo查看详细内存。 - 磁盘分析：
iostat -x 1 5关注%util、r/s、w/s、await。iotop查看具体进程 I/O。 - 网络分析：
netstat -tan | grep :80 | wc -l查看连接数，ss -tn更高效。 - 系统日志：
journalctl -u <服务名> --since "5 minutes ago"或tail -100 /var/log/syslog。 - 进程跟踪：
strace -p <PID> -c统计系统调用，找出耗时操作。
风险控制
- 不要随意 kill 进程：先
kill -0 <PID>测试，或使用kill -3 <PID>获取线程堆栈。 - 避免在生产环境直接重启服务，除非明确知道问题原因。
- 若怀疑资源泄漏，先保存
top和ps快照，再做操作。
回滚方案
- 若是最近配置变更：还原备份配置（如
/etc/nginx/nginx.conf.bak）。 - 若是软件更新：回退到前一版本（如
apt-get install <pkg>=<prev-version>）。 - 若无法快速定位，可重启服务或扩缩容（若使用容器编排）。
验证
- 确认服务恢复：
curl -I http://localhost:80返回 200。 - 检查负载：
uptime降至正常值。 - 监控指标：CPU 和内存使用回落，磁盘 I/O 降低。
- 运行预定义的健康检查脚本。
何时提交 OpsGlobal 工单
- 排查 30 分钟后仍未找到根因。
- 需要深入的内核级调试（如
perf、ftrace）。 - 问题涉及多节点或集群层面。
- 需要安排内核或硬件供应商介入。
提交工单时请附上以下信息：
- 时间窗口、症状描述。
- 已执行的命令输出（如 top -bn1、vmstat）。
- 相关日志片段。
适用场景
适合正在处理 DevOps、Linux, SRE, 故障排查, 性能调优 相关问题的团队，用于快速建立排查路径和交付标准。
问题背景
本文详细介绍了在生产环境中遇到 Linux 服务器性能问题时的排查步骤、命令、风险控制、回滚方案及何时联系 OpsGlobal 支持。
排查步骤
先确认影响范围和最近变更，再收集日志、配置、指标和链路数据，最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名，并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径，避免扩大故障影响。
回滚方案
保留原配置和发布版本；如修复后指标异常，立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题？
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题，可以提交日志和配置文件，我们帮你远程诊断。