我首先要看看问题是否不是gc调优问题。以下是几种可能性：
硬内存泄漏将导致gc时间增加。gc所做的工作主要是跟踪和复制可到达的对象。如果你有一个泄漏，那么越来越多的对象将（不正确）达到。
保持太多对象可访问的缓存也会增加gc时间。
过度使用引用类型、终结器等可能会增加gc时间。
我将启用gc日志记录，并查找gc报告的内存和空间利用率模式。如果您怀疑内存泄漏是因为内存利用率在长期内呈上升趋势，请转到下一步并使用内存配置文件来跟踪泄漏。
无论哪种方式，在试图解决问题之前，了解问题的起因都是很重要的。
经过进一步分析，我们发现每秒的数据量确实有所增加。其中一个主题将消息输入从10kbps左右增加到200kbps。但我相信Kafka可以很容易地处理这些数据。
很可能是这样。然而，20倍的吞吐量增长将不可避免地导致更多的对象被创建和丢弃。。。gc需要更频繁地运行来处理这个问题。
为什么仅仅在5个代理之间分配200kbps的数据就能够破坏gc呢。
是什么让你认为你已经“破坏”了gc？gc中15%的时间并不意味着它坏了。
现在，我可以想象gc可能很难达到你的20ms最大暂停时间目标，结果可能会触发偶尔的完全gcs。您的暂停时间目标是“雄心勃勃的”，尤其是当堆可能增长到10gb时。我建议减少堆大小，增加暂停时间目标，和/或增加jvm可用的物理内核的数量。
打破我的意思是增加延迟提交抵消和其他生产者和消费者抵消。
所以。。。您只是担心负载增加20倍会导致gc使用高达15%的可用cpu。好吧，那还没坏。这是（国际海事组织）所期望的。垃圾收集器不是魔法。它需要使用cpu时间来完成它的工作。它需要做的工作越多，它需要使用的cpu就越多。如果应用程序的工作负载涉及大量的对象分配，那么gc必须处理这些问题。
除了上面的调优思想之外，我怀疑您应该设置 G1HeapRegionSize 尺寸要小得多。根据monica beckwith的“垃圾第一垃圾收集器调优”，默认值是基于最小堆大小的2048个区域。但您的设置将给出1g/16m==64个初始区域。
最后，如果您的总体目标是降低gc的cpu利用率，那么您应该使用吞吐量gc，而不是g1gc。这将最小化gc开销。缺点是gc暂停最小化不再是一个目标，因此偶尔会有长时间的暂停。
如果您打算继续使用g1gc，建议使用最新版本的java；i、 e. java 11(参见“g1垃圾收集器在java9中已经成熟了，最后”）

Kafka2.1默认使用g1gc，所以我想您可以省略这个参数。我假设你没有使用JDK11。与以前的版本相比，JDK11给g1gc带来了显著的改进。它现在可以实现并行处理，而不是运行一个单线程的完整gc周期。尽管这不应该大大改善最佳情况下的情况，但最坏情况下的情况应该会有显著的改善。如果可能的话，请在迁移到jdk 11后共享您的结果。
注：我怀疑这是根本原因，但让我们看看。