1. 项目概述当你的Linux服务器“发烧”了最近在维护几台线上服务器时又遇到了那个熟悉又让人头疼的问题监控告警突然响起CPU使用率飙到了90%以上甚至持续100%。屏幕前的你是不是也经历过这种心跳加速的时刻无论是负责运维的同事还是自己搭服务玩的后端开发者Linux下的CPU使用率过高都是一个绕不开的“经典故障”。这不仅仅是服务器“卡了”那么简单它背后可能隐藏着死循环、资源竞争、配置不当甚至是安全攻击。如果处理不及时轻则服务响应变慢用户体验下降重则可能导致整个应用雪崩数据丢失。所以掌握一套系统、高效的CPU使用率排查方法就像医生掌握听诊器一样是每个Linux使用者的基本功。网上教程很多但往往只告诉你用top命令看一眼然后kill -9结束进程这治标不治本。今天我想结合自己踩过的坑和实战经验分享一套从“现象定位”到“根因分析”的完整排查流程。我们会用到top、ps、pidstat、perf等一系列工具不仅告诉你“怎么看”更重点解释“为什么这么看”以及看到异常数据后“下一步该怎么办”。无论你是刚入行的运维新人还是遇到突发问题的开发者这篇内容都能给你提供直接可用的“急救手册”和“深度诊断方案”。2. 排查工具箱与核心思路拆解面对CPU高使用率最忌讳的就是慌乱中直接重启服务。一个科学的排查思路能帮你快速定位问题甚至发现系统的潜在优化点。整个排查流程可以概括为“由表及里层层递进”先全局观察再定位具体进程最后深入进程内部分析热点函数。2.1 核心排查逻辑从宏观到微观的四层分析法我的经验是将排查分为四个层次像剥洋葱一样逐步深入系统层整体观察首先确认CPU高是全局性的还是局部性的。是所有CPU核心都忙还是某一个特别忙用户态us和内核态sy的时间占比如何这能帮你初步判断问题是出在应用程序逻辑还是系统调用上。进程级定位找到是哪个或哪几个进程消耗了最多的CPU资源。这里不能只看瞬间值更要观察其随时间的变化趋势。线程级深入现代应用多是多线程的一个进程CPU高可能是其中某一个线程在“疯狂工作”。需要深入到线程级别找到那个“罪魁祸首”。代码级剖析定位到具体线程后最终要找到是线程中的哪段代码、哪个函数在大量消耗CPU。这是根因分析的终点可能需要用到性能剖析工具。这个流程确保了你不会在“哪个进程有问题”这种表层问题上浪费时间而是能直击问题核心。2.2 工具选型为什么是它们工欲善其事必先利其器。Linux下的性能工具多如牛毛但针对CPU排查以下几款是经过时间检验的“瑞士军刀”。选择它们不仅因为其强大更因为其普遍可用性和互补性。top/htop实时监控的入口。top是绝大多数Linux发行版自带的工具无需安装信息全面系统负载、CPU、内存、进程列表。它的优势在于实时性和交互性你可以动态排序、杀死进程。htop是它的增强版界面更友好支持鼠标操作查看线程也更方便。在排查的第一步我一定会先用它们快速把握系统全局状况。ps进程快照的专家。与top的实时动态不同ps提供的是某一时刻的进程静态快照。它的强大之处在于无比灵活的过滤和格式化输出能力。当你需要根据特定条件如特定用户、特定命令名筛选进程或者需要获取进程的详细元信息如启动时间、父进程PID时ps是不可替代的。pidstat来自sysstat套件的精准度量仪。top虽然能看进程CPU但数据是瞬时的且不够细致。pidstat可以按指定间隔如每秒采样输出进程及其线程的详细CPU使用率、内存、IO等统计信息并支持生成可读性强的报告。它是进行定量分析和趋势观察的利器尤其擅长发现间歇性飙升的问题。perfLinux内核的“官方”性能剖析器。当定位到某个高CPU进程/线程后perf可以告诉你CPU时间具体花在了哪些函数上。它可以进行采样分析生成火焰图直观展示调用栈和热点。这是进行代码级根因分析的终极工具功能非常强大但需要一定的学习成本。注意pidstat和perf通常不是默认安装的。在CentOS/RHEL上可以通过yum install sysstat perf安装在Ubuntu/Debian上使用apt install sysstat linux-tools-common linux-tools-$(uname -r)。建议在系统平稳时就安装好这些工具别等出了问题时才手忙脚乱。3. 实操演练一步步揪出CPU消耗元凶下面我们模拟一个CPU使用率突然升高的场景并用上述工具走一遍完整的排查流程。假设我们收到告警一台服务器的CPU总使用率超过了80%。3.1 第一步全局概览与初步定位首先登录服务器打开终端。第一个命令永远是top按下1数字键1这会让top显示所有CPU核心的单独使用情况而不是一个汇总的平均值。这非常关键有时总使用率不高但某个核心被100%占用同样会导致处理该核心上任务的应用卡顿。观察top输出的前几行汇总信息load average: 系统负载如果1分钟、5分钟、15分钟平均值持续高于CPU核心数说明系统长期过载。%Cpu(s)行这是重点。ususer: 用户态CPU时间。高通常意味着应用程序业务逻辑繁忙。sysystem: 内核态CPU时间。高可能意味着系统调用频繁或者有锁竞争、中断处理多。ididle: 空闲CPU时间。我们希望它越高越好。waiowait: 等待I/O的CPU时间。如果这个值很高说明CPU经常在等待磁盘或网络瓶颈可能不在CPU本身。我的经验如果us很高问题大概率出在应用代码如果sy很高可能需要检查系统调用、上下文切换或内核模块如果wa很高就该去查磁盘IO或网络了。今天我们聚焦us高的情况。接着看下面的进程列表。默认按CPU使用率降序排序。记下排在第一位的进程的PID进程ID和COMMAND命令名。假设我们发现一个叫my_app的Java进程占用了45%的CPU。3.2 第二步进程与线程的深度剖析仅凭top的一瞥还不够我们需要更精确和持续的数据。这时pidstat就派上用场了。使用以下命令以每秒1次的频率采样10次并显示进程级别的CPU使用情况pidstat -u 1 10这个命令会输出一个表格包含%usr用户态、%system内核态和%CPU总等列。观察my_app进程的%CPU是否持续高位。现在我们需要深入到该进程的内部看看是它的哪些线程在作怪。有两个方法方法一使用top的线程模式在top界面中按下H大写H可以切换到线程视图。你会发现原本的进程列表变成了线程列表。看看my_app进程下哪个线程的CPU使用率最高。记下这个线程的PID在线程视图下这个PID通常被称为LWP轻量级进程ID。方法二使用pidstat的线程模式这个方法更灵活可以输出到文件供后续分析# 查看特定进程PID为12345的线程级CPU统计每秒1次共5次 pidstat -t -p 12345 1 5-t参数表示显示线程信息。输出中TID列就是线程ID。找到那个持续消耗高CPU的TID。假设我们找到了高CPU线程的TID是12346。3.3 第三步代码级热点定位与火焰图生成找到了高CPU线程接下来就要问这个线程到底在执行什么函数这时就该perf出场了。首先我们可以用perf top做一个实时分析但这可能对系统有一些性能影响且信息滚动很快。更常用的方法是采样记录然后离线分析。1. 对特定进程进行采样# 对PID为12345的进程进行持续30秒的CPU调用栈采样记录到perf.data文件 sudo perf record -F 99 -g -p 12345 -- sleep 30-F 99: 每秒采样99次。这是一个常用值在开销和精度间取得平衡。-g: 记录调用栈call graph这对生成火焰图至关重要。-p 12345: 指定要采样的进程ID。-- sleep 30: 采样持续30秒。2. 生成并查看火焰图采样完成后需要将perf.data转换为可视化的火焰图。# 1. 用perf script将数据转换为可读格式 sudo perf script -i perf.data out.perf # 2. 使用FlameGraph工具包需提前下载生成火焰图 # 假设FlameGraph工具包解压在/home/user/FlameGraph /home/user/FlameGraph/stackcollapse-perf.pl out.perf out.folded /home/user/FlameGraph/flamegraph.pl out.folded cpu_flame.svg生成的cpu_flame.svg可以用浏览器打开。火焰图怎么看X轴表示采样到的调用栈数量总和不是时间。越宽的块表示它出现的次数越多即CPU时间占比越高。Y轴表示调用栈的深度。最底层是入口函数如main往上层层调用。关键操作在火焰图上寻找最宽的那些“平顶山”。鼠标悬停可以看到具体的函数名和采样占比。那个最宽的、顶是平的部分就是消耗CPU最多的热点函数。实操心得第一次生成火焰图可能会遇到缺少符号表的问题导致函数名显示为十六进制地址。这时需要确保被分析的程序编译时带有调试信息-g选项。对于Java程序可能需要使用perf-map-agent等工具来生成Java符号映射。虽然步骤稍复杂但一旦成功火焰图提供的洞察力是无与伦比的它能直接把你带到最耗时的代码行附近。4. 常见高CPU场景根因分析与解决策略定位到热点函数后就可以结合代码分析根因了。以下是我在实践中遇到的几种典型场景及其解决思路4.1 场景一无限循环或低效算法这是最常见的原因。比如在代码中有一个没有退出条件或退出条件很难满足的循环或者使用了时间复杂度为O(n²)的算法处理大规模数据。排查线索perf火焰图会清晰显示某个函数占用接近100%的CPU。top查看该进程发现其CPU占用稳定在高位不会大幅波动。解决思路审查热点函数对应的源代码。检查循环条件。是否在等待一个永远不会发生的事件是否边界条件处理有误分析算法逻辑。是否存在多层嵌套循环能否用更高效的数据结构如哈希表替代列表遍历或算法如排序算法优化考虑引入“让步”机制。如果是计算密集型任务在循环体内适当加入sleep(0)或调用pthread_yield()可以让出CPU给其他线程避免饿死。4.2 场景二锁竞争激烈在多线程程序中线程频繁地争抢同一把锁会导致大量线程处于“可运行”但“拿不到锁”的状态在top中体现为高CPU使用率因为线程在不断尝试获取锁属于用户态计算但实际工作进展缓慢。排查线索perf火焰图可能会显示在锁操作函数如pthread_mutex_lock或相关的等待函数上消耗了大量时间。使用pidstat -w可以查看进程的上下文切换次数锁竞争激烈时自愿上下文切换cswch/s会显著增高。解决思路缩小锁粒度将一把大锁拆分成多个小锁减少竞争范围。使用无锁数据结构对于特定场景如高性能队列可以考虑CASCompare-And-Swap等原子操作实现的无锁结构。减少锁持有时间只在对共享数据操作时才加锁尽快完成操作后释放。使用读写锁如果读多写少使用读写锁可以大幅提升并发读的性能。4.3 场景三频繁的GC垃圾回收对于Java、Go等托管语言的应用不合理的堆内存设置或存在内存泄漏会导致垃圾回收器频繁启动进行Full GC。Full GC是“Stop-The-World”的会暂停所有应用线程但GC线程本身会疯狂工作以回收内存从而表现为周期性通常是规律性的CPU使用率尖峰。排查线索CPU使用率呈锯齿状周期性飙升。配合JVM监控工具如jstat -gcutil可以清晰看到GC次数和时间暴涨。解决思路分析GC日志启用JVM的GC日志-Xlog:gc*分析每次GC的成因、耗时和回收效果。调整堆大小适当增大堆内存-Xmx可以减少GC频率。优化对象创建减少短生命周期对象的创建避免在循环中创建大量临时对象。选择合适的GC器根据应用特性如低延迟要求、高吞吐量要求选择G1、ZGC或Shenandoah等现代GC器。4.4 场景四配置错误或Bug有时一些配置错误会引发意外行为。例如日志级别配置错误在线上环境误配置为DEBUG或TRACE级别导致日志量暴增序列化和写入日志的CPU消耗激增。定时任务周期错误本应每小时执行一次的任务被错误配置为每分钟执行一次。第三方库或内核Bug这种情况相对少见但确实存在。排查线索这类问题通常有比较明确的时间点如发布后、配置修改后。结合perf火焰图看到的热点函数如日志输出类、序列化类和系统变更记录往往能快速定位。解决思路核对配置回滚变更升级存在已知问题的库或内核版本。5. 高级工具与排查技巧除了上述核心流程还有一些高级工具和技巧能在特定场景下发挥奇效。5.1 使用strace追踪系统调用如果top显示%sy系统态CPU很高怀疑是系统调用过于频繁可以使用strace。# 追踪一个正在运行的进程的系统调用 sudo strace -cp 12345 # -c 选项会在结束时统计各类系统调用的次数、时间和错误。 # -p 指定进程PID。注意事项strace会严重拖慢被追踪进程的速度因为它需要拦截每个系统调用。绝对不要在生产环境对核心服务长时间使用仅用于短期的诊断。从输出中你可以看到是否在频繁执行open、read、stat等系统调用从而判断是否是文件IO或网络IO配置问题。5.2 使用vmstat和mpstat查看系统整体状态vmstat和mpstat也是sysstat套件的一部分它们提供了另一个维度的视角。vmstat 1查看虚拟内存、进程、CPU等整体状态。关注r运行队列长度和us、sy、id、wa列。mpstat -P ALL 1查看每个CPU核心的详细使用情况。当怀疑负载不均时特别有用。5.3 编写排查脚本自动化对于需要长期监控或反复出现的问题可以编写简单的Shell脚本来自动化数据收集。#!/bin/bash # 保存高CPU进程信息的脚本 LOG_FILE/tmp/cpu_high.log while true; do # 获取CPU使用率超过50%的进程排除掉系统进程和本脚本自身 HIGH_PROC$(top -b -n1 | grep -E ^\s*[0-9] | awk $950 {print $1, $9, $12} | grep -v -E (systemd|kworker|ksoftirqd|本脚本名)) if [ -n $HIGH_PROC ]; then echo [$(date)] High CPU process detected: $LOG_FILE echo $HIGH_PROC $LOG_FILE # 可选记录该进程的线程信息和前10个线程 for PID in $(echo $HIGH_PROC | awk {print $1}); do echo Threads of PID $PID: $LOG_FILE ps -T -p $PID -o tid,pcpu,comm | sort -k2 -rn | head -10 $LOG_FILE done echo --- $LOG_FILE fi sleep 5 # 每5秒检查一次 done这个脚本会每5秒检查一次将CPU使用率超过50%的进程及其线程信息记录到日志中。你可以根据自己的需求调整阈值和采集的信息。6. 问题排查与避坑指南即使按照流程操作排查过程中也可能遇到各种“坑”。这里记录几个我印象深刻的教训。6.1 火焰图看不到应用层函数名这是使用perf分析Java等JIT语言程序时最常见的问题。perf默认只能识别原生符号JIT编译后的Java方法对它是“隐形”的。解决方案 对于Java程序需要使用perf-map-agent。它是一个Java Agent会在JVM启动时注入动态生成Java方法地址到方法名的映射文件/tmp/perf-.map。perf在生成报告时会读取这个文件从而正确显示Java方法名。下载并编译perf-map-agent。在启动Java应用时加入Agent参数-agentpath:/path/to/libperfmap.so。确保运行perf命令的用户有权限读取/tmp/perf-*.map文件。6.2pidstat显示CPU使用率超过100%在top或pidstat中你可能会看到一个进程的CPU使用率是150%甚至更高。这并非错误。原因解释这些工具显示的CPU使用率是相对于单个CPU核心的百分比。如果一个进程有多个线程在全力运行且它们被调度到了不同的CPU核心上那么该进程的总CPU使用率就可以超过100%。例如一个双线程进程每个线程都占满一个核心那么它的CPU使用率就是200%。在top中按下1看到的是每个核心的使用率而进程列表中的%CPU是所有这些核心使用率的总和。6.3 容器环境下的排查差异在Docker或Kubernetes环境中直接在宿主机上使用top或ps看到的进程信息是全局的可能难以对应到具体的容器。解决方案进入容器内部排查使用docker exec -it /bin/bash进入容器然后在容器内使用top、ps等工具。这样看到的环境是隔离的更清晰。使用容器化工具crictl用于CRI运行时或docker stats命令可以从宿主机视角查看容器的资源使用概况。关联PID在宿主机上可以通过ps -ef | grep找到容器内进程在宿主机上的真实PID然后用cat /proc//cgroup查看其Cgroup信息从而关联到容器ID。不过这种方法比较繁琐。个人建议对于容器化应用最好的实践是在构建镜像时就把sysstat、procps包含top、ps等基础工具包打进去。同时务必建立完善的应用日志和指标监控体系如Prometheus Grafana这样大部分问题可以通过监控图表发现端倪再进入容器进行细粒度排查。6.4 瞬时高峰与持续高负载的区分监控系统告警CPU高但你登录上去用top看的时候可能已经恢复了。这可能是瞬时高峰如定时任务、突发请求导致的。排查技巧查看历史数据利用sar命令也来自sysstat查看历史CPU使用率。例如sar -u 1 10可以看过去一段时间的情况但更常用的是查看系统自动收集的历史记录通常位于/var/log/sa/。配置更细粒度的监控将监控系统的采集频率从1分钟提高到15秒或30秒更容易捕捉到瞬时尖峰。分析日志结合应用日志查看CPU高峰时间点附近是否有特殊操作或大量请求涌入。CPU使用率排查是一个需要结合工具、经验和系统知识的综合性工作。没有一成不变的银弹但掌握从全局到局部、从现象到代码的这套分层分析法至少能让你在问题面前不再盲目。最重要的永远是结合业务逻辑去思考高CPU时系统在做什么是正常的业务高峰还是异常的错误循环工具给出的是数据而你的思考才能给出答案。平时多练习这些命令了解它们的输出含义等真正遇到问题时你就能像老中医一样做到“望闻问切”药到病除。 Linux服务器CPU使用率过高排查：从工具使用到根因分析实战指南
1. 项目概述当你的Linux服务器“发烧”了最近在维护几台线上服务器时又遇到了那个熟悉又让人头疼的问题监控告警突然响起CPU使用率飙到了90%以上甚至持续100%。屏幕前的你是不是也经历过这种心跳加速的时刻无论是负责运维的同事还是自己搭服务玩的后端开发者Linux下的CPU使用率过高都是一个绕不开的“经典故障”。这不仅仅是服务器“卡了”那么简单它背后可能隐藏着死循环、资源竞争、配置不当甚至是安全攻击。如果处理不及时轻则服务响应变慢用户体验下降重则可能导致整个应用雪崩数据丢失。所以掌握一套系统、高效的CPU使用率排查方法就像医生掌握听诊器一样是每个Linux使用者的基本功。网上教程很多但往往只告诉你用top命令看一眼然后kill -9结束进程这治标不治本。今天我想结合自己踩过的坑和实战经验分享一套从“现象定位”到“根因分析”的完整排查流程。我们会用到top、ps、pidstat、perf等一系列工具不仅告诉你“怎么看”更重点解释“为什么这么看”以及看到异常数据后“下一步该怎么办”。无论你是刚入行的运维新人还是遇到突发问题的开发者这篇内容都能给你提供直接可用的“急救手册”和“深度诊断方案”。2. 排查工具箱与核心思路拆解面对CPU高使用率最忌讳的就是慌乱中直接重启服务。一个科学的排查思路能帮你快速定位问题甚至发现系统的潜在优化点。整个排查流程可以概括为“由表及里层层递进”先全局观察再定位具体进程最后深入进程内部分析热点函数。2.1 核心排查逻辑从宏观到微观的四层分析法我的经验是将排查分为四个层次像剥洋葱一样逐步深入系统层整体观察首先确认CPU高是全局性的还是局部性的。是所有CPU核心都忙还是某一个特别忙用户态us和内核态sy的时间占比如何这能帮你初步判断问题是出在应用程序逻辑还是系统调用上。进程级定位找到是哪个或哪几个进程消耗了最多的CPU资源。这里不能只看瞬间值更要观察其随时间的变化趋势。线程级深入现代应用多是多线程的一个进程CPU高可能是其中某一个线程在“疯狂工作”。需要深入到线程级别找到那个“罪魁祸首”。代码级剖析定位到具体线程后最终要找到是线程中的哪段代码、哪个函数在大量消耗CPU。这是根因分析的终点可能需要用到性能剖析工具。这个流程确保了你不会在“哪个进程有问题”这种表层问题上浪费时间而是能直击问题核心。2.2 工具选型为什么是它们工欲善其事必先利其器。Linux下的性能工具多如牛毛但针对CPU排查以下几款是经过时间检验的“瑞士军刀”。选择它们不仅因为其强大更因为其普遍可用性和互补性。top/htop实时监控的入口。top是绝大多数Linux发行版自带的工具无需安装信息全面系统负载、CPU、内存、进程列表。它的优势在于实时性和交互性你可以动态排序、杀死进程。htop是它的增强版界面更友好支持鼠标操作查看线程也更方便。在排查的第一步我一定会先用它们快速把握系统全局状况。ps进程快照的专家。与top的实时动态不同ps提供的是某一时刻的进程静态快照。它的强大之处在于无比灵活的过滤和格式化输出能力。当你需要根据特定条件如特定用户、特定命令名筛选进程或者需要获取进程的详细元信息如启动时间、父进程PID时ps是不可替代的。pidstat来自sysstat套件的精准度量仪。top虽然能看进程CPU但数据是瞬时的且不够细致。pidstat可以按指定间隔如每秒采样输出进程及其线程的详细CPU使用率、内存、IO等统计信息并支持生成可读性强的报告。它是进行定量分析和趋势观察的利器尤其擅长发现间歇性飙升的问题。perfLinux内核的“官方”性能剖析器。当定位到某个高CPU进程/线程后perf可以告诉你CPU时间具体花在了哪些函数上。它可以进行采样分析生成火焰图直观展示调用栈和热点。这是进行代码级根因分析的终极工具功能非常强大但需要一定的学习成本。注意pidstat和perf通常不是默认安装的。在CentOS/RHEL上可以通过yum install sysstat perf安装在Ubuntu/Debian上使用apt install sysstat linux-tools-common linux-tools-$(uname -r)。建议在系统平稳时就安装好这些工具别等出了问题时才手忙脚乱。3. 实操演练一步步揪出CPU消耗元凶下面我们模拟一个CPU使用率突然升高的场景并用上述工具走一遍完整的排查流程。假设我们收到告警一台服务器的CPU总使用率超过了80%。3.1 第一步全局概览与初步定位首先登录服务器打开终端。第一个命令永远是top按下1数字键1这会让top显示所有CPU核心的单独使用情况而不是一个汇总的平均值。这非常关键有时总使用率不高但某个核心被100%占用同样会导致处理该核心上任务的应用卡顿。观察top输出的前几行汇总信息load average: 系统负载如果1分钟、5分钟、15分钟平均值持续高于CPU核心数说明系统长期过载。%Cpu(s)行这是重点。ususer: 用户态CPU时间。高通常意味着应用程序业务逻辑繁忙。sysystem: 内核态CPU时间。高可能意味着系统调用频繁或者有锁竞争、中断处理多。ididle: 空闲CPU时间。我们希望它越高越好。waiowait: 等待I/O的CPU时间。如果这个值很高说明CPU经常在等待磁盘或网络瓶颈可能不在CPU本身。我的经验如果us很高问题大概率出在应用代码如果sy很高可能需要检查系统调用、上下文切换或内核模块如果wa很高就该去查磁盘IO或网络了。今天我们聚焦us高的情况。接着看下面的进程列表。默认按CPU使用率降序排序。记下排在第一位的进程的PID进程ID和COMMAND命令名。假设我们发现一个叫my_app的Java进程占用了45%的CPU。3.2 第二步进程与线程的深度剖析仅凭top的一瞥还不够我们需要更精确和持续的数据。这时pidstat就派上用场了。使用以下命令以每秒1次的频率采样10次并显示进程级别的CPU使用情况pidstat -u 1 10这个命令会输出一个表格包含%usr用户态、%system内核态和%CPU总等列。观察my_app进程的%CPU是否持续高位。现在我们需要深入到该进程的内部看看是它的哪些线程在作怪。有两个方法方法一使用top的线程模式在top界面中按下H大写H可以切换到线程视图。你会发现原本的进程列表变成了线程列表。看看my_app进程下哪个线程的CPU使用率最高。记下这个线程的PID在线程视图下这个PID通常被称为LWP轻量级进程ID。方法二使用pidstat的线程模式这个方法更灵活可以输出到文件供后续分析# 查看特定进程PID为12345的线程级CPU统计每秒1次共5次 pidstat -t -p 12345 1 5-t参数表示显示线程信息。输出中TID列就是线程ID。找到那个持续消耗高CPU的TID。假设我们找到了高CPU线程的TID是12346。3.3 第三步代码级热点定位与火焰图生成找到了高CPU线程接下来就要问这个线程到底在执行什么函数这时就该perf出场了。首先我们可以用perf top做一个实时分析但这可能对系统有一些性能影响且信息滚动很快。更常用的方法是采样记录然后离线分析。1. 对特定进程进行采样# 对PID为12345的进程进行持续30秒的CPU调用栈采样记录到perf.data文件 sudo perf record -F 99 -g -p 12345 -- sleep 30-F 99: 每秒采样99次。这是一个常用值在开销和精度间取得平衡。-g: 记录调用栈call graph这对生成火焰图至关重要。-p 12345: 指定要采样的进程ID。-- sleep 30: 采样持续30秒。2. 生成并查看火焰图采样完成后需要将perf.data转换为可视化的火焰图。# 1. 用perf script将数据转换为可读格式 sudo perf script -i perf.data out.perf # 2. 使用FlameGraph工具包需提前下载生成火焰图 # 假设FlameGraph工具包解压在/home/user/FlameGraph /home/user/FlameGraph/stackcollapse-perf.pl out.perf out.folded /home/user/FlameGraph/flamegraph.pl out.folded cpu_flame.svg生成的cpu_flame.svg可以用浏览器打开。火焰图怎么看X轴表示采样到的调用栈数量总和不是时间。越宽的块表示它出现的次数越多即CPU时间占比越高。Y轴表示调用栈的深度。最底层是入口函数如main往上层层调用。关键操作在火焰图上寻找最宽的那些“平顶山”。鼠标悬停可以看到具体的函数名和采样占比。那个最宽的、顶是平的部分就是消耗CPU最多的热点函数。实操心得第一次生成火焰图可能会遇到缺少符号表的问题导致函数名显示为十六进制地址。这时需要确保被分析的程序编译时带有调试信息-g选项。对于Java程序可能需要使用perf-map-agent等工具来生成Java符号映射。虽然步骤稍复杂但一旦成功火焰图提供的洞察力是无与伦比的它能直接把你带到最耗时的代码行附近。4. 常见高CPU场景根因分析与解决策略定位到热点函数后就可以结合代码分析根因了。以下是我在实践中遇到的几种典型场景及其解决思路4.1 场景一无限循环或低效算法这是最常见的原因。比如在代码中有一个没有退出条件或退出条件很难满足的循环或者使用了时间复杂度为O(n²)的算法处理大规模数据。排查线索perf火焰图会清晰显示某个函数占用接近100%的CPU。top查看该进程发现其CPU占用稳定在高位不会大幅波动。解决思路审查热点函数对应的源代码。检查循环条件。是否在等待一个永远不会发生的事件是否边界条件处理有误分析算法逻辑。是否存在多层嵌套循环能否用更高效的数据结构如哈希表替代列表遍历或算法如排序算法优化考虑引入“让步”机制。如果是计算密集型任务在循环体内适当加入sleep(0)或调用pthread_yield()可以让出CPU给其他线程避免饿死。4.2 场景二锁竞争激烈在多线程程序中线程频繁地争抢同一把锁会导致大量线程处于“可运行”但“拿不到锁”的状态在top中体现为高CPU使用率因为线程在不断尝试获取锁属于用户态计算但实际工作进展缓慢。排查线索perf火焰图可能会显示在锁操作函数如pthread_mutex_lock或相关的等待函数上消耗了大量时间。使用pidstat -w可以查看进程的上下文切换次数锁竞争激烈时自愿上下文切换cswch/s会显著增高。解决思路缩小锁粒度将一把大锁拆分成多个小锁减少竞争范围。使用无锁数据结构对于特定场景如高性能队列可以考虑CASCompare-And-Swap等原子操作实现的无锁结构。减少锁持有时间只在对共享数据操作时才加锁尽快完成操作后释放。使用读写锁如果读多写少使用读写锁可以大幅提升并发读的性能。4.3 场景三频繁的GC垃圾回收对于Java、Go等托管语言的应用不合理的堆内存设置或存在内存泄漏会导致垃圾回收器频繁启动进行Full GC。Full GC是“Stop-The-World”的会暂停所有应用线程但GC线程本身会疯狂工作以回收内存从而表现为周期性通常是规律性的CPU使用率尖峰。排查线索CPU使用率呈锯齿状周期性飙升。配合JVM监控工具如jstat -gcutil可以清晰看到GC次数和时间暴涨。解决思路分析GC日志启用JVM的GC日志-Xlog:gc*分析每次GC的成因、耗时和回收效果。调整堆大小适当增大堆内存-Xmx可以减少GC频率。优化对象创建减少短生命周期对象的创建避免在循环中创建大量临时对象。选择合适的GC器根据应用特性如低延迟要求、高吞吐量要求选择G1、ZGC或Shenandoah等现代GC器。4.4 场景四配置错误或Bug有时一些配置错误会引发意外行为。例如日志级别配置错误在线上环境误配置为DEBUG或TRACE级别导致日志量暴增序列化和写入日志的CPU消耗激增。定时任务周期错误本应每小时执行一次的任务被错误配置为每分钟执行一次。第三方库或内核Bug这种情况相对少见但确实存在。排查线索这类问题通常有比较明确的时间点如发布后、配置修改后。结合perf火焰图看到的热点函数如日志输出类、序列化类和系统变更记录往往能快速定位。解决思路核对配置回滚变更升级存在已知问题的库或内核版本。5. 高级工具与排查技巧除了上述核心流程还有一些高级工具和技巧能在特定场景下发挥奇效。5.1 使用strace追踪系统调用如果top显示%sy系统态CPU很高怀疑是系统调用过于频繁可以使用strace。# 追踪一个正在运行的进程的系统调用 sudo strace -cp 12345 # -c 选项会在结束时统计各类系统调用的次数、时间和错误。 # -p 指定进程PID。注意事项strace会严重拖慢被追踪进程的速度因为它需要拦截每个系统调用。绝对不要在生产环境对核心服务长时间使用仅用于短期的诊断。从输出中你可以看到是否在频繁执行open、read、stat等系统调用从而判断是否是文件IO或网络IO配置问题。5.2 使用vmstat和mpstat查看系统整体状态vmstat和mpstat也是sysstat套件的一部分它们提供了另一个维度的视角。vmstat 1查看虚拟内存、进程、CPU等整体状态。关注r运行队列长度和us、sy、id、wa列。mpstat -P ALL 1查看每个CPU核心的详细使用情况。当怀疑负载不均时特别有用。5.3 编写排查脚本自动化对于需要长期监控或反复出现的问题可以编写简单的Shell脚本来自动化数据收集。#!/bin/bash # 保存高CPU进程信息的脚本 LOG_FILE/tmp/cpu_high.log while true; do # 获取CPU使用率超过50%的进程排除掉系统进程和本脚本自身 HIGH_PROC$(top -b -n1 | grep -E ^\s*[0-9] | awk $950 {print $1, $9, $12} | grep -v -E (systemd|kworker|ksoftirqd|本脚本名)) if [ -n $HIGH_PROC ]; then echo [$(date)] High CPU process detected: $LOG_FILE echo $HIGH_PROC $LOG_FILE # 可选记录该进程的线程信息和前10个线程 for PID in $(echo $HIGH_PROC | awk {print $1}); do echo Threads of PID $PID: $LOG_FILE ps -T -p $PID -o tid,pcpu,comm | sort -k2 -rn | head -10 $LOG_FILE done echo --- $LOG_FILE fi sleep 5 # 每5秒检查一次 done这个脚本会每5秒检查一次将CPU使用率超过50%的进程及其线程信息记录到日志中。你可以根据自己的需求调整阈值和采集的信息。6. 问题排查与避坑指南即使按照流程操作排查过程中也可能遇到各种“坑”。这里记录几个我印象深刻的教训。6.1 火焰图看不到应用层函数名这是使用perf分析Java等JIT语言程序时最常见的问题。perf默认只能识别原生符号JIT编译后的Java方法对它是“隐形”的。解决方案 对于Java程序需要使用perf-map-agent。它是一个Java Agent会在JVM启动时注入动态生成Java方法地址到方法名的映射文件/tmp/perf-.map。perf在生成报告时会读取这个文件从而正确显示Java方法名。下载并编译perf-map-agent。在启动Java应用时加入Agent参数-agentpath:/path/to/libperfmap.so。确保运行perf命令的用户有权限读取/tmp/perf-*.map文件。6.2pidstat显示CPU使用率超过100%在top或pidstat中你可能会看到一个进程的CPU使用率是150%甚至更高。这并非错误。原因解释这些工具显示的CPU使用率是相对于单个CPU核心的百分比。如果一个进程有多个线程在全力运行且它们被调度到了不同的CPU核心上那么该进程的总CPU使用率就可以超过100%。例如一个双线程进程每个线程都占满一个核心那么它的CPU使用率就是200%。在top中按下1看到的是每个核心的使用率而进程列表中的%CPU是所有这些核心使用率的总和。6.3 容器环境下的排查差异在Docker或Kubernetes环境中直接在宿主机上使用top或ps看到的进程信息是全局的可能难以对应到具体的容器。解决方案进入容器内部排查使用docker exec -it /bin/bash进入容器然后在容器内使用top、ps等工具。这样看到的环境是隔离的更清晰。使用容器化工具crictl用于CRI运行时或docker stats命令可以从宿主机视角查看容器的资源使用概况。关联PID在宿主机上可以通过ps -ef | grep找到容器内进程在宿主机上的真实PID然后用cat /proc//cgroup查看其Cgroup信息从而关联到容器ID。不过这种方法比较繁琐。个人建议对于容器化应用最好的实践是在构建镜像时就把sysstat、procps包含top、ps等基础工具包打进去。同时务必建立完善的应用日志和指标监控体系如Prometheus Grafana这样大部分问题可以通过监控图表发现端倪再进入容器进行细粒度排查。6.4 瞬时高峰与持续高负载的区分监控系统告警CPU高但你登录上去用top看的时候可能已经恢复了。这可能是瞬时高峰如定时任务、突发请求导致的。排查技巧查看历史数据利用sar命令也来自sysstat查看历史CPU使用率。例如sar -u 1 10可以看过去一段时间的情况但更常用的是查看系统自动收集的历史记录通常位于/var/log/sa/。配置更细粒度的监控将监控系统的采集频率从1分钟提高到15秒或30秒更容易捕捉到瞬时尖峰。分析日志结合应用日志查看CPU高峰时间点附近是否有特殊操作或大量请求涌入。CPU使用率排查是一个需要结合工具、经验和系统知识的综合性工作。没有一成不变的银弹但掌握从全局到局部、从现象到代码的这套分层分析法至少能让你在问题面前不再盲目。最重要的永远是结合业务逻辑去思考高CPU时系统在做什么是正常的业务高峰还是异常的错误循环工具给出的是数据而你的思考才能给出答案。平时多练习这些命令了解它们的输出含义等真正遇到问题时你就能像老中医一样做到“望闻问切”药到病除。