单核吃满的多核假象

load average 不高，某个服务却慢得反常，先把 top 按数字 1 展开，看看是不是只有一个核在燃烧。平均值是最会骗人的指标，多核机器上尤其如此。 一、现象长什么样 八核机器 CPU 总使用率才两成，展开一看其中一核 100%，其余七个核闲着。top 按 1 之后每核一行，哪一行恒定在 99% 一眼可见。单线程程序把一个核吃满之后，吞吐就卡在单核上限，加多少核都无济于事，监控的平均值把它完美遮住了。这一幕在排障时反复上演：加配置、复测、还是慢，绕一大圈回到单核。 二、为什么会有单线程程序 不少服务天生单进程处理：队列消费者、脚本型业务、某些应用的线程池默认只开一条。判断依据很简单：单进程 CPU 长期顶在一颗核的量级上不去。这类程序横向扩展容易、纵向升级无效，是限制也是便利。它们的性能天花板就是一颗核，这是程序结构决定的，不是资源不足。 三、怎么确认 top 按 1 展开每核占用；pidstat -t -p PID 1 看进程内各线程的 CPU 分布，确认是否单线程在忙；mpstat -P ALL 1 看各核历史曲线。不同工具的核占用统计口径略有差异，确认时别被小数点骗了。另外留意中断集中在单核的情况，cat /proc/interrupts 里某一列异常突出，说明网卡中断没分散。火焰图也能佐证，热点集中在单一执行路径上的特征很明显。 四、业务拆分思路 程序支持多实例的，起多个实例绑不同端口，前面用 Nginx 反向代理分流；支持线程池调参的，把工作线程数开到核数附近再观察；实在改不了的，用任务队列把工作切给多个消费者进程。改完看单核占用是否摊平，这是验收标准。拆分粒度从粗到细，先复制实例再谈代码改造，别一上来就动架构。 扩容之前先确认瓶颈真的在核上，否则机器越换越大，浪费也越大。