Linux服务器故障排查实战：CPU飙高与内存不足定位流程

服务器故障排查是Linux系统管理的日常工作。服务突然变慢、接口超时、进程被杀，背后大多是CPU或内存出了问题。排查的关键不是猜，而是按层剥：先看系统负载，再定位进程，最后落到线程与代码。用对工具，十分钟内能把问题从”服务器卡了”收敛到”某个函数在忙等”。

CPU飙高排查流程：从load average到线程栈

接到告警先执行uptime看负载，再配合top观察进程CPU占用。load average是1/5/15分钟的运行队列平均长度，单看数值没意义，要结合核数判断：四核机器load长期超过4说明任务排队。定位到高CPU进程后，用top -Hp PID找到具体线程，再把线程号换算成十六进制，用jstack或perf抓线程栈看卡点。

# 定位CPU消耗线程的完整命令链
uptime
top -b -n1 | head -20           # 找高CPU进程PID
top -Hp 12345 -b -n1 | head -30 # 找高CPU线程TID
printf '%x\n' 23456             # 线程号转十六进制
jstack 12345 | grep -A20 '0x5ba0' # 抓线程栈看卡点

拿到线程栈后按状态分类：RUNNABLE集中在业务代码一般是锁竞争或循环空转，WAITING集中在锁上说明线程在等锁，大量Blocked配合iotop输出高说明磁盘慢。物理机与云主机排查路径一致，差别只在云厂商监控面板能直接看到磁盘IOPS与网络带宽指标，少一层猜测。

内存不足排查：先看日志再定策略

内存问题分两档：OOM killer直接杀进程，还有一种缓慢增长最终把swap占满。OOM发生后先查dmesg日志，里面记录了被杀进程与内存快照；同时看应用自身的GC日志或内存监控，确认是泄漏还是流量增大。临时缓解手段是调低进程内存或重启，长期解法要回到代码层定位驻留对象。清理缓存能争取时间，但cache本来就是给磁盘IO用的，别指望清完能一劳永逸。

# 内存排查命令组合
free -h          # 总量与cache占用
cat /proc/meminfo | grep -i 'MemAvailable'
dmesg -T | grep -i 'Out of memory'   # OOM记录
ps aux --sort=-rss | head -10        # 内存占用排序
cat /proc/sys/vm/swappiness          # swap倾向性参数

高可用集群下故障排查的差异与标准化

单机排查练的是定位速度，集群排查练的是隔离与止损。多节点部署时先确认流量是否被引流到异常节点，用负载均衡的权重与健康检查摘除异常节点，再在维护窗口慢慢查根因。数据库与缓存集群注意主从切换后的延迟回放，磁盘满会直接引发只读，监控里磁盘使用率阈值建议提前到80%。

排查流程要沉淀成标准操作步骤：告警触发、信息采集、影响面评估、临时处置、根因定位、复盘。团队每次故障都补一条监控项，故障率会随轮次明显下降。记一套checklist比临时翻手册靠谱，日志里的OOM条目、硬件的风扇异响都是高频复用信号。