1. 当CPU满载时我们首先应该观察什么服务器突然变得卡顿终端响应迟缓top命令显示CPU使用率持续保持在100%——这是每个Linux运维人员都经历过的噩梦场景。面对这种情况我们需要像老中医一样望闻问切系统性地排查问题根源。首先打开终端执行top命令。这个经典的性能监控工具会实时显示系统资源使用情况。在top界面中重点关注以下几列数据%CPU进程的CPU占用百分比COMMAND进程名称USER进程所有者PID进程IDTIME进程累计占用CPU时间按下ShiftP可以按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.log3. 常见CPU满载场景与解决方案3.1 无限循环或死循环程序逻辑错误导致的死循环是最常见的CPU满载原因。表现为单个进程持续占用一个或多个核心的100%算力。通过strace可以看到进程在重复执行相同的代码路径。解决方案如果是自研应用检查最近更新的代码特别是循环逻辑第三方应用则考虑回滚到稳定版本临时可通过renice调整进程优先级renice 19 -p 12343.2 锁竞争或资源等待多个进程/线程争夺同一资源导致的等待虽然看起来CPU使用率高但实际工作效率低下。这种情况下的特点是系统负载高但吞吐量低上下文切换频繁通过vmstat或sar查看可能有大量进程处于D状态不可中断睡眠解决方案使用ipcs检查System V IPC资源使用情况通过lsof查看进程打开的文件和套接字考虑重构应用逻辑减少锁粒度或使用无锁数据结构3.3 外部依赖故障我曾遇到一个案例一个微服务CPU持续满载最终发现是其依赖的Redis服务响应变慢导致客户端不断重试。这类问题的特点是应用本身逻辑没问题网络或外部服务响应时间变长应用日志中可见大量超时错误排查方法检查应用日志中的错误信息使用tcpdump或wireshark分析网络流量测试依赖服务的响应时间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优化方案启用RSS接收端缩放分散中断到多个CPU考虑使用RPS/RFS进一步优化对于高性能场景可使用DPDK或XDP绕过内核网络栈4.3 调度器与CPU亲和性对于多核服务器合理设置进程的CPU亲和性可以提升缓存命中率taskset -pc 0,2,4 1234 # 将进程绑定到0,2,4号CPU对于NUMA架构的服务器还需要考虑内存本地性numactl --hardware # 查看NUMA拓扑 numactl --cpunodebind0 --membind0 command # 绑定CPU和内存节点5. 长效监控与预防措施5.1 建立性能基线使用sar工具收集系统历史数据# 安装sysstat sudo apt install sysstat # 启用数据收集 sed -i s/ENABLEDfalse/ENABLEDtrue/ /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 设置告警阈值使用PrometheusGrafana等监控方案对关键指标设置告警CPU使用率持续5分钟90%系统负载超过CPU核心数的2倍就绪队列长度持续增长示例PromQL查询100 - (avg by(instance)(irate(node_cpu_seconds_total{modeidle}[5m])) * 100) 905.3 定期性能测试对于关键业务系统建议每季度进行一次压力测试记录性能指标变化趋势建立性能回归测试流程可以使用工具如stress-ng模拟各种压力场景sysbench综合性能测试JMeterWeb应用压力测试6. 实战案例一个真实CPU满载问题的排查过程去年我们遇到一个线上问题每天凌晨3点左右某台服务器CPU使用率会突然飙升到100%持续约15分钟后恢复正常。经过系统排查最终发现是一个定时执行的日志分析脚本存在设计缺陷。排查步骤首先检查crontab发现3:00有一个自定义脚本运行cat /etc/crontab ls -la /etc/cron.d/使用auditd追踪脚本执行auditctl -a exit,always -F archb64 -S execve ausearch -ts recent -sc execve发现脚本在处理一个每日增长的日志文件时使用了O(n^2)复杂度的算法随着日志量增加处理时间呈指数增长。优化脚本算法复杂度后CPU使用峰值从100%降到15%左右。这个案例告诉我们定时任务是最常见的午夜杀手算法复杂度问题在数据量小时可能不明显监控系统要能捕捉周期性的性能波动