Linux 系统故障快速定位实战经验

Ubuntu 教程

人工智能（AI）

postgres数据库

linux shell 新手简易教程

linux 行业新闻

核心思路：先宏观后微观、先外部后内部、先现象后根因。新手最容易犯的错是上来就钻进程 / 代码细节，结果浪费半小时，发现只是磁盘满了、防火墙没开。下面按「通用入场流程 + 7 大高频场景分步排查 + 实战避坑」整理，都是生产环境验证过的排障路径，照着走能大幅缩短定位时间。

一、通用入场流程：接到故障先做这 4 步

任何故障先别急着深挖，花 1 分钟做整体体检，快速缩小范围。

1. 先确认故障边界

先理清三个问题，避免无效排查：

• 是单台机器还是多台机器同时故障？（多台大概率是网络 / 交换机 / 依赖服务问题）

• 是完全不可用还是部分功能慢 / 报错？

• 故障是突然发生还是逐渐恶化？故障前后有没有发布、配置变更？

2. 入场必敲 4 条命令（1 分钟整体体检）

能 SSH 登录的情况下，依次执行，80% 的常见故障能直接找到线索：

uptime                  # 看负载高低、运行时长，判断系统整体压力dmesg -T | tail -30     # 看最近内核报错：OOM、磁盘IO错误、网络异常、硬件报错df -h                   # 排除磁盘满（根分区满会导致大量服务集体异常）systemctl --failed      # 看哪些系统服务失败，快速定位异常单元

3. 分层定位顺序（从易到难）

严格按「网络层→系统层→业务层」排查，不要跳步：

• 网络层：能不能 ping 通？端口能不能访问？

• 系统层：CPU / 内存 / 磁盘 / IO 是否正常？内核有没有报错？

• 业务层：进程在不在？日志有没有报错？配置对不对？

4. 锁定时间窗口

• 明确故障发生的准确时间点

• 对应时间点去匹配系统日志、业务日志、变更记录

• 历史故障用 sar、/var/log/messages 回溯

二、7 大高频故障场景分步排查

每个场景给出「最快排查路径」「关键命令」「高频根因」「避坑提醒」，可直接对照执行。

场景 1：系统卡顿、SSH 登录慢、操作无响应

排查路径

1、先测网络：ping 丢包 / 延迟高 → 优先查链路；能 ping 通但 ssh 极卡 → 查系统负载 / IO

2、登录后执行 vmstat 1，10 秒判断瓶颈类型：

• r列持续高于 CPU 核心数 → CPU 计算瓶颈

• b列持续大于 0 → IO 阻塞瓶颈（最常见）

3、iostat -x 1 确认磁盘 %util 是否打满

4、dmesg -T 看有没有磁盘 IO 错误、内核 hung task 软死锁报错

高频根因

• 磁盘 IO 打满，大量进程等待读写

• 内存耗尽，系统疯狂 Swap 换页，整体卡顿

• CPU 被占满，进程调度不过来

• 内核软死锁、磁盘硬件故障、文件系统损坏

避坑提醒

• 系统极卡时不要反复敲命令刷屏，会进一步加剧系统负担

• 完全连不上时，通过云控制台 / IPMI / 带外管理看控制台输出，判断是否已经死机

场景 2：服务启动失败 / 异常退出 / 频繁重启

排查路径（按优先级）

1. systemctl status 服务名 看退出码、最近一行报错

2. journalctl -u 服务名 -n 50 --no-pager 看服务启动日志，这是第一线索

3. 校验配置语法：如 nginx -t、mysqld --verbose --help

4. 检查端口占用：ss -lntp | grep 端口号

5. 检查文件 / 目录权限、属主是否正确

6. 检查依赖：依赖服务是否启动、依赖库文件是否存在

7. 终极手段：strace -f 启动命令 跟踪系统调用，看具体卡在哪一步

高频根因

• 配置文件语法错误（最常见）

• 端口被其他进程占用

• 目录 / 文件权限不足，尤其是非 root 运行的服务

• 磁盘满，无法写入日志或数据

• SELinux 安全策略拦截（新手最高频踩坑）

• 依赖库缺失、版本不兼容

避坑提醒

• 启动失败先看日志，不要反复重启，越重启现场越乱

• 权限看起来没问题但就是访问不了，先 setenforce 0 临时关闭 SELinux 验证，确认后再配置策略

• 服务异常退出，先去 dmesg 看是不是被 OOM killer 杀掉了

场景 3：磁盘空间满 / IO 夯住 / 读写无响应

子场景 A：磁盘空间告警

排查路径：

1. df -hT 定位哪个分区满、是什么文件系统

2. du -sh * | sort -hr | head -10 定位大目录，逐层向下收敛

3. lsof | grep deleted 排查「删除未释放」文件（df 和 du 数值不一致时必用）

4. 根分区满重点排查：/tmp、/var/log、/var/spool邮件队列、root 家目录

高频根因：日志未轮转、大文件误写入、临时文件未清理、邮件队列堆积。

子场景 B：IO 夯住、读写卡顿

排查路径：

1. iostat -x 1 看 %util（磁盘繁忙度）、await（IO 平均耗时）

2. iotop -oP 或 pidstat -d 1 定位高 IO 进程

3. lsof -p 进程PID 看进程在读写哪些文件

4. dmesg -T 看有没有 IO 错误、磁盘坏道报错

高频根因：日志疯狂刷盘、数据库大查询、随机读写过多、磁盘硬件故障。

避坑提醒

• 大日志文件不要直接rm，先 > 文件名 清空再删除，避免句柄残留导致空间不释放

• %util 100% 不代表磁盘吞吐量到顶，只代表 IO 请求占满，随机小 IO 场景很容易打满 util

场景 4：内存 OOM、进程被 Kill、内存泄漏

排查路径

1. 第一时间执行：dmesg -T | grep -i "out of memory"，确认是不是 OOM killer 杀了进程

2. free -h 看可用内存、Swap 使用趋势

3. ps aux --sort=-%mem | head -10 找内存占用 Top 进程

4. pidstat -r 1 观察进程内存是否持续上涨（判断是否泄漏）

5. 系统级分析：cat /proc/meminfo 看 slab、cache、buffer 分布

高频根因

• 业务程序内存泄漏，只申请不释放

• JVM / 中间件堆内存配置过大，超出物理内存

• 缓存占用失控、连接数爆炸导致内存暴涨

• 系统参数配置不合理，OOM 触发阈值过低

避坑提醒

• 不要看到used高就判定内存不足，Linux 的buffer/cache是可回收的，看available字段才准确

• Swap 持续上涨才是真的内存紧张，单纯 Swap used 高可能是历史换入的残留

• OOM killer 不杀内存最大的进程，杀得分最高的进程，不要默认被杀的就是元凶

场景 5：网络不通 / 端口不可达 / 服务访问超时

排查路径（从近到远，从易到难）

1. 本机自测：ss -lntp | grep 端口 确认服务是否在监听

2. 本地连通：nc -zv 127.0.0.1 端口 排除服务本身问题

3. 防火墙检查：firewall-cmd --list-ports / iptables -L 看端口是否放行

4. 链路排查：mtr --tcp -P 端口 目标IP 看逐跳丢包

5. 对端确认：目标机器安全组、防火墙是否拦截

6. 终极定位：两端同时tcpdump抓包，看数据包在哪一跳丢失

高频根因

• 防火墙 / 安全组未开放端口（最常见）

• 服务只监听了127.0.0.1，未监听0.0.0.0，外网无法访问

• 网络 ACL、交换机策略拦截

• DNS 解析失败、解析缓慢

• 运营商封禁端口

避坑提醒

• 先测本机再测网络，不要上来就找网络团队

• ping 不通不代表服务不通，很多服务器封禁 ICMP，测端口才是金标准

• 服务监听0.0.0.0和127.0.0.1天差地别，是新手高频配置错误

场景 6：CPU 飙高、负载异常

排查路径

1. uptime 看负载趋势，vmstat 1 判断是 CPU 密集还是 IO 等待

2. top 按P排序，定位 CPU 占比最高的进程

3. ps -T -p 进程PID 定位具体高消耗线程

4. 用户态 us 高：排查业务代码死循环、计算密集任务，配合堆栈工具分析

5. 内核态 sy 高：strace看系统调用，排查频繁创建销毁线程、大量 IO

6. 软中断 si 高：mpstat -P ALL 1 确认，配合sar -n DEV 1看网卡流量，排查大流量、攻击

高频根因

• 业务代码死循环、死锁

• 大量短连接导致上下文切换飙升

• 日志级别过低，疯狂刷盘消耗 CPU

• 网络流量过大，软中断占满 CPU

• 挖矿病毒、异常进程

避坑提醒

• 负载高≠CPU 满，IO 等待也会大幅拉高负载，先看wa占比

• 单线程程序打满单核，整体 CPU 占比不高但负载会上升，属于正常现象

• 不要上来就 kill 进程，先保留现场抓取堆栈信息

场景 7：系统意外宕机、自动重启

排查路径

1. last reboot 查看准确的重启时间点

2. uptime 确认本次运行时长，对齐故障时间

3. 查历史日志：journalctl -b -1 看上一次启动的系统日志

4. dmesg 看本次启动内核日志，有没有硬件报错、panic 记录

5. 重点排查：OOM、内核 panic、hung task、硬件错误

6. 云服务器同步查平台监控：是否宿主机故障、是否触发告警自动重启

高频根因

• 内核 panic（内核 bug、驱动问题、硬件故障）

• 内存耗尽，系统极端情况触发 panic

• 硬件故障：CPU、内存、磁盘坏道、电源异常

• 人工误操作重启

• 云平台宿主机故障迁移

避坑提醒

• 系统重启后第一时间备份日志，防止被日志轮转覆盖

• 多次无故重启，优先排查硬件和内存错误

• 核心服务器建议配置 kdump，宕机时生成内核转储文件方便定位

三、实战排障黄金经验与避坑指南

1. 排障优先级原则

• 先止损，后定位：生产环境优先恢复业务（重启、回滚、切流量），再慢慢排查根因

• 先易后难：先查磁盘满、服务挂、防火墙，再查代码、内核、硬件

• 先整体后细节：先看系统整体状态，再钻单个进程细节

2. 新手最容易忽略的排查点

• SELinux：权限看起来正常但就是访问不了，优先临时关闭验证

• DNS 解析：服务访问超时，很多时候是 DNS 解析慢 / 失败

• 时间同步：集群类服务异常，先看各节点时间是否一致

• 文件句柄数：出现too many open files，用ulimit -n检查打开文件数限制

3. 现场保留原则

• 关键故障不要第一时间重启进程 / 服务器，先保存日志、抓取堆栈、记录状态

• 重要操作前备份配置文件，修改操作留痕

• 故障排查过程的命令输出，尽量保存下来方便事后复盘

4. 常见认知误区

• 误区 1：负载高就是 CPU 满 → 70% 以上是 IO 瓶颈

• 误区 2：内存 used 高就是不够用 → 看available，cache 是可回收的

• 误区 3：ping 不通就是网络断了 → 多数是 ICMP 被封禁，测端口为准

• 误区 4：服务启动失败就是代码问题 → 80% 是配置、权限、端口、依赖问题