1. CPU性能优化到底在优化什么很多人一提到Linux性能优化脑子里第一反应就是top命令里那个飘忽不定的CPU使用率看到数字高了就紧张低了就安心。但实际情况远比这个数字复杂得多。CPU性能优化这件事本质上是在解决一个核心矛盾有限的CPU资源与无限的任务需求之间的分配问题。你手上有多少核、多少主频、多少缓存这些是硬件给定的天花板而你的应用要跑多少线程、做多少计算、等多少IO这些是软件层面的需求。优化就是让这两者尽可能匹配既不浪费硬件也不让任务排队排到天荒地老。这篇文章是CPU性能优化系列的第三篇前两篇分别聊了CPU的基础监控指标和调度器原理这一篇重点落在实战调优手段上。我会把常见的CPU瓶颈场景拆开从进程调度、中断处理、频率调节、亲和性绑定这几个维度把每个参数背后的逻辑讲清楚再配上可以直接复现的操作步骤。适合已经有一定Linux基础、能看懂top和ps输出、但面对具体性能问题不知道从哪下手的运维和开发人员。如果你刚接触Linux不久建议先把前两篇的基础概念过一遍不然直接看调优参数会有点懵。先说一个我踩过的坑。早些年接手一个日志处理服务CPU使用率常年维持在80%以上但吞吐量死活上不去。当时第一反应是加机器结果加了之后发现单机性能反而下降了。后来用perf top一看大量时间花在__schedule和finish_task_switch上也就是上下文切换开销吃掉了将近三成的CPU。这就是典型的“看起来忙实际没干正事”。所以CPU优化第一步永远不是调参数而是搞清楚CPU时间到底花在哪了。提示在动任何内核参数之前先用perf top -g或者pidstat -w 1确认瓶颈类型。盲目调参比不调更危险因为很多参数是全局生效的改错了会影响整台机器上所有服务。2. 进程调度与上下文切换的实战调优2.1 上下文切换的代价到底有多大上下文切换分两种自愿切换和非自愿切换。自愿切换是进程主动让出CPU比如等IO、等锁、调用sleep非自愿切换是时间片用完被调度器强行换下。前者通常说明任务在等资源后者说明CPU真的不够用了。用pidstat -w 1可以分别看到cswch/s和nvcswch/s两个指标。上下文切换的直接开销包括保存和恢复寄存器、刷新TLB、切换内核栈等间接开销更麻烦——缓存局部性被破坏。一个进程刚把热数据加载进L1/L2缓存被换下去之后另一个进程上来把缓存冲掉等它再回来时又得重新加载。实测下来一次上下文切换的直接开销大约在2到5微秒但如果算上缓存失效的间接影响在高频切换场景下等效开销可以到10微秒以上。假设你的服务每秒处理10万个请求每个请求触发两次上下文切换那就是20万次切换光切换开销就吃掉2秒CPU时间相当于两个核白干了。2.2 减少非必要切换的几种手段第一种手段是调整进程优先级。Linux的CFS调度器用nice值来控制权重范围从-20到19值越小优先级越高。很多人只知道nice命令但不知道renice可以在进程运行中动态调整。比如一个后台批处理任务影响了前台服务可以这样操作# 查看当前进程的nice值 ps -eo pid,ni,comm | grep batch_worker # 动态调整为低优先级 renice 10 -p pid但要注意nice只影响CFS调度类的进程。如果你的服务用的是实时调度类SCHED_FIFO或SCHED_RRnice是无效的得用chrt命令。实时进程的优先级范围是1到99数值越大优先级越高。我见过有人把日志采集进程设成SCHED_FIFO优先级99结果把整个系统卡死因为那个进程一旦跑起来就不让出CPU除非它自己阻塞。第二种手段是控制线程数量。线程不是越多越好每个线程都是一个独立的调度实体线程数超过CPU核数之后切换频率会显著上升。一个经验法则是CPU密集型任务的线程数设为核数加一IO密集型任务可以适当放大到核数的两到三倍。但这不是绝对的得看具体场景。可以用nproc查看核数用ps -eLf | wc -l看当前线程总数。第三种手段是使用CPU亲和性绑定。把关键进程绑定到固定的CPU核上可以减少它在不同核之间迁移带来的缓存失效。taskset命令可以做到# 将进程绑定到CPU 0和1 taskset -cp 0,1 pid # 启动时直接绑定 taskset -c 2,3 ./my_service绑定之后用pidstat -t -p pid 1观察可以看到进程只在指定的核上运行。但这里有个坑如果你绑定的核上还有别的重负载进程反而会加剧竞争。所以绑定之前先用mpstat -P ALL 1看看各核的负载分布。2.3 调度器参数的微调CFS调度器有几个关键参数在/proc/sys/kernel/下面。sched_min_granularity_ns控制最小调度粒度默认一般是1毫秒左右sched_wakeup_granularity_ns控制唤醒抢占的粒度。这两个值调小会让调度更精细但切换次数增加调大则相反。除非你有非常明确的场景需求否则不建议动这两个参数因为默认值是经过大量测试的平衡点。真正值得关注的是/proc/sys/kernel/sched_autogroup_enabled。这个特性会把同一会话的进程自动分组桌面环境下能提升交互体验但服务器环境下反而可能造成调度不均。很多发行版默认开启服务器上建议关掉echo 0 /proc/sys/kernel/sched_autogroup_enabled注意这个修改是临时的重启后失效。要持久化需要写入/etc/sysctl.conf但改之前先在测试环境验证因为不同内核版本的调度行为有差异。3. 中断处理与软中断的优化策略3.1 硬中断和软中断的区别与联系网卡收到数据包时首先触发硬中断CPU暂停当前任务去执行中断处理程序。但硬中断处理程序应该尽可能短所以它通常只做最紧急的事情比如把数据包拷贝到内存缓冲区然后触发软中断来完成后继处理。软中断在ksoftirqd内核线程中执行优先级低于普通进程但高于用户态任务。用cat /proc/softirqs可以看到各类软中断的累计次数其中NET_RX和NET_TX是网络相关的BLOCK是块设备相关的。如果某个CPU上NET_RX增长特别快说明这个核在处理大量网络数据包。用mpstat -I SUM -P ALL 1可以看到每个核的中断分布。我遇到过一个典型案例一台服务器网卡所有中断都落在CPU 0上导致CPU 0的软中断使用率长期在30%以上而其他核闲着。这就是中断亲和性没有配置好。现代网卡支持多队列每个队列可以绑定到不同的CPU核通过/proc/interrupts可以看到每个中断号对应的CPU分布。3.2 中断亲和性配置实操首先找到网卡对应的中断号# 查看网卡名称 ip link show # 查看中断分布假设网卡是eth0 grep eth0 /proc/interrupts输出会显示每个队列的中断号以及各CPU上的计数。然后可以通过/proc/irq/中断号/smp_affinity来设置亲和性。这个文件里是一个十六进制掩码比如01表示CPU 002表示CPU 103表示CPU 0和1。# 将中断号100绑定到CPU 2 echo 4 /proc/irq/100/smp_affinity # 或者用位掩码形式 echo 00000004 /proc/irq/100/smp_affinity更省事的办法是用irqbalance服务它会自动把中断分散到各个CPU上。但irqbalance在有些场景下反而会把中断集中到少数核上因为它考虑的是整体均衡而非特定网卡的队列分布。对于高性能网络场景我通常建议关掉irqbalance手动绑定。systemctl stop irqbalance systemctl disable irqbalance然后写一个脚本把每个网卡队列的中断绑定到对应的CPU核上。比如8队列网卡可以绑定到CPU 0到7每个队列一个核。3.3 RPS和RFS软件分流如果网卡队列数少于CPU核数可以用RPSReceive Packet Steering在软件层面把数据包分发到多个核上处理。配置方法是往/sys/class/net/网卡/queues/rx-队列号/rps_cpus写入CPU掩码。# 假设有4个CPU把rx-0队列的软中断分发到CPU 0-3 echo f /sys/class/net/eth0/queues/rx-0/rps_cpusRFSReceive Flow Steering更进一步它根据应用层线程的位置来决定数据包交给哪个CPU处理减少跨核缓存失效。开启RFS需要设置/proc/sys/net/core/rps_sock_flow_entries和每个队列的rps_flow_cnt。# 全局流表大小 echo 32768 /proc/sys/net/core/rps_sock_flow_entries # 每个队列的流表大小假设有4个队列 echo 8192 /sys/class/net/eth0/queues/rx-0/rps_flow_cnt echo 8192 /sys/class/net/eth0/queues/rx-1/rps_flow_cnt echo 8192 /sys/class/net/eth0/queues/rx-2/rps_flow_cnt echo 8192 /sys/class/net/eth0/queues/rx-3/rps_flow_cnt提示RPS和RFS会增加软中断的负载如果CPU本身已经吃紧开启后可能适得其反。建议在CPU使用率低于50%且网络吞吐上不去的情况下尝试。4. CPU频率调节与功耗管理4.1 频率调节器的工作模式现代CPU都支持动态频率调节Linux内核通过cpufreq子系统来管理。常见的调节器有几种performance始终跑在最高频率性能最好但功耗最高。powersave始终跑在最低频率省电但性能差。ondemand根据负载动态调整负载高时升频负载低时降频。conservative类似ondemand但升降频更平缓。schedutil基于调度器信息来调频比ondemand更精准是较新内核的默认选项。查看当前调节器cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor查看支持的调节器列表cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors对于延迟敏感的服务比如高频交易或实时数据处理建议设为performance。对于批处理任务schedutil或ondemand更合适。设置方法# 对所有CPU生效 for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance $cpu done4.2 频率调节的坑与注意事项第一个坑是虚拟机环境。很多云主机不支持频率调节/sys/devices/system/cpu/cpu0/cpufreq/目录可能根本不存在。这种情况下调频参数是无效的得从宿主机层面处理。第二个坑是温度墙和功耗墙。即使设了performanceCPU温度过高时硬件会自动降频这时候看/proc/cpuinfo里的cpu MHz会发现实际频率低于标称值。用sensors命令可以查看温度用turbostat可以看实际运行频率和功耗状态。第三个坑是调节器切换的延迟。从powersave切到performance不是瞬间生效的中间有个过渡过程。如果服务对延迟极其敏感建议在服务启动前就设好而不是运行中动态切换。4.3 与C-state的配合CPU除了频率调节还有C-state睡眠状态。C0是正常工作状态C1到C6是不同程度的睡眠越深的睡眠越省电但唤醒延迟越大。对于延迟敏感的服务建议限制最大C-state深度# 查看当前C-state限制 cat /sys/devices/system/cpu/cpu0/cpuidle/state*/disable # 禁用深度睡眠状态比如state3及以上 echo 1 /sys/devices/system/cpu/cpu0/cpuidle/state3/disable内核启动参数intel_idle.max_cstate1可以全局限制C-state深度但会显著增加功耗。这个取舍要看具体场景我一般只在延迟要求极高的场景下才动C-state。5. 常见CPU性能问题排查速查5.1 典型症状与对应排查方向症状可能原因排查命令解决方向CPU使用率高但吞吐低上下文切换过多pidstat -w 1减少线程数、调整调度策略单核跑满其他核空闲中断集中或单线程瓶颈mpstat -P ALL 1中断亲和性、多线程改造软中断使用率高网络或块设备负载大mpstat -I SUM 1RPS/RFS、多队列网卡频率上不去温度墙或功耗墙turbostat、sensors改善散热、调整功耗策略系统态CPU占比高系统调用频繁perf top减少syscall、使用批处理等待IO的CPU高IO瓶颈伪装成CPU问题iostat -x 1优化IO、增加缓存5.2 一个完整的排查案例假设你发现一台服务器CPU使用率突然从30%涨到70%但业务量没有明显变化。排查步骤可以这样走第一步用top按1展开看每个核的情况。如果只有个别核高可能是中断或单线程问题如果所有核都高可能是全局性负载增加。第二步用pidstat -u 1看是哪个进程吃掉了CPU。如果是你的业务进程继续往下查如果是内核线程如ksoftirqd转向中断排查。第三步用perf top -g看热点函数。如果看到大量__schedule说明调度开销大如果看到copy_user_enhanced_fast_string说明数据拷贝多如果看到_raw_spin_lock说明锁竞争严重。第四步根据热点函数定位具体代码路径。比如锁竞争严重可以用perf lock进一步分析是哪个锁。第五步验证假设。比如怀疑是锁竞争可以临时减少线程数看CPU是否下降怀疑是中断可以调整中断亲和性看效果。5.3 几个容易被忽略的细节第一个细节是容器环境的CPU限制。在容器里看到的CPU使用率是相对于cgroup限额的不是物理核的真实使用率。用cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us和cpu.cfs_period_us可以算出实际限额。第二个细节是NUMA架构的影响。多路服务器上跨NUMA节点访问内存的延迟是本地访问的两倍以上。用numactl --hardware查看NUMA拓扑用numastat看内存分配情况。关键进程建议用numactl --cpunodebind0 --membind0绑定到同一个NUMA节点。第三个细节是CPU缓存的影响。L1/L2缓存是核私有的L3是共享的。如果两个频繁通信的线程跑在不同核上L3缓存命中率会下降。用perf stat -e cache-misses,cache-references可以看缓存命中情况。注意所有调优操作都应该在测试环境验证后再上生产。生产环境的变更要有回滚方案尤其是内核参数和中断亲和性这类全局性配置。6. 我个人在CPU调优上的一些体会调了这么多年CPU参数最大的感受是大部分CPU性能问题不是靠调参解决的而是靠架构优化解决的。我见过太多团队花大量时间调内核参数结果发现把同步调用改成异步、把单线程改成多线程、把频繁的小IO合并成大IO效果比调参好十倍。参数调优的定位应该是“锦上添花”而不是“雪中送炭”。系统架构合理的情况下默认参数通常就能跑得不错架构有问题的情况下怎么调都是拆东墙补西墙。所以每次遇到CPU问题我的第一反应永远是先看代码逻辑和架构设计确认没有明显问题之后再考虑参数层面的微调。另外一点体会是监控比调优更重要。很多问题如果能在发生前就通过监控发现趋势处理起来会从容得多。建议至少监控这几个指标每核CPU使用率、上下文切换率、软中断分布、CPU频率、温度。这些数据积累下来出问题的时候才有对比基线不然你连“正常”是什么样都不知道。最后分享一个实用小技巧用perf record -g -p pid -- sleep 30抓30秒的性能数据然后用perf report分析比盯着top看有用得多。这个组合能直接告诉你CPU时间花在哪个函数上省去大量猜测时间。
