文件密码忘记了怎么办(加密文件密码忘记了怎么办)
810
2022-05-29
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小时内删除侵权内容。