kafka性能调优解密(三)-- Consumer端

网友投稿 810 2022-05-29

Consumer篇

kafka性能调优解密(三)-- Consumer端

1  fetch.message.max.bytes

这个参数是Consumer每次发起获取消息请求的时候,会发往给broker端指导broker端每次读取partition日志时的最大消息长度。这个值越大有利于减少日志读取的次数,提升broker端获取数据的速度,但越大占的内存也越大。在读取数据时,BoundedByteBufferReceive.readFrom用来申请读取缓存的总大小(byteBufferAllocate), 同时这个设置是针对每个分区的,即共需要的内存为fetch.size * partitionNum

1.3 实测分析

1. 个broker 创建10个分区的topic

2. 同时启动Producer与Consumer,一起测试

3. 测试Consumer scoket.receiver.buffer.bytes取值为256k 或者2M, 这两者在不同fetch.message.max.bytes的区别

10G网卡下,10分区,2k数据,发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据,10个线程, bufferMemory为32M, Producer默认send buf为128k:

10分区,4k数据,发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据,10个线程, bufferMemory为32M, Producer默认send buf为128k:

可以看出无论是2k或者4k数据,fetch.size在1M~8M之间,Consumer性能都是在峰值范围

结论:

1. 需要根据业务最大消息来配置,比如业务最大4M, 这个参数至少配置4M

2. 实测证明,在内存足够的情况下,也不是越大越好。从目前来看1M~8M性能都稳定在峰值附近

2 num.consumer.fetchers

该参数是用于指定Consumer端用于fetcht数据的线程数(fetch threads),如下图:

Consumer跟根据这个线程个数和Topic的分区数,均匀地分布在这些fetch threads上。增大这些线程能起到一定的提升性能,但是多于分区个数后,就会有线程空闲。

2.3 实测分析

1. 2个broker 创建10个分区的topic

2. 同时启动Producer与Consumer,一起测试

3. 通过指定Consumer不同的fetch threads,查看性能结果

10G网卡下,10分区,2k数据,发送1000000, ack都为1, 10个Producer与10个Consumer一起跑, Consumer每次从队列开始读取数据,bufferMemory为32M:

结论:

1. 从性能上看,10个Consumer线程配10个Fetch 线程,性能最优

2. 10个Fetch线程后面就会有空闲的线程分配不到partition

3  offsets.storage

Kafka会记录offset到zk中。但是,zk client api对zk的频繁写入是一个低效的操作。0.8.2 kafka引入了native offset storage,将offset管理从zk移出,并且可以做到水平扩展。其原理就是利用了kafka的compacted topic,offset以consumer group,topic与partion的组合作为key直接提交到compacted topic中。同时Kafka又在内存中维护了的三元组来维护最新的offset信息,consumer来取最新offset信息的时候直接内存里拿即可。当然,kafka允许你快速的checkpoint最新的offset信息到磁盘上。

3.3 实测分析

1. 2个broker 创建10个分区的topic

2. 同时启动Producer与Consumer,一起测试

3. 在不同的压力下, 查看offsets.storage保存在zk上性能好还是broker上好

10G网卡下,10分区,2k数据,发送1000000, ack都为1, N个Producer与N个Consumer一起跑, Consumer每次从队列开始读取数据,10个线程, bufferMemory为32M, Consumer receiver buffer大小为2M:

从上面的数据来看,存储在zookeeper与存储在kafka,性能峰值相差不

结论:

1.在broker节点数不是很多并且对zk节点写入不大的情况下,这个选项对性能影响不是很大,但以后社区会推用存储在kafka,为了避免以后修改,建议值为kafka

尾声

性能相关的核心参数详解到处就结束了,希望对大家业务应用有帮助。对于应用PUMA或者kafka作为消息总线的用户,应该在实施过程关注过这样的问题:具体业务不同可靠模式下,对于特定硬件及网络,需要多少资源,才能达到业务需要的吞吐量。这个PUMA经过大量实践验证及理论分析,证明可以通过简单测试及公式计算就可以完成业务资源部署评估,相关进一步信息欢迎联系PUMA或持续关注后续的解密,谢谢~

Kafka 应用性能调优

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:[华为云在线课程][Git基础与实操][第2章][Git基础实战篇]
下一篇:表空间及分区表的概念
相关文章