Apache Kafka从2.7升级至3.7后性能测试结果大幅劣化求助

问题背景 #

将Apache Kafka从2.7版本升级至3.7版本后，使用kafka-producer-perf-test.sh对指定主题进行基准测试时，发现性能出现显著退化：例如延迟从5ms飙升至60ms。

测试主题创建命令如下：

bin/kafka-topics.sh --bootstrap-server X:9092  --create --topic perf-test compression.type=snappy --config min.insync.replicas=2 --config retention.ms=84000000 --partitions 9 --replication-factor 3  --command-config /Y

排查方向与步骤 #

1. 确认性能测试命令的一致性 #

Kafka 3.x版本的kafka-producer-perf-test.sh默认参数可能与2.7版本存在差异，acks、batch.size、linger.ms等关键参数的默认值变化会直接影响测试结果。

• 必须确保两次测试使用完全相同的命令参数，显式指定所有影响性能的配置，避免依赖默认值：

  bin/kafka-producer-perf-test.sh --bootstrap-server X:9092 \
    --topic perf-test \
    --record-size 1024 \
    --num-records 1000000 \
    --acks 1 \
    --batch-size 16384 \
    --linger-ms 5 \
    --compression-type snappy \
    --producer-config /path/to/producer.properties
  

• 对比2.7版本测试时使用的命令，确保所有参数完全对齐后重新执行测试，验证是否为参数差异导致的性能变化。

2. 检查主题配置的正确性 #

原主题创建命令存在语法错误：--topic perf-test compression.type=snappy会将主题名错误设置为perf-test compression.type=snappy，而非给主题配置compression.type=snappy，这会导致压缩配置未生效，直接影响性能。

• 先确认目标主题的实际配置：

  bin/kafka-configs.sh --bootstrap-server X:9092 --describe --topic perf-test
  

  （如果原命令创建了错误名称的主题，替换为实际主题名）
• 验证compression.type=snappy、min.insync.replicas=2等配置是否正确生效，若配置缺失，需重新添加主题配置：

  bin/kafka-configs.sh --bootstrap-server X:9092 --alter --topic perf-test --add-config compression.type=snappy
  

3. 排查Broker端配置变化 #

Kafka 3.x版本对Broker默认配置做了不少调整，部分参数会直接影响生产者性能：

• 对比2.7与3.7版本的server.properties，重点检查以下参数：
  • acks：Broker级别的默认生产者确认策略，若从1改为all会大幅提升延迟
  • min.insync.replicas：集群默认的最小同步副本数，若高于2会增加副本同步开销
  • compression.type：Broker默认的消息压缩类型，若从snappy改为none会增加网络传输量
  • replica.lag.time.max.ms：副本滞后超时时间，若缩短会导致ISR频繁收缩，影响生产稳定性
  • log.flush.*：日志刷新相关参数，若刷新频率过高会增加磁盘IO开销
• 若发现参数变更不符合业务需求，调整回升级前的配置后重新测试。

4. 检查集群硬件与网络状态 #

升级过程中可能伴随硬件、网络环境的变化，或是集群存在资源瓶颈：

• 监控Broker节点的CPU、内存、磁盘IO使用率，确认是否存在IO瓶颈（比如磁盘写入速度不足）或CPU过载
• 检查Broker之间的网络延迟，若副本同步的网络延迟增加，会直接导致生产者等待确认的时间变长
• 查看副本同步状态，确认是否存在欠复制分区：

  bin/kafka-topics.sh --bootstrap-server X:9092 --describe --topic perf-test
  

  若ISR列表不完整或存在UnderReplicatedPartitions，需排查副本同步异常的原因。

5. 排查新版本特性带来的开销 #

Kafka 3.x引入的部分新特性可能带来额外性能开销：

• 若升级时迁移到了KRaft模式，需检查KRaft控制器的性能，调整kraft.controller.quorum.voters等配置优化控制器效率
• 检查是否默认启用了幂等生产者、事务等特性，此类特性会增加额外的协调开销，若不需要可在生产者配置中关闭
• 确认日志格式是否自动升级（比如从v2到v3），日志格式升级可能带来短期IO开销，待升级完成后重新测试。

6. 验证测试环境一致性 #

确保两次性能测试的环境完全一致：

• 测试客户端的机器配置、网络位置需与2.7版本测试时相同，避免客户端自身负载过高影响结果
• 测试时集群需无其他业务流量、数据迁移、分区重平衡等任务运行，排除外部干扰。

内容的提问来源于stack exchange，提问作者Amir Abbas