Linux服务器故障排查实战：从CPU 100%到OOM的通用解决思路

深夜接到告警服务器CPU飙到100%业务接口大面积超时登录系统一看满屏的进程和日志该从何下手这大概是每一位运维工程师都经历过的“至暗时刻”。故障排查远不止是敲几个命令看看日志那么简单它更像是一场与未知问题的“侦探游戏”需要清晰的思路、科学的方法和丰富的经验作为支撑。本文旨在为你梳理一套在Linux环境下“万能”的故障排查通用思路与方法论。无论你面对的是性能瓶颈、服务异常还是网络故障这套结构化流程都能帮助你快速定位问题根因而不是在问题表面盲目尝试。我们将从核心原则出发拆解标准排查步骤并结合CPU、内存、磁盘、网络等经典场景的实战案例最后分享能融入日常工作的提效脚本与习惯。无论你是刚入行的运维新人还是希望体系化自己排查能力的老手都能从中获得可直接复用的价值。1. 故障排查的核心原则与心态准备在接触具体命令和案例之前建立正确的排查“心法”比掌握“招式”更重要。错误的开端往往导致在错误的方向上浪费大量时间。1.1 黄金法则假设与验证永远不要盲目相信你的第一直觉。故障排查是一个不断提出假设并用证据去验证或推翻假设的科学过程。基于现象提出假设例如“网站访问慢”可能是前端资源加载慢、可能是后端API响应慢、也可能是数据库查询慢。设计验证实验针对每个假设设计一个可验证的检查点。例如用浏览器开发者工具查看网络请求时序用curl命令测试API接口用数据库客户端执行慢查询。收集证据并判断根据实验结果判断假设是否成立。成立的假设成为新的线索不成立的假设被排除缩小问题范围。1.2 必须遵守的纪律变更控制与回滚预案在排查过程中尤其是生产环境任何修改操作都必须谨慎。变更前备份修改配置文件前先复制备份。例如cp nginx.conf nginx.conf.bak.$(date %Y%m%d%H%M)。一次只做一个变更同时修改多个地方一旦问题解决或恶化你无法确定是哪个变更生效的。准备好回滚方案在执行可能影响服务的操作如重启服务、更新软件包前必须明确知道如何快速回退到操作前的状态。对于关键服务应在业务低峰期操作。1.3 信息收集先问“是什么”再想“为什么”遇到问题不要急于思考“为什么会出现这个问题”而应该先全面、准确地收集“问题现在是什么状态”。这包括故障现象用户报告的错误信息是什么监控图表如Zabbix、Prometheus显示了哪些异常指标CPU、内存、磁盘IO、网络流量、错误率、延迟影响范围是所有用户都受影响还是特定地区、特定功能是单台机器还是整个集群发生时间故障是何时开始的是突然出现还是缓慢恶化是否与最近的某个变更发布、配置更新、数据迁移时间点吻合相关日志系统日志/var/log/messages、内核日志dmesg、应用日志、中间件日志Nginx, Tomcat, MySQL中有无错误、警告或异常模式2. 故障排查标准化流程六步法将上述原则落地可以形成一套标准化的排查流程适用于绝大多数故障场景。2.1 第一步明确问题与影响评估首先用一句话清晰定义问题。例如“从15:30开始订单提交API的平均响应时间从50ms上升至2000ms导致前端页面超时用户投诉激增。” 同时快速评估影响面业务功能、用户量、收入损失决定响应优先级。如果是核心业务瘫痪可能需要立即启动应急预案如切换流量、服务重启而非按部就班排查。2.2 第二步信息收集与现象复现根据第一步的定义系统地收集信息。检查监控系统查看相关服务器和服务的核心指标历史趋势图。登录目标服务器使用ssh连接首先检查系统整体状态。# 快速查看系统概览 uptime # 查看负载 top -c -n 1 # 查看进程按CPU排序 free -h # 查看内存使用 df -h # 查看磁盘空间 ss -tulnp | head -20 # 查看网络连接和监听端口收集关键日志使用tail,grep,less等命令查看最新或特定的错误日志。# 查看应用最近100行日志并过滤错误 tail -n 100 /path/to/your/app.log | grep -i error # 动态跟踪日志文件 tail -f /var/log/nginx/access.log2.3 第三步定位问题边界缩小范围目标是确定问题是出在哪个层次、哪个组件。是网络问题吗从客户端到服务器链路是否通畅使用ping,traceroute,mtr测试。是服务器资源问题吗使用top,vmstat 1,iostat -xz 1持续观察CPU、内存、磁盘IO。是应用进程问题吗进程是否存活ps aux | grep [进程名]。进程状态是S(睡眠)、R(运行)还是Z(僵尸)是依赖服务问题吗数据库、缓存、消息队列是否可连接且响应正常使用telnet或专用客户端测试。是配置问题吗对比故障前后的配置文件差异。2.4 第四步根因分析与深入探查找到可疑组件后进行深入分析。高CPU使用top -Hp [PID]查看进程内哪个线程CPU高结合jstack(Java) 或pstack/gdb(C/C) 查看线程栈定位到具体代码。高内存使用pmap -x [PID]查看进程内存映射或jmap -heap(Java) 分析堆内存。检查是否有内存泄漏。高磁盘IO使用iotop或pidstat -d 1查看是哪个进程在大量读写磁盘。慢查询开启数据库慢查询日志使用explain分析SQL执行计划。死锁检查数据库死锁日志或应用日志中的相关线程阻塞信息。2.5 第五步制定与实施解决方案根据根因制定解决方案。紧急恢复对于线上紧急故障可能先采取“止血”措施如重启服务、扩容实例、重启服务器。但这只是临时方案。根本解决修复Bug的代码、优化低效的SQL、调整不合理的JVM参数、清理无用的日志文件、升级存在漏洞的库等。实施变更严格按照变更控制流程在测试环境验证后再灰度发布到生产环境。2.6 第六步复盘与改进故障解决后工作并未结束。撰写故障报告记录故障时间线、根因、处理过程、影响、改进措施。完善监控告警本次故障是否因监控缺失未能提前发现补充关键指标告警。优化预案与工具本次排查过程是否低效编写或优化排查脚本固化排查路径。进行知识分享在团队内部分享避免类似问题再次发生。3. 核心资源类故障排查实战让我们将上述流程应用到几个最常见的资源类故障场景中。3.1 场景一CPU使用率100%排查现象top命令显示CPU使用率接近100%系统响应缓慢。排查步骤定位高CPU进程top命令中看%CPU列找到占用最高的进程PID。定位高CPU线程top -Hp [高CPU进程的PID]查看该进程内哪个线程TID消耗高。分析线程栈以Java进程为例# 将十进制的线程ID转换为十六进制jstack输出是十六进制 printf %x\n [高CPU线程的TID] # 获取Java进程的线程栈 jstack [Java进程的PID] /tmp/thread_dump.txt # 在thread_dump.txt中搜索上一步得到的十六进制线程ID找到对应的线程栈信息 grep -A 20 -B 5 [十六进制线程ID] /tmp/thread_dump.txt线程栈会显示线程正在执行哪个类的哪个方法通常能直接定位到问题代码如死循环、密集计算。其他可能原因频繁的GC通过jstat -gcutil查看、加密解密操作、正则表达式回溯等。3.2 场景二内存耗尽OOM排查现象系统可用内存(free)极少可能触发OOM Killer杀死进程应用报OutOfMemoryError。排查步骤查看整体内存free -h关注available列。使用slabtop查看内核 slab 使用情况。定位内存消耗进程top命令按内存排序在top界面按ShiftM。深入分析进程内存以Java为例# 查看JVM堆内存概要 jmap -heap [PID] # 生成堆转储文件生产环境慎用文件大会暂停应用 jmap -dump:live,formatb,file/tmp/heap.hprof [PID] # 使用MAT、JVisualVM等工具分析heap.hprof文件查找内存中数量最多的对象。排查非堆内存使用pmap -x [PID]查看进程地址空间关注[anon]匿名映射如线程栈、malloc分配和共享库的占用。常见原因内存泄漏对象被无意识持有、缓存无限增长、大文件读取、JVM堆参数设置不合理。3.3 场景三磁盘空间不足与IO瓶颈现象df -h显示某个分区使用率100%或iostat显示%util持续接近100%应用读写超时。排查步骤定位大文件或目录# 查看根目录下哪个文件夹最大 du -sh /* 2/dev/null | sort -hr | head -10 # 逐层深入找到具体的大文件 du -sh /var/log/* | sort -hr | head -10 # 查找大于100M的文件 find / -type f -size 100M 2/dev/null | xargs ls -lh定位大量小文件有时是海量小文件占用了inode。使用df -i查看inode使用率。定位IO高的进程# 使用iotop可能需要安装 iotop -o # 或使用pidstat pidstat -d 1分析IO类型使用iostat -xz 1关注await平均等待时间和%util利用率。高await通常意味着磁盘忙。常见原因日志未轮转如Log4j配置不当、临时文件未清理、数据库表空间暴涨、程序异常写文件。3.4 场景四网络连接故障现象应用无法连接数据库、服务间调用超时、用户无法访问网站。排查步骤从底层到上层本地网络配置ip addr查看IP是否正确route -n查看路由表。本地端口监听ss -tulnp | grep [端口号]或netstat -tulnp确认服务是否在监听预期端口。本地防火墙iptables -L -n或firewall-cmd --list-all检查规则是否阻止了连接。网络连通性ping [目标IP] # 测试基础连通性 traceroute [目标IP] # 追踪路由路径 telnet [目标IP] [端口] # 测试TCP端口是否开放 nc -zv [目标IP] [端口] # 另一种测试端口的方法DNS解析nslookup [域名]或dig [域名]检查域名解析是否正确。应用层连接使用tcpdump抓包分析。# 抓取指定网卡、端口和主机的包写入文件 tcpdump -i eth0 -w /tmp/net.pcap host [目标IP] and port [目标端口] # 用wireshark或tcpdump本身分析文件 tcpdump -r /tmp/net.pcap -A -n常见原因防火墙规则、DNS故障、网络抖动、对端服务未启动或崩溃、连接数耗尽检查net.core.somaxconn、应用连接池配置。4. 运维提效脚本化与自动化高效的运维工程师不是“救火队员”而是“消防系统设计师”。将重复的排查动作脚本化、自动化能极大提升日常工作效率和故障响应速度。4.1 编写实用的Shell排查脚本将常用的排查命令组合成脚本一键执行。示例1系统健康检查脚本 (health_check.sh)#!/bin/bash # 系统健康检查脚本 echo 系统基础信息 hostname cat /etc/redhat-release 2/dev/null || cat /etc/os-release | grep PRETTY_NAME uptime echo -e \n CPU与负载 top -bn1 | grep Cpu(s) echo 最近1/5/15分钟平均负载: cat /proc/loadavg echo -e \n 内存使用 free -h echo -e \n 磁盘空间 df -hT | grep -v tmpfs echo -e \n 磁盘Inode df -i echo -e \n 网络连接统计 ss -s echo -e \n 前10个CPU占用进程 ps aux --sort-%cpu | head -11 echo -e \n 前10个内存占用进程 ps aux --sort-%mem | head -11 echo -e \n 检查关键服务状态 services(nginx mysql docker redis) for svc in ${services[]}; do if systemctl is-active --quiet $svc 2/dev/null; then echo $svc: Running else echo $svc: Not Running or Not Found fi done示例2查找并清理指定天数前的日志文件 (clean_old_logs.sh)#!/bin/bash # 清理旧日志脚本谨慎使用建议先在测试环境验证 LOG_DIR/var/log/myapp DAYS_TO_KEEP30 if [ ! -d $LOG_DIR ]; then echo 日志目录 $LOG_DIR 不存在. exit 1 fi echo 查找 $DAYS_TO_KEEP 天前的日志文件... find $LOG_DIR -name *.log -type f -mtime $DAYS_TO_KEEP -print # 确认后删除取消下面一行的注释以实际执行删除 # find $LOG_DIR -name *.log -type f -mtime $DAYS_TO_KEEP -exec rm -f {} \; echo 查找并清理空目录... find $LOG_DIR -type d -empty -delete4.2 利用Alias和函数提升命令行效率将长命令定义为简短的别名或函数添加到~/.bashrc中。# 常用别名 alias llls -alhF alias grepgrep --colorauto alias dfdf -h alias dudu -h # 自定义函数根据端口号查找进程 findport() { lsof -i :$1 } # 使用 findport 8080 # 自定义函数快速查看指定进程的线程数 pst() { local pid$1 if [ -z $pid ]; then echo Usage: pst PID return 1 fi ps -T -p $pid | wc -l # 或者 ls /proc/$pid/task/ | wc -l } # 使用 pst 12344.3 日志分析与监控告警集成集中式日志使用ELKElasticsearch, Logstash, Kibana或LokiGrafana收集所有服务器日志便于跨主机搜索和关联分析。指标监控使用Prometheus收集系统及应用指标用Grafana绘制仪表盘。为关键指标如CPU80%持续5分钟、内存可用10%、服务HTTP 5xx错误率1%设置告警规则通过钉钉、企业微信、邮件等渠道通知。APM工具使用SkyWalking、Pinpoint等应用性能监控工具可以追踪分布式请求链路自动定位慢调用和异常将故障定位从系统层深入到代码层。5. 常见问题排查清单Checklist将经验固化为清单在紧急情况下可以按图索骥避免遗漏。5.1 服务无法启动[ ]检查启动命令和参数是否拼写错误路径是否正确[ ]检查端口占用ss -tulnp | grep :端口端口是否已被其他进程占用[ ]检查依赖服务数据库、缓存、配置中心等是否可达[ ]检查配置文件语法是否正确nginx -t,java -jar app.jar --check-config。[ ]检查文件权限执行用户是否有权读取配置文件、写入日志目录[ ]检查日志输出启动时控制台或日志文件中的具体错误信息是什么[ ]检查资源限制是否达到系统最大文件打开数(ulimit -n)、最大进程数限制5.2 服务运行中突然崩溃[ ]检查系统日志journalctl -xe或/var/log/messages是否有OOM Killer记录(killed process)或段错误(segfault)[ ]检查应用日志崩溃前是否有大量错误、异常堆栈[ ]检查资源使用崩溃前是否内存、CPU、磁盘空间达到极限[ ]检查外部依赖是否因数据库连接中断、网络分区导致[ ]检查核心转储是否生成了core dump文件使用gdb分析。5.3 网络访问超时或缓慢[ ]客户端测试从不同网络环境机房内、外网访问问题是否一致[ ]DNS解析dig域名解析是否慢或不正确[ ]网络链路mtr报告是否有高延迟或丢包节点[ ]服务端负载服务器CPU、内存、网络带宽是否饱和[ ]应用性能数据库查询是否慢缓存是否命中代码是否存在性能瓶颈使用slow log、APM工具分析。[ ]安全组件防火墙、WAF、负载均衡器策略是否导致延迟6. 运维工程师的日常提效习惯与最佳实践6.1 文档与知识沉淀运维手册为每个维护的系统编写手册包含架构图、部署步骤、启停命令、配置文件路径、监控指标、常见故障处理流程。事后复盘文档每次故障后强制要求撰写复盘报告并归档到团队知识库如Confluence。定期回顾将共性问题转化为监控项或自动化脚本。命令手册将自己常用的、复杂的命令及解释记录下来形成个人或团队的“命令词典”。6.2 标准化与自动化环境标准化使用Docker、Kubernetes或配置管理工具Ansible, SaltStack统一环境减少因环境差异导致的问题。部署自动化通过CI/CD流水线实现一键部署、回滚减少人为失误。巡检自动化将health_check.sh这样的脚本通过定时任务cron或监控系统定期执行并将结果报告或告警。6.3 容量规划与性能基线建立性能基线在系统健康时记录关键指标CPU idle, 内存使用率, 平均响应时间, QPS的正常范围。当指标偏离基线时即使未触发告警也应引起关注。定期容量评估根据业务增长趋势定期评估数据库容量、服务器负载、带宽使用等提前规划扩容避免因资源耗尽导致故障。6.4 安全与权限管理最小权限原则为运维账号、应用账号分配刚好够用的权限避免使用root进行日常操作。操作审计启用auditd或使用堡垒机记录所有高危操作如rm,chmod, 文件修改。密钥管理使用Vault等工具管理密码、API密钥禁止在代码或配置文件中硬编码。故障排查能力的提升是一个从“点”具体命令到“线”排查流程再到“面”系统观、架构观的积累过程。它没有终极捷径依赖于对系统原理的深刻理解、对业务架构的熟悉、以及大量实践经验的总结。建议你从今天起在每次处理问题后都花几分钟回顾一下这次排查走了哪些弯路哪个命令最关键下次如何能更快将这些思考融入你的脚本、清单和文档中。久而久之你面对再复杂的故障也能胸有成竹快速拆解从一名被故障追逐的“救火员”成长为能预见并防范风险的“系统守护者”。