下面给你的是 生产环境真正可用的 Kafka 性能瓶颈 → JMX 指标对照表。
目标不是罗列指标，而是建立：

现象 → 观察哪些 JMX → 如何判断 → 对应优化动作

这是 Kafka SRE / 运维排障的核心方法论。

---

Kafka 性能瓶颈 → JMX 指标对照表（生产级）

我按 7 大类瓶颈模型整理，这是 Kafka 99% 性能问题来源。

---

一、写入延迟高（Producer 发送慢）

📌 现象

• Producer send() 阻塞

• ack 等待时间长

• TPS下降

---

🔍 重点 JMX 指标

1️⃣ 请求延迟（核心指标）

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=Produce

关注：

属性	含义
Mean	平均延迟
99thPercentile	P99 延迟

---

2️⃣ 请求队列

kafka.network:type=RequestChannel,name=RequestQueueSize

---

3️⃣ Purgatory（等待ACK）

kafka.server:type=DelayedOperationPurgatory,name=PurgatorySize,delayedOperation=Produce

---

✅ 判断逻辑

指标变化	结论
TotalTimeMs ↑	Broker处理慢
QueueSize ↑	网络线程不足
Purgatory ↑	ISR同步慢

---

🛠 优化方向

num.network.threads ↑
num.io.threads ↑
batch.size ↑
linger.ms ↑

---

二、Kafka 吞吐低（带宽未跑满）

📌 现象

• CPU 很低

• 网络很低

• TPS 上不去

---

🔍 JMX 指标

kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec
kafka.server:type=BrokerTopicMetrics,name=MessagesInPerSec

---

Socket 空闲率（关键）

kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

---

✅ 判断

指标	解释
IdlePercent > 0.6	Broker 很闲
TPS低	Producer限制

👉 问题在客户端。

---

🛠 优化

Producer：

compression.type=lz4
batch.size=64KB+
linger.ms=10~50
acks=1（允许）

---

三、磁盘 IO 瓶颈（最常见）

📌 现象

• 延迟周期性抖动

• CPU idle 高

• iowait 高

---

🔍 JMX 指标

Flush 延迟

kafka.log:type=LogFlushStats,name=LogFlushRateAndTimeMs

---

写入时间

kafka.network:type=RequestMetrics,name=LocalTimeMs,request=Produce

---

✅ 判断

指标	含义
LocalTimeMs ↑	磁盘慢
FlushTime ↑	fsync阻塞

---

🛠 优化

log.flush.interval.messages 调大
使用 SSD/NVMe
num.io.threads ↑

---

四、副本同步慢（ISR问题）

📌 现象

• Producer timeout

• ISR频繁变化

• leader election

---

🔍 JMX

⭐ 核心指标

kafka.server:type=ReplicaManager,name=UnderReplicatedPartitions

---

Follower Fetch 延迟

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchFollower

---

✅ 判断

指标	说明
URP > 0	副本落后
FetchFollower慢	Broker间网络/IO问题

---

🛠 优化

replica.fetch.max.bytes ↑
num.replica.fetchers ↑
检查跨机房延迟

---

五、Consumer 消费慢

📌 现象

• Lag 持续增长

• Broker正常

---

🔍 Broker侧 JMX

kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec

---

FetchConsumer 延迟

kafka.network:type=RequestMetrics,name=TotalTimeMs,request=FetchConsumer

---

✅ 判断

情况	结论
BytesOut低	consumer慢
FetchConsumerTime低	broker没问题

---

🛠 优化

Consumer：

fetch.min.bytes ↑
max.poll.records ↑
增加consumer实例

---

六、线程瓶颈（隐藏杀手）

Kafka 是线程模型驱动系统。

---

🔍 JMX

网络线程

kafka.network:type=SocketServer,name=NetworkProcessorAvgIdlePercent

IO线程

kafka.server:type=KafkaRequestHandlerPool,name=RequestHandlerAvgIdlePercent

---

✅ 判断标准（黄金经验）

IdlePercent	状态
>0.4	健康
0.2~0.4	紧张
<0.2	瓶颈

---

🛠 优化

num.network.threads ↑
num.io.threads ↑

---

七、JVM GC 瓶颈（80%人误判）

📌 现象

• Kafka 卡顿

• 延迟周期性尖峰

---

🔍 JMX

java.lang:type=GarbageCollector,name=G1 Young Generation

关注：

指标	含义
CollectionTime	GC耗时
CollectionCount	GC次数

---

Heap：

java.lang:type=Memory

---

✅ 判断

现象	结论
GC time ↑	堆太小
Full GC	配置问题

---

🛠 优化

-Xms = -Xmx
G1GC
堆大小 = RAM * 50%

---

⭐ Kafka 性能瓶颈速查总表（最重要）

症状	看这个 JMX	根因
写入慢	Produce TotalTimeMs	IO/线程
TPS低	IdlePercent	Producer
延迟抖动	LogFlushTimeMs	磁盘
ISR减少	UnderReplicatedPartitions	副本慢
Lag增长	BytesOutPerSec	Consumer
CPU低但慢	QueueSize	线程不足
周期卡顿	GC Time	JVM

---

🔥 SRE级排障顺序（强烈建议记住）

遇到 Kafka 慢：

① TotalTimeMs
      ↓
② QueueSize
      ↓
③ IdlePercent
      ↓
④ UnderReplicatedPartitions
      ↓
⑤ LogFlushTimeMs
      ↓
⑥ GC

90% 问题 5 分钟定位。

---

✅ 核心认知（非常重要）

Kafka 性能 ≠ CPU 使用率

真正瓶颈通常是：

线程模型
+ Page Cache
+ 顺序写磁盘
+ 副本同步

而这些 全部只能通过 JMX 看见。