一次生产故障完整复盘：Linux 排查全流程实录

张开发
• 2026/4/16 1:11:17 • 15 分钟阅读

最新文章

推荐文章

相关文章

分享文章

一次生产故障完整复盘：Linux 排查全流程实录
文章目录引言一、故障全览：时间线与因果链二、逐阶段深入：每个决策背后的原理阶段一：CPU 飙升——先确认热点进程阶段二：内存增长——区分正常缓存与泄漏阶段三：OOM Kill——理解选择逻辑阶段四：磁盘写满——理解写入在哪里发生阶段五：SSH 失联——控制台是最后的安全网阶段六：数据抢救——先保现场，再救数据三、根因分析：为什么从一条慢查询蔓延到系统瘫痪四、改进清单：每一项对应根因链上的一个断点五、复盘工具链：按场景整理六、知识串联：这篇文章整合了前面哪些内容总结引言某台跑着 MySQL + Nginx 的 CentOS 7 服务器，凌晨 03:17 收到 Zabbix 告警——CPU 使用率瞬间破 90%。从登录服务器到服务完全恢复，一共用了 47 分钟。这 47 分钟里，CPU 飙升只是开场，内存泄漏是推手，OOM Kill 触发了连锁反应，磁盘写满导致远程连接彻底断开，最后靠 IPMI 控制台才挤进服务器救出数据。前面十三篇文章拆开了讲 CPU、内存、IO、网络、systemd、安全加固的知识点。这一篇把它们串起来：每个决策都有时间窗口的压力，没有机会回头重来。一、故障全览：时间线与因果链先建立整体视图，理解这条链才能明白每一步为什么要那样走。磁盘子系统OOM KillerMySQL值守工程师服务器系统Zabbix 监控磁盘子系统OOM KillerMySQL值守工程师服务器系统Zabbix 监控第一阶段 · CPU 飙升（03:17 - 03:21）确认是 Java 服务异常，MySQL CPU 占用正常第二阶段 · 内存泄漏（03:21 - 03:29）内存增长速率不均衡，不是正常的 Page Cache 抖动第三阶段 · OOM Kill 触发（03:29 - 03:34）Java 进程同样被 kill，/var/crash 目录下瞬间堆积大量 core dump第四阶段 · 磁盘写满（03:34 - 03:42）core dump 写入 /var/crash，磁盘空间瞬间归零第五阶段 · SSH 失联（03:42 - 03:50）切换到 IPMI/BMC 控制台直连第六阶段 · 数据抢救（03:50 - 04:04）MySQL 配置 lower_case_table_names=1，重启后表名大小写一致性得到保证03:17 CPU 90% 告警SSH 登录服务器top -c 发现 java 进程 CPU 占用 780%java 进程 PID=15234，子进程数量偏多free -m，可用内存从 8GB 跌至 300MBfor x in $(seq 1 10)do ps aux --sort=-rss | head -5sleep 3done

更多文章