公众号「后端进阶」 每一步成长都想与你分享

记一次 Kafka Producer 性能调优实战

2020-09-18
zch

最近,遇到某个集群的生产端发送延迟特别高,而且吞吐量上不去,检查集群负载却很低,且集群机器配置非常好,网络带宽也很大,于是使用 Kafka 压测脚本进行了压测。

昨天凌晨,在生产环境进行实战调优,经过不断参数改动,现将生产者相关参数设置为以下配置:

linger.ms=50
batch.size=524288
compression.type=lz4
acks=1(用户要求消息至少要发送到分区 leader)
max.request.size=5242880
buffer.memory=268435456

在生产环境的一台服务器上,使用以上参数对集群进行生产发送性能压测:

从上图可以看到,使用平均 4k 大小的消息体对集群进行压测,单个 Producer 平均吞吐量达到 2000MB/s,50w/s+

作为对比,我还是使用同一台服务器,将调优参数去掉,再压一遍:

可以看到,最高的吞吐量也不过 500M/s,最低已经来到 2M/s 了。

虽然说实际客户端环境比压测环境复杂很多,但是使用压测工具已经能够证明,该集群的负载目前现在还远远没有达到瓶颈,且生产端还有待优化。

以上参数调优思想是:

1、buffer.memory=268435456

由于发送端发送频率非常快,加上由于 Spark 客户端频繁断开连接导致生产端 Sender 线程发送延迟增高,这就会造成客户端发送速率 > Sender线程的发送速率。

它们之间会有一个缓冲池,如果客户端发送速率 > Sender 线程的发送速率,缓冲池会很快塞满,阻塞当前发送进程,导致发送延迟增高。

注:如果 Java 进程的堆内存大小允许,可以适当再调大一些。

2、batch.size=524288

我们的客户端消息大小普遍 4k 左右,而 batch.size 默认大小为 16k,如果直接使用默认的大小,每个批次很容易被塞满,达不到缓冲的作用。而且,如果消息大小 > batch.size,则缓冲池不会对该消息产生作用,导致内存频繁被 JVM GC 回收,具体详情请看这篇文章:「深度剖析 Kafka Producer 的缓冲池机制【图解 + 源码分析】」。

3、max.request.size=5242880

该参数主要作用是限定每次发送到 broker 的数据大小,默认值为 1M,如果太小,会导致生产端与 broker 的网络交互增多,加上加上由于 Spark 客户端频繁断开连接导致生产端 Sender 线程发送延迟增高。

如上图,当 max.request.size=5242880 时,请求 broker 发送的数据量不大于 max.request.size。

如果频繁地进行网络交互,延迟也会随之增高,该值可以根据集群网络带宽适当设置更大一些,我们的集群带宽非常充足,可以适当再调大些。

4、linger.ms=50

为了防止某些时候发送速率很低,batch 没有装满导致不发送消息的情况,需要适当调整该值,与 batch.size 的大小适当调整为最佳大小。

注:以上参数仅仅是根据我的生产集群实际情况给出的值,具体参数还是需要结合你的集群本身的情况,机器的配置,网络的带宽不同,都会影响参数的值。


更多精彩文章请关注作者维护的公众号「后端进阶」,这是一个专注后端相关技术的公众号。 关注公众号并回复「后端」免费领取后端相关电子书籍。 欢迎分享,转载请保留出处。

微信公众号「Java科代表」

Content