1. 当CPU满载时，我们首先应该观察什么

服务器突然变得卡顿，终端响应迟缓，top命令显示CPU使用率持续保持在100%——这是每个Linux运维人员都经历过的噩梦场景。面对这种情况，我们需要像老中医一样"望闻问切"，系统性地排查问题根源。

首先打开终端，执行top命令。这个经典的性能监控工具会实时显示系统资源使用情况。在top界面中，重点关注以下几列数据：

• %CPU：进程的CPU占用百分比
• COMMAND：进程名称
• USER：进程所有者
• PID：进程ID
• TIME+：进程累计占用CPU时间

按下Shift+P可以按CPU使用率排序，通常排在第一位的进程就是罪魁祸首。但这里有个常见误区：高CPU占用的进程可能只是表象，而非根本原因。比如一个Java应用CPU飙高，可能是其依赖的数据库服务出现了问题。

经验之谈：在top界面按下数字1，可以显示所有CPU核心的单独使用情况。多核服务器上，单核满载而其他核心空闲的情况很常见，这能帮助我们缩小排查范围。

2. 深入分析问题进程的三种武器

2.1 使用strace追踪系统调用

找到可疑进程后，strace工具能帮助我们观察进程正在执行的系统调用。例如对一个PID为1234的进程：

strace -p 1234 -T -tt -o /tmp/strace.log

这个命令会：

• -p 1234：附加到指定PID的进程
• -T：显示每次调用的耗时
• -tt：显示精确到微秒的时间戳
• -o：将输出保存到文件

分析strace输出时，特别关注频繁出现的调用类型。比如大量执行stat调用可能说明程序在疯狂查找某个不存在的文件；过多的epoll_wait可能表明程序在空转等待。

2.2 用perf进行性能剖析

perf是Linux内核自带的性能分析工具，可以生成火焰图直观展示CPU时间消耗在哪里：

perf record -F 99 -p 1234 -g -- sleep 30 perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > flame.svg

生成的火焰图中，横向表示耗时比例，纵向表示调用栈。宽大的"火苗"就是需要优化的热点函数。

2.3 查看进程状态和线程情况

有时候问题出在进程的某个线程上。使用以下命令查看线程详情：

top -H -p 1234 # 查看指定进程的线程情况 ps -T -p 1234 # 另一种查看线程的方式 pstree -p 1234 # 以树状显示进程和线程

Java应用特别需要注意线程堆栈分析：

jstack 1234 > thread_dump.log

3. 常见CPU满载场景与解决方案

3.1 无限循环或死循环

程序逻辑错误导致的死循环是最常见的CPU满载原因。表现为单个进程持续占用一个或多个核心的100%算力。通过strace可以看到进程在重复执行相同的代码路径。

解决方案：

1. 如果是自研应用，检查最近更新的代码，特别是循环逻辑
2. 第三方应用则考虑回滚到稳定版本
3. 临时可通过renice调整进程优先级：renice +19 -p 1234

3.2 锁竞争或资源等待

多个进程/线程争夺同一资源导致的等待，虽然看起来CPU使用率高，但实际工作效率低下。这种情况下的特点是：

• 系统负载高但吞吐量低
• 上下文切换频繁（通过vmstat或sar查看）
• 可能有大量进程处于D状态（不可中断睡眠）

解决方案：

1. 使用ipcs检查System V IPC资源使用情况
2. 通过lsof查看进程打开的文件和套接字
3. 考虑重构应用逻辑，减少锁粒度或使用无锁数据结构

3.3 外部依赖故障

我曾遇到一个案例：一个微服务CPU持续满载，最终发现是其依赖的Redis服务响应变慢，导致客户端不断重试。这类问题的特点是：

• 应用本身逻辑没问题
• 网络或外部服务响应时间变长
• 应用日志中可见大量超时错误

排查方法：

1. 检查应用日志中的错误信息
2. 使用tcpdump或wireshark分析网络流量
3. 测试依赖服务的响应时间

4. 系统级排查与优化

4.1 内核参数调优

某些情况下，默认的内核参数可能导致CPU使用效率低下。需要关注的参数包括：

sysctl -a | grep sched

常见优化点：

• kernel.sched_migration_cost_ns：任务迁移成本估值
• kernel.sched_min_granularity_ns：最小调度时间片
• vm.dirty_ratio：脏页写回阈值

重要提示：修改内核参数前务必做好备份，并在测试环境验证效果。不当的参数调整可能导致系统不稳定。

4.2 中断与软中断分析

高网络负载的服务器上，网卡中断可能消耗大量CPU资源。使用以下命令查看中断分布：

cat /proc/interrupts watch -n 1 'cat /proc/softirqs'

优化方案：

1. 启用RSS（接收端缩放）分散中断到多个CPU
2. 考虑使用RPS/RFS进一步优化
3. 对于高性能场景，可使用DPDK或XDP绕过内核网络栈

4.3 调度器与CPU亲和性

对于多核服务器，合理设置进程的CPU亲和性可以提升缓存命中率：

taskset -pc 0,2,4 1234 # 将进程绑定到0,2,4号CPU

对于NUMA架构的服务器，还需要考虑内存本地性：

numactl --hardware # 查看NUMA拓扑 numactl --cpunodebind=0 --membind=0 command # 绑定CPU和内存节点

5. 长效监控与预防措施

5.1 建立性能基线

使用sar工具收集系统历史数据：

# 安装sysstat sudo apt install sysstat # 启用数据收集 sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat systemctl enable sysstat systemctl start sysstat

收集的数据可以在/var/log/sysstat/中找到，使用以下命令查看：

sar -u 1 3 # CPU使用率 sar -q 1 3 # 负载队列 sar -w 1 3 # 进程创建/上下文切换

5.2 设置告警阈值

使用Prometheus+Grafana等监控方案，对关键指标设置告警：

• CPU使用率持续5分钟>90%
• 系统负载超过CPU核心数的2倍
• 就绪队列长度持续增长

示例PromQL查询：

100 - (avg by(instance)(irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90

5.3 定期性能测试

对于关键业务系统，建议：

1. 每季度进行一次压力测试
2. 记录性能指标变化趋势
3. 建立性能回归测试流程

可以使用工具如：

• stress-ng：模拟各种压力场景
• sysbench：综合性能测试
• JMeter：Web应用压力测试

6. 实战案例：一个真实CPU满载问题的排查过程

去年我们遇到一个线上问题：每天凌晨3点左右，某台服务器CPU使用率会突然飙升到100%，持续约15分钟后恢复正常。经过系统排查，最终发现是一个定时执行的日志分析脚本存在设计缺陷。

排查步骤：

1. 首先检查crontab，发现3:00有一个自定义脚本运行：

cat /etc/crontab ls -la /etc/cron.d/

2. 使用auditd追踪脚本执行：

auditctl -a exit,always -F arch=b64 -S execve ausearch -ts recent -sc execve

3. 发现脚本在处理一个每日增长的日志文件时，使用了O(n^2)复杂度的算法，随着日志量增加，处理时间呈指数增长。

4. 优化脚本算法复杂度后，CPU使用峰值从100%降到15%左右。

这个案例告诉我们：

• 定时任务是最常见的"午夜杀手"
• 算法复杂度问题在数据量小时可能不明显
• 监控系统要能捕捉周期性的性能波动