★ FEATURED ARTICLE 1. 从一次线上告警说起CPU性能优化到底在优化什么凌晨两点被电话叫醒监控面板上一台核心业务服务器的CPU使用率飙到了98%接口响应时间从平均80毫秒涨到3秒以上上游调用方已经开始大面积超时。登录机器一看top显示%sy系统态CPU占了将近70%%us反而不高。这个现象很典型——瓶颈不在业务代码本身而在内核态的系统调用上。后来排查发现是一个日志组件在高并发下疯狂调用write()每次只写几十字节导致上下文切换和系统调用开销把CPU吃光了。这个案例我后来在团队内部分享过很多次因为它说明了一个核心问题CPU性能优化不是简单地让CPU使用率降下来而是要让CPU把时间花在真正产生业务价值的地方。使用率低不代表没问题使用率高也不代表一定有瓶颈关键要看CPU的时间到底花在了哪里、花得值不值。这篇内容是我在Linux性能优化系列里关于CPU部分的第三篇前两篇分别聊了CPU的基础指标和上下文切换这一篇重点落在实战排查方法论上当你面对一台CPU异常的机器时应该按什么顺序、用什么工具、看哪些指标一步步把问题定位到具体的函数行号。适合有一定Linux基础、正在做后端服务或中间件运维的读者也适合那些知道top命令但看不懂输出的同学。整篇内容会围绕四个部分展开先讲清楚CPU性能分析的整体思路和工具选型逻辑再拆解核心指标的判读方法然后给出一套完整的实战排查流程最后整理我这些年踩过的坑和常见问题的速查方案。全程用真实场景驱动不堆砌理论。2. 分析思路与工具选型为什么不能一上来就用perf2.1 CPU性能分析的漏斗模型很多人一遇到CPU问题就直接上perf top结果面对满屏的内核符号一脸茫然。我的经验是CPU排查应该遵循一个从粗到细的漏斗模型每一层用不同的工具逐步缩小范围。第一层是全局概览回答CPU到底忙不忙、忙在哪个维度。这一层用top、uptime、vmstat就够了。uptime看平均负载趋势vmstat看us/sy/id/wa的分布top看具体进程排名。这一层不需要精确只需要判断方向是用户态忙、系统态忙、还是IO等待高。第二层是进程级定位回答是哪个进程/线程在消耗CPU。用top -H看线程级排名用pidstat看进程的细分指标。这一层要特别注意区分是单线程打满还是多线程均匀消耗两者的根因完全不同。第三层是函数级剖析回答具体是哪段代码/哪个系统调用。这时候才轮到perf、strace、火焰图这些工具上场。如果跳过前两层直接到这一层就像不知道哪个房间着火就去拆整栋楼的水管。第四层是代码级优化根据前三层的结论决定是改算法、改架构、还是调内核参数。提示漏斗模型的核心价值在于每一层都排除掉大量可能性。我见过太多人卡在第三层用perf抓了一堆数据却不知道要证明什么就是因为前两层没做扎实。2.2 工具选型的三个判断维度Linux下CPU分析工具几十个选哪个不是看哪个高级而是看三个维度开销、精度、可解释性。top和vmstat开销极低可以常驻监控但精度只到进程级且采样间隔粗。pidstat精度到线程级开销也不大适合做二次定位。perf精度到函数级甚至指令级但采样本身有开销在高负载机器上要谨慎使用采样频率建议从99Hz起步而不是默认的4000Hz。strace能看到每一次系统调用但开销巨大只适合短时间抓取生产环境用之前一定要评估。工具分析层级开销适用场景主要局限top/uptime全局极低快速判断方向精度粗无历史vmstat全局极低看CPU时间分布无进程维度pidstat进程/线程低定位具体线程无函数信息perf函数/指令中找热点函数符号解析需配置strace系统调用高排查syscall异常严重拖慢进程火焰图函数调用栈中可视化热点需perf数据支撑选型的逻辑是先用低开销工具缩小范围再用高精度工具确认结论。反过来做要么被海量数据淹没要么把生产环境拖垮。2.3 一个容易被忽略的前置问题基线所有性能分析的前提是你知道正常是什么样。如果平时没有采集基线数据出问题时你连这个值算不算高都判断不了。我的做法是在每台核心服务器上跑一个轻量的采集脚本每分钟记录一次vmstat、pidstat的关键字段存到本地时序库。这样出问题时可以直接对比昨天同一时段的数据快速判断是突变还是渐变。基线采集不需要多复杂一个cron任务加几行shell就够。关键是持续和低开销。我见过团队花大力气搭了完整的监控体系结果采样间隔设成1秒采集本身就成了CPU消耗大户这就本末倒置了。3. 核心指标深度拆解us、sy、wa、hi、si到底在说什么3.1 用户态与系统态的黄金比例top输出里的%us和%sy是最常被误读的两个指标。简单说%us是CPU执行用户空间代码的时间占比%sy是执行内核空间代码的时间占比。但多少算正常没有绝对标准要看业务类型。对于一个计算密集型服务比如图像处理、加解密%us高到80%以上是正常的说明CPU在干正事。对于一个IO密集型服务比如网关、代理%sy偏高反而更常见因为大量时间花在网络协议栈和系统调用上。我的经验阈值是%sy持续超过30%就值得警惕超过50%基本可以确定有系统调用层面的问题。%sy高的常见原因有几个频繁的系统调用比如小包读写、上下文切换过多、锁竞争导致的内核态自旋、以及某些内核子系统的bug。区分方法是结合vmstat的cs上下文切换次数和in中断次数一起看。如果cs也高多半是切换问题如果cs正常但%sy高可能是单次系统调用本身耗时长。3.2 那个最容易被忽视的wa指标%wa是IO等待时间。严格来说wa高的时候CPU本身是空闲的它在等磁盘或网络。但很多人看到wa高就以为是磁盘问题其实不一定。wa的本质是进程发起了IO请求后进入不可中断睡眠D状态CPU在此期间无事可做。所以wa高可能来自磁盘慢也可能来自网络文件系统卡顿甚至来自某些驱动的问题。判断方法是看iostat的%util和await如果磁盘%util接近100%且await很高那是真磁盘瓶颈如果磁盘指标正常但wa高就要怀疑是不是NFS、分布式存储或者某个块设备驱动的问题。还有一个坑wa高不一定是坏事。如果业务本身就是IO密集型的wa高说明CPU没有浪费在无谓的自旋上反而是健康的。真正要警惕的是wa高同时us也高那说明CPU既要处理计算又要等IO系统已经过载了。3.3 硬中断与软中断网络服务的隐形杀手%hi是硬中断时间%si是软中断时间。这两个指标在普通业务服务器上通常很低但在网络服务、尤其是高PPS每秒包数的场景下会显著升高。硬中断是网卡收到包后直接打断CPU通知内核有数据来了。软中断是内核在稍后处理的延迟工作比如网络协议栈的解析。当PPS很高时软中断会消耗大量CPU表现为%si升高。这时候top里可能看不到明显的进程占用因为软中断是内核线程ksoftirqd在处理而ksoftirqd的CPU占用往往被算在%si里而不是进程列表里。排查软中断问题的关键是看/proc/softirqs重点关注NET_RX这一列的增速。如果NET_RX增长极快说明网络收包压力大。解决方案包括开启网卡多队列RSS、调整软中断的CPU亲和性、使用RPS/RFS把软中断分散到多个核上。这些配置我在后面实战部分会给出具体命令。注意软中断优化有个反直觉的点——不是核越多越好。如果业务本身是单线程的把软中断分散到多个核反而增加了缓存失效的开销。要根据业务模型来定。3.4 平均负载的真相它不只是CPU指标uptime里的load average是很多人第一个看的指标但它其实不是纯CPU指标。Linux的负载计算包含了运行态R和不可中断睡眠态D的进程数。所以load高可能是CPU忙也可能是IO卡。判断方法是结合vmstat的r列运行队列长度和b列阻塞进程数。如果r高而b低是CPU瓶颈如果b高是IO瓶颈。另外要注意load的趋势比绝对值更重要从0.5涨到2.0比一直稳定在4.0更值得警惕因为前者说明系统状态在恶化。还有一个经典误区load高不等于性能差。如果一台机器有32个核load是16那其实还有一半余量。判断标准应该是load / 核数这个比值超过1才说明有排队超过2说明排队严重。4. 实战排查全流程从告警到定位根因4.1 第一步用vmstat建立全局视图拿到一台CPU异常的机器我第一件事是跑vmstat 1 10连续看10秒的数据。这个命令开销极低能快速建立全局印象。vmstat 1 10重点看几列r运行队列、us、sy、id、wa、cs、in。假设输出是这样的procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 12 0 0 800000 50000 2000000 0 0 0 100 5000 8000 45 50 5 0 0这里r12说明有12个进程在排队等CPUus45、sy50说明系统态消耗比用户态还高cs8000说明上下文切换频繁。初步判断系统调用或上下文切换是主要矛盾。如果r不高但wa很高方向就要转向IO。如果r高、us高、sy低那就是纯计算瓶颈方向是优化算法或加机器。4.2 第二步用top -H锁定具体线程确定方向后用top -H -p pid看具体进程的线程级消耗。假设我们怀疑是某个Java服务先找到它的PID然后top -H -p 12345输出里会列出该进程下所有线程的CPU占用。找到占用最高的线程记下它的TID线程ID。对于Java应用把TID转成16进制再用jstack去线程栈里找对应的nid就能定位到具体是哪段代码。printf %x\n 12346 # 假设输出 303a jstack 12345 | grep -A 30 nid0x303a这一步的关键是不要只看单个线程。如果发现是多个线程均匀消耗CPU那可能是锁竞争或者GC问题如果是单线程打满那多半是某段循环或算法问题。两种情况的处理思路完全不同。4.3 第三步用perf找热点函数线程级定位后如果还是看不出具体原因比如线程栈显示在某个native方法里就该perf上场了。我通常用perf top先看实时热点perf top -p 12345 -g-g开启调用栈能看到函数的调用关系。如果perf top的实时输出滚动太快看不清可以采样一段时间生成报告perf record -F 99 -p 12345 -g -- sleep 30 perf report-F 99表示采样频率99Hz这个值是有讲究的。默认的4000Hz在高负载机器上会引入明显开销而99Hz既能保证统计显著性又几乎不影响业务。-- sleep 30表示采样30秒后自动停止。perf report里会按CPU占用排序显示函数展开可以看到调用链。找到占用最高的函数后结合源码分析是算法问题、锁问题还是系统调用问题。4.4 第四步生成火焰图做可视化perf report是文本界面看调用关系不够直观。我习惯把perf数据转成火焰图一眼就能看出热点在哪。# 采集数据 perf record -F 99 -p 12345 -g -- sleep 30 # 导出 perf script out.perf # 用火焰图工具生成SVG ./stackcollapse-perf.pl out.perf out.folded ./flamegraph.pl out.folded cpu-flame.svg火焰图的读法横轴是CPU占用比例纵轴是调用栈深度。最宽的方块就是最耗CPU的函数。如果某个方块的宽度异常大且位于调用栈底部说明是底层函数的问题如果位于顶部说明是业务代码本身的问题。我踩过的一个坑是火焰图里看到大量__libc_write以为是日志问题结果深入看调用栈发现是某个监控SDK在每次请求里都写一次本地文件。这种问题光看top是永远发现不了的。4.5 第五步strace确认系统调用异常如果perf显示热点在内核态或者怀疑是系统调用问题用strace做最后确认。但生产环境用strace一定要加限制# 只统计系统调用耗时不打印每次调用 strace -c -p 12345 # 只跟踪特定系统调用且限制输出 strace -e tracewrite,read -p 12345 -o /tmp/strace.logstrace -c会统计每个系统调用的次数和耗时非常适合快速判断。如果发现某个系统调用次数异常多比如每秒几万次write基本就能确定问题所在。注意strace会显著拖慢目标进程在高并发服务上可能导致请求堆积。我的做法是先在低峰期做或者用-f跟踪子进程时格外小心。如果实在不能停服务可以用perf trace替代开销小很多。5. 常见问题与排查技巧实录5.1 CPU使用率高但找不到占用进程这种情况我遇到过几次top显示CPU很忙但进程列表里所有进程的CPU加起来远不到总使用率。原因通常是内核线程消耗或者中断消耗。排查方法是看top的%sy和%si。如果%si高是软中断如果%sy高但进程列表里没有对应消耗可能是内核线程比如kswapd、kworker在干活。用ps -eLf可以看到所有内核线程或者直接看/proc/pid/stat。还有一种可能是容器环境下的统计偏差。在容器里top看到的CPU使用率是宿主机视角的容器内的进程列表不完整。这时候要用cgroup的cpuacct来确认。5.2 上下文切换次数异常高vmstat的cs列如果持续超过每秒10万次就值得关注了。上下文切换分两种自愿切换进程主动让出CPU比如等IO和非自愿切换被强制剥夺CPU说明有竞争。用pidstat -w可以看到每个进程的自愿和非自愿切换次数pidstat -w -p 12345 1 5如果非自愿切换cswch/s里的nvcswch/s很高说明CPU竞争激烈可能是线程数过多或者锁粒度过大。如果自愿切换高说明IO等待多要去看IO。我处理过的一个案例是一个服务开了200个工作线程但机器只有8个核导致大量非自愿切换。把线程数降到32后CPU使用率反而下降了吞吐量还提升了。线程数不是越多越好超过核数太多只会增加切换开销。5.3 单核打满但整体使用率不高这是典型的单线程瓶颈。top里整体CPU可能只有15%但某个核是100%。用top然后按1可以展开看每个核的使用率。原因通常是某个关键路径是单线程的比如一个全局锁、一个单线程的队列消费者或者中断都集中在某一个核上。解决方案包括把单线程逻辑改成多线程、用分片锁替代全局锁、调整中断亲和性把中断分散开。调整中断亲和性的命令# 查看网卡中断分布 cat /proc/interrupts | grep eth0 # 把中断绑定到指定核假设中断号是100绑到核2和核3 echo 0c /proc/irq/100/smp_affinity0c是十六进制表示二进制1100即第2和第3个核。5.4 常见问题速查表现象可能原因排查工具解决方向%sy持续50%系统调用频繁strace -c减少syscall批量处理%si高网络软中断/proc/softirqsRSS/RPS调优cs异常高线程过多/锁竞争pidstat -w减少线程优化锁单核打满单线程瓶颈top按1多线程化分片wa高但磁盘正常网络存储/驱动iostat检查存储链路load高但CPU空闲IO阻塞vmstat的b列排查D状态进程找不到占用进程内核线程/中断ps -eLf看内核态消耗5.5 几个我踩过的坑坑一盲目调大采样频率。有次为了抓一个偶发问题把perf采样频率调到10000Hz结果采样本身把CPU吃满了问题反而复现不出来。后来改成99Hz加长时间采样问题就抓到了。低频长采样比高频短采样更有效。坑二忽略NUMA的影响。在多路CPU的机器上如果进程和内存不在同一个NUMA节点跨节点访问会显著增加延迟。用numactl --hardware看节点分布用numastat看命中率。我优化过一个服务只是把进程绑定到内存所在的NUMA节点CPU使用率就降了15%。坑三把CPU频率调节当成万能药。cpupower frequency-set -g performance确实能让CPU跑在最高频率但在某些云环境下这个设置会被hypervisor覆盖而且会增加功耗和散热压力。先确认是不是真的频率问题再动手调。坑四忽视cgroup限制。容器环境下top看到的CPU使用率是宿主机的但容器实际被cgroup限制了cpu.cfs_quota_us。如果容器被限流即使宿主机CPU空闲容器内也会出现CPU不足。用cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us确认限制值。6. 写在最后的一点个人体会CPU性能优化这件事工具和方法论都是次要的最重要的是建立数据驱动的习惯。我见过太多人凭直觉猜问题猜对了是运气猜错了浪费大量时间。真正高效的排查永远是先测量、再假设、再验证、最后优化。另外优化之前一定要想清楚优化的目标是什么。是降低延迟、提升吞吐、还是降低资源成本这三个目标有时候是冲突的。比如为了降低延迟把线程数调大可能吞吐反而下降。明确目标之后所有的优化手段才有评判标准。最后分享一个我常用的技巧在优化前后都做一次完整的基线采集包括CPU、内存、IO、网络的全套指标。这样不仅能验证优化效果还能发现优化带来的副作用。我优化过一个服务CPU确实降了20%但内存涨了30%如果不做全面对比根本发现不了。性能优化从来不是单点问题永远要放在整个系统里看。
阅读完成 · 觉得有帮助？
