1. 问题现象与初步判断
最近在维护服务器时，突然收到监控系统告警：某台Linux服务器的CPU使用率持续保持在100%。这种状况如果持续下去，轻则导致服务响应变慢，重则可能引发系统崩溃。作为运维人员，我们需要快速定位问题根源。
CPU满载通常表现为：
- 系统响应明显变慢，连简单的命令都要等待很久
- 通过top命令查看，CPU的us（用户空间）或sy（内核空间）指标持续高位
- 服务器负载（load average）数值远高于CPU核心数
遇到这种情况，我通常会先确认是否属于正常业务高峰。如果是突发流量导致的正常负载，可以考虑扩容；如果是异常进程占用，就需要深入排查了。
2. 基础排查工具与技巧
2.1 top命令：第一响应工具
最快捷的方式就是使用top命令：
bash复制top -c
关键观察点：
- %CPU列：查看哪些进程占用率高
- COMMAND列：查看进程名称和启动参数
- 按P键：按CPU使用率排序
- 按1键：显示每个CPU核心的详细使用情况
注意：有些异常进程会不断fork子进程来逃避监控，这时需要观察进程树的整体占用情况。
2.2 htop：增强型进程查看器
如果系统安装了htop，它能提供更直观的视图：
bash复制htop
优势在于：
- 彩色显示，不同类型资源占用一目了然
- 支持鼠标操作，方便选中进程
- 可以直接杀死进程或调整优先级
2.3 vmstat：系统整体状态监控
对于短期突发的CPU问题，可以用vmstat查看瞬时状态：
bash复制vmstat 1 5
输出示例：
code复制procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 250000 50000 800000 0 0 10 20 1000 1500 80 20 0 0 0
重点关注：
- r列：运行队列长度，如果持续大于CPU核心数说明CPU饱和
- us/sy列：用户态/内核态CPU占用比例
3. 深入分析工具链
3.1 pidstat：进程级资源监控
要分析特定进程的CPU使用详情，pidstat非常有用：
bash复制pidstat -u -p <PID> 1 5
输出示例：
code复制Linux 5.4.0-91-generic (hostname) 01/01/2023 _x86_64_ (4 CPU)
03:30:00 PM UID PID %usr %system %guest %wait %CPU CPU Command
03:30:01 PM 0 12345 85.00 15.00 0.00 0.00 100.00 2 java
这个输出清晰地显示了该Java进程几乎占满了一个CPU核心。
3.2 perf：性能分析利器
对于需要深度分析的情况，perf工具可以帮我们找到热点函数：
bash复制perf top -p <PID>
输出示例：
code复制Samples: 10K of event 'cpu-clock', Event count (approx.): 10000000
Overhead Shared Object Symbol
65.42% libc-2.31.so [.] __memmove_avx_unaligned_erms
12.33% [kernel] [k] _raw_spin_unlock_irqrestore
8.91% java [.] java.util.HashMap.putVal
这个结果显示内存拷贝操作占用了大部分CPU时间，可能是程序在频繁处理大块数据。
3.3 strace：系统调用追踪
当怀疑是系统调用导致的问题时，strace可以捕获所有系统调用：
bash复制strace -p <PID> -c
执行一段时间后按Ctrl+C，会输出统计信息：
code复制% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
75.23 5.123456 512 10000 futex
12.45 0.847563 84 10000 poll
8.12 0.552871 55 10000 read
这个例子中，futex调用占用了大部分时间，可能说明程序存在锁竞争问题。
4. 常见问题场景与解决方案
4.1 Java应用CPU飙高
Java应用是CPU问题的重灾区，排查步骤：
- 用top找到Java进程PID
- 获取线程栈信息：
bash复制
jstack <PID> > thread_dump.log - 将top中的高CPU线程ID（十进制）转换为十六进制：
bash复制printf "%x\n" <线程ID> - 在thread_dump.log中搜索对应的nid值
常见原因：
- 死循环
- 锁竞争
- GC频繁（配合jstat -gcutil查看）
4.2 内核态CPU占用高
当sy值过高时，可能是内核问题：
- 用perf查看内核调用：
bash复制
perf top -g -e cycles:k - 检查系统调用：
bash复制perf stat -e 'syscalls:sys_enter_*' -a sleep 5
常见原因：
- 频繁的上下文切换（检查cs值）
- 过多的系统调用（如小文件IO）
- 内核模块bug
4.3 僵尸进程累积
虽然僵尸进程本身不消耗CPU，但大量僵尸进程可能是问题的征兆：
bash复制ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'
处理方法：
- 找到父进程ID
- 重启或正确处理父进程
5. 自动化监控与预防
5.1 使用sar记录历史数据
安装sysstat包后，sar会自动记录系统指标：
bash复制sar -u 1 5 # 查看CPU历史
sar -q # 查看负载历史
这些数据对于事后分析非常有用。
5.2 编写排查脚本
我通常会准备一个排查脚本，一键收集关键信息：
bash复制#!/bin/bash
DATE=$(date +%Y%m%d-%H%M%S)
DIR="cpu_analysis_$DATE"
mkdir $DIR
# 基础信息
top -b -n 1 > $DIR/top.out
ps -aux > $DIR/ps.out
vmstat 1 5 > $DIR/vmstat.out
# 按CPU排序的进程
ps -eo pcpu,pid,user,args --sort=-pcpu | head -20 > $DIR/ps_cpu.out
echo "诊断数据已保存到 $DIR 目录"
5.3 配置告警规则
在监控系统中设置合理的告警阈值：
- CPU使用率 > 90% 持续5分钟
- 负载 > CPU核心数*2
- 运行队列长度 > CPU核心数*3
6. 实战案例分享
最近遇到一个典型案例：某台服务器CPU持续100%，但top显示没有单个进程占用很高。通过以下步骤解决了问题：
-
用pidstat发现有很多低CPU进程：
bash复制
pidstat -u 1 5输出显示数百个进程每个占用0.5%-2%CPU
-
检查进程关系：
bash复制
pstree -p发现都是同一个父进程fork出来的
-
用strace跟踪父进程：
bash复制
strace -ff -p <PPID>发现它在循环创建子进程处理任务，但没有正确控制并发数
-
联系开发团队修复了并发控制逻辑
这个案例告诉我们，当CPU满载但没有单一高负载进程时，要检查是否有大量小进程累积占用资源。
7. 性能优化建议
7.1 代码层面优化
- 避免在循环中做重复计算
- 使用更高效的数据结构和算法
- 减少锁竞争（使用读写锁、减小锁粒度）
- 批量处理代替频繁小操作
7.2 系统配置调优
- 调整进程优先级：
bash复制
renice -n 10 -p <PID> - 限制进程CPU使用：
bash复制
cpulimit -p <PID> -l 50 - 使用cgroups限制资源：
bash复制cgcreate -g cpu:/app_group cgset -r cpu.cfs_quota_us=50000 app_group # 限制50%CPU cgexec -g cpu:app_group <command>
7.3 架构层面改进
- 引入队列缓冲突发请求
- 将CPU密集型任务异步化
- 考虑水平扩展分担负载
- 使用缓存减少重复计算
在实际运维工作中，CPU满载问题千变万化，但掌握了这些工具和方法论，就能快速定位和解决问题。最重要的是建立系统化的排查思路，而不是盲目尝试。每次解决完问题后，建议记录详细的排查过程和解决方案，形成知识库，这对团队成长非常有帮助。