Kafka Mirror Maker 2.0性能调优求助：跨集群复制吞吐量瓶颈

是否存在固有限制？ #

MM2的吞吐量没有绝对固定的上限，其性能上限由源集群消费能力、目标集群生产能力、跨集群网络带宽、MM2自身线程/资源配置共同决定。你观察到的「payload越大吞吐量越低」是消息系统的通用规律：大消息会占用更多网络带宽与磁盘IO资源，单条消息的处理（序列化、传输、持久化）开销更高，因此TPS会随消息体积增大而下降。你的当前测试结果远低于合理预期，说明存在配置或资源瓶颈，而非MM2的固有上限。

遗漏的关键配置项 #

你当前仅配置了源集群（cluster1）的消费相关参数，忽略了目标集群（cluster2）的生产配置，以及MM2核心的线程/任务调度配置，以下是需要补充调整的关键项：

调整后的完整配置参考 #

clusters = cluster1, cluster2 
max.tasks=5  # 主题仅5个分区，任务数无需超过分区数，避免线程上下文切换开销
# 源集群消费配置（保留现有配置基础上补充）
cluster1.max.poll.records = 20000
cluster1.receive.buffer.bytes = 33554432
cluster1.send.buffer.bytes = 33554432
cluster1.max.partition.fetch.bytes = 33554432
cluster1.message.max.bytes = 37755000
cluster1.compression.type = gzip
cluster1.max.request.size = 26214400
cluster1.buffer.memory = 524288000
cluster1.batch.size = 524288
cluster1.fetch.min.bytes = 524288
cluster1.fetch.max.wait.ms = 500
cluster1.consumer.threads = 5  # 与分区数匹配，保证每个分区有独立消费线程
# 目标集群生产配置（新增）
cluster2.batch.size = 524288  # 与源端一致，保证批量发送效率
cluster2.buffer.memory = 524288000  # 足够的缓冲内存，避免消息阻塞
cluster2.compression.type = gzip  # 与源端保持一致，避免重复解压压缩开销
cluster2.max.request.size = 26214400  # 匹配源端配置，支持大消息发送
cluster2.producer.threads = 5  # 与分区数匹配，保证每个分区有独立生产线程

关键配置调整说明 #

• max.tasks：MM2的任务数上限等于待复制主题的总分区数，配置超过分区数的任务只会造成资源浪费，建议设置为与主题分区数一致（5）。
• consumer.threads/producer.threads：默认线程数可能无法充分利用CPU资源，设置为与分区数匹配，保证每个分区的复制流程有独立线程处理，避免线程竞争。
• fetch.min.bytes/fetch.max.wait.ms：让源端消费者积累足够的消息再发起拉取请求，减少拉取次数，提升消费吞吐量。
• 目标集群生产配置：生产端的批量大小、缓冲内存直接决定了发送效率，必须与源端的消费能力匹配，否则会成为吞吐量瓶颈。

公开性能测试数据参考 #

官方社区及第三方测试数据显示，在最优配置下：

• 单节点MM2可实现100k+ TPS（单条消息1KB左右），或数百MB/s的吞吐量。
• 当消息大小在64B-256B区间时，只要网络带宽充足（10Gbps以上）、目标集群磁盘IO负载正常，MM2的TPS应能接近源端生产速率。

额外排查建议 #

1. 检查目标集群的生产日志，确认是否存在BufferExhaustedException（缓冲不足）或RecordTooLargeException（请求大小超限）。
2. 监控MM2的JVM指标：查看GC频率、线程状态，排查是否存在线程阻塞或GC停顿过长的问题。
3. 测试跨集群网络带宽：使用iperf工具验证源集群到目标集群的实际可用带宽，排除带宽瓶颈。
4. 检查目标集群磁盘IO负载：若磁盘使用率超过80%，会导致生产端写入阻塞，需优化磁盘配置（如使用SSD、调整RAID策略）。

内容的提问来源于stack exchange，提问作者Sandeep Tengale