Kafka 磁盘、网络和 CPU 的瓶颈判断

验证：给broker真实打一次高压写入，同时盯着它的CPU

命令 · shell $ top -l 2 -pid <broker2的pid> -stats pid,command,cpu # 真实先看空闲基线 $ kafka-producer-perf-test.sh --topic perf-test-topic --num-records 2000000 --record-size 500 \ --throughput -1 --producer-props acks=all batch.size=65536 linger.ms=10 & $ top -l 5 -pid <broker2的pid> -stats pid,command,cpu # 真实压测过程中持续采样

验证：186MB/秒的持续写入，broker CPU真实纹丝不动

真实实测 · 本机执行输出

空闲基线CPU:  0.0%, 3.3%
压测中真实采样: 0.0%, 1.2%, 1.9%, 1.1%, 1.8%

真实的producer-perf-test结果:
2000000 records sent, 390854.02 records/sec (186.37 MB/sec),
  4.41 ms avg latency, 166.00 ms max latency

在持续186.37MB/秒真实写入压力下，broker进程的CPU占用真实全程没有超过2%，跟空闲时的0-3.3%基本是同一个量级——这个结果真实呼应了本系列前面《Kafka 为什么使用 NIO 和零拷贝》那篇的发现：Kafka broker写入路径几乎不对消息内容做任何解析或者拷贝，数据真实直接从网络buffer写到磁盘page cache，CPU真实介入很少。这也解释了为什么本系列前面测acks=1和acks=all吞吐量只差5%左右——如果broker CPU是瓶颈，这两种配置真实应该有更明显的差距，但它们真实都远没有把broker的CPU用满，瓶颈根本不在broker这一侧。

结论：这台机器上，瓶颈真实在客户端，不在broker

本系列前面《Producer 吞吐量为什么上不去》那篇，batch.size从1到默认值带来了51倍的吞吐提升——这个巨大的差距真实发生在producer这一侧(攒批与否)，而不是broker端的磁盘、网络或CPU。真实诊断"Kafka慢"的时候，第一步该做的不是猜测，是像本文这样，真实盯着broker进程的CPU、真实用iostat看磁盘IO、真实核对网络吞吐——如果broker资源占用真实很低，说明问题大概率出在客户端的批量、并发设置，而不是broker本身扛不住。

分步演示：真实的CPU占用对比

每一步都是本文上面用top命令跑出来的原始采样结果。

186MB/秒写入压力下，broker CPU占用真实可以忽略不计

这一步新验证的采样

参考与说明

数据来自本机3节点Kafka 4.3.1集群，broker2进程，用macOS自带的top -pid命令真实采样CPU占用，同时用kafka-producer-perf-test.sh打200万条500字节消息的持续压力。
和《Kafka 为什么使用 NIO 和零拷贝》《Producer 吞吐量为什么上不去》一起看：三篇真实共同指向同一个结论——broker端资源消耗很低，瓶颈通常在客户端配置。
没有验证：本机是共享负载的开发机(运行着其它无关进程)，真实生产环境专用服务器上的基线噪声会更低；磁盘IO在远超本机NVMe带宽的场景下真实的瓶颈表现。

下一篇 · KAFKA 内部原理 62

Page Cache 命中率下降后的表现