最近,遇到某个集群的生产端发送延迟特别高,而且吞吐量上不去,检查集群负载却很低,且集群机器配置非常好,网络带宽也很大,于是使用 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 的大小适当调整为最佳大小。
注:以上参数仅仅是根据我的生产集群实际情况给出的值,具体参数还是需要结合你的集群本身的情况,机器的配置,网络的带宽不同,都会影响参数的值。
近期热文
原创不易,如果对你有帮助,麻烦各位读者帮忙点个「在看」或者「转发」一下文章!
再次感谢你的阅读!
本文分享自微信公众号 - 后端进阶(objcoding)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
来源:oschina
链接:https://my.oschina.net/u/3762425/blog/4600179