本文详细介绍了使用Hibench进行Kafka性能测试的方案，旨在评估Kafka处理上亿级别消息的能力。测试涵盖了消息写入、消费、不同参数配置下的性能表现，如batch-size、ack策略、message-size、compression-codec、partition和replication。测试结果显示，lz4压缩算法在吞吐量上有显著优势，而分区数、副本数与吞吐量之间的关系表明，过多的副本会导致吞吐率降低。此外，高并发可能导致IO限制，影响性能。测试结果为Kafka集群的优化提供了依据。
1.压测方案
1.1 压测目的
本次性能测试在正式环境下单台服务器上Kafka处理MQ消息能力进行压力测试。测试包括对Kafka写入MQ消息和消费MQ消息进行压力测试，根据不同量级的消息处理结果，评估Kafka的处理性能是否满足项目需求(该项目期望Kafka能够处理上亿级别的MQ消息)。
1.2 测试范围及方法
1.2.1 测试范围概述
测试使用Kafka自带的测试脚本，通过命令对Kafka发起写入MQ消息和Kafka消费MQ消息的请求。模拟不同数量级的消息队列的消息写入和消费场景，根据Kafka的处理结果，评估Kafka是否满足处理亿级以上的消息的能力。
1.2.3 测试方法
测试目的：
验证单台服务器上Kafka写入消息和消费消息的能力，根据测试结果评估当前Kafka集群模式是否满足上亿级别的消息处理能力。
测试方法
在服务器上使用Kafka自带的测试脚本，模拟1y级别的消息写入以及读取请求，查看Kafka处理不同数量级的消息数时的处理能力，包括每秒生成消息数、吞吐量、消息延迟时间。
Kafka消息写入创建的topic命名为test_kafka_throughout，Kafka消费读取的topic也是该topic;使用命令发起消费该topic的请求，针对不同的测试指标，本次我们采用固定其他值，动态变化测量值的方式来进行，具体使用脚本为kafka自带的测试脚本，分别为kafka bin目录下的kafka-producer-perf-test.sh和kafka-consumer-perf-test.sh；通过测试来查看Kafka消费不同数量级别的消息时的处理能力。
准备工作
测试之前，我们需要先用linux命令去测试磁盘的读写速度，具体命令如下：
1.测试IO读
hdparm -t --direct /dev/sda3
IO读用上面的命令测试即可，不过 hdparm 这个工具需要自己安装，而且需要root用户去执行；
2.测试IO写
sync;/usr/bin/time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"
测试结论：
1.dd测试出的读速度和hdparm 是存在区别的；
2.通过 bs 选项 设置不通的读写块大小测试(默认512字节，测试使用1M)；
3.可以看出 dd 的测出的速度与读写块的大小有关系，还可能受到系统中有IO读写的进程的影响；
4.hdparm的测试原理可能是和dd的测试方法存在差别；
整体上看，IO的实际测试速度是受到很多因素影响的，包括读写的方式(随机还是顺序，hdparm和dd测试是都是采用顺序读写)、缓存机制、测试的取样等等。
所以不太可能得到一个确定的值(相同的命令行多次测试也不一样，不过差别要小些)，以上的方法中读测试还是推荐使用hdparm。
以上的数据虽然存在偏差，但还是能大体分析出机器的IO性能。只是需要明确，这些测试值是在什么样的环境下获得的。
3.测试结果
1.磁盘cache读7471m/s；
2.disk读163m/s；
3.IO写125m/s；
4.IO读206m/s；
经过测试，我们拿到的磁盘读应该在163m/s-206m/s之间，而写速度是163m/s。后续评测我们以该磁盘测试为基准来核定。
1.3 测试环境
主 机
数量
资 源
操作系统
MQ消息服务
1
硬件：32(核)-32(G)-20(T)软件:Kafka集群(Kafka_2.11-1.1.0)
CentoOS
2.kafka参数
在调试和优化使用Java开发的系统时，第一步绕不开对JVM的调优，Kafka也不例外，而JVM调优的重点则是在内存上。
其实Kafka服务本身并不需要很大内存，其依赖的是系统提供的PageCache来满足性能上的要求，本次测试时设置30G内存的目的是支持更高的并发，高并发本身就必然会需要更多的内存来支持，同时高并发也意味着SocketBuffer等相关缓存容量会成倍增长。实际使用中，调整内存大小的准则是留给系统尽可能多的空闲内存，Broker本身则是够用就好。
JVM上的垃圾回收器，官方文档里推荐使用最新的G1来代替CMS作为垃圾回收器。为了稳定性问题，本次我们使用jdk8以上的版本，我们本次使用G1回收器的原因如下：
G1是一种适用于服务器端的垃圾回收器，很好的平衡了吞吐量和响应能力；
对于内存的划分方法不同，Eden, Survivor, Old区域不再固定，使用内存会更高效。G1通过对内存进行Region的划分，有效避免了内存碎片问题；
G1可以指定GC时可用于暂停线程的时间(不保证严格遵守)。而CMS并不提供可控选项；
CMS只有在FullGC之后会重新合并压缩内存，而G1把回收和合并集合在一起；
CMS只能使用在Old区，在清理Young时一般是配合使用ParNew，而G1可以统一两类分区的回收算法。
其使用场景如下：
JVM占用内存较大(At least 4G)；
应用本身频繁申请、释放内存，进而产生大量内存碎片时；
对于GC时间较为敏感的应用。
首先，我们设置JVM配置为：
-Xmx6G -Xms6G -XX:MMetaspaceSize=96m -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:G1HeapRegionSize=16m -XX:MinMetaspaceFreeRatio=50 -XX:MaxMetaspaceFreeRatio=80
后续在broker的相关参数测试完成后，保持其在最优的参数下，再来针对我们的服务器和kafka的页缓存及jvm堆内存以及策略等进行测试。
2.1 Producer相关参数
我们在producer涉及到性能的关键因素可能会存在如下几个：
thread:我们测试时的单机线程数；
bath-size:我们所处理的数据批次大小；
ack:主从同步策略我们在生产消息时特别需要注意，是follower收到后返回还是只是leader收到后返回，这对于我们的吞吐量影响颇大；
message-size:单条消息的大小，要在producer和broker中设置一个阈值，且它的大小范围对吞吐量也有影响；
compression-codec:压缩方式，目前我们有不压缩，gzip，snappy，lz4四种方式;
partition:分区数，主要是和线程复合来测试；
replication:副本数；
througout:我们所需要的吞吐量，单位时间内处理消息的数量，可能对我们处理消息的延迟有影响；
linger.ms：两次发送时间间隔，满足后刷一次数据。
2.2 Consumer相关参数
thread：我们测试时的单机线程数；
fetch-size：抓取数据量；
partition:分区数，主要是和线程复合来测试；
replication:副本数；
througout:我们所需要的吞吐量，单位时间内处理消息的数量，可能对我们处理消息的延迟有影响；
2.3 Broker相关参数
num.replica.fetchers：副本抓取的相应参数，如果发生ISR频繁进出的情况或follower无法追上leader的情况则适当增加该值，==但通常不要超过CPU核数+1；==
num.io.threads：broker处理磁盘IO的线程数，主要进行磁盘io操作，高峰期可能有些io等待，因此配置需要大些。==建议配置线程数量为cpu核数2倍，最大不超过3倍；==
num.network.threads：broker处理消息的最大线程数，和我们生产消费的thread很类似主要处理网络io，读写缓冲区数据，基本没有io等待，==建议配置线程数量为cpu核数加1；==
log.flush.interval.messages：每当producer写入多少条消息时，刷数据到磁盘；
log.flush.interval.ms：每隔多长时间，刷数据到磁盘；
3.flink参数
4.测试过程
4.1 producer测试
4.1.1 bath-size
测试脚本
./kafka-producer-perf-test.sh --topic test_kafka_perf1 --num-records 100000000 --record-size 687 --producer-props bootstrap.servers=10.240.1.134:9092,10.240.1.143:9092,10.240.1.146:9092 batch.size=10000 --throughput 30000
./kafka-producer-perf-test.sh --topic test_kafka_perf1 --num-records 100000000 --record-size 687 --producer-props boots
最低0.47元/天 解锁文章
扫一扫
688
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
