kafka压力测试说明书(九) - 简书

1 整体环境说明

1.1 硬件环境

1、 磁盘:SATA磁盘2块,磁盘阵列为RAID1

2、 CPU****:2个4核CPU。具体参数:Intel(R) Xeon(R) CPU E5405 @ 2.00GHz

3、 内存:8G(8*1G)

4、 网卡:1000Mb/s

1.2 软件环境

1、 kafka版本:kafka_2.11-0.11.0.3

2、 kafka集群数量:3

3、 zookeeper版本:zookeeper-3.4.12

4、 zookeeper集群数量:3

5、 zookeeper使用单独的集群,不使用kafka自带zookeeper

2 服务器自身瓶颈测试

由于kafka是的吞吐量特别大,所以先考虑集群服务器的自身瓶颈。如磁盘IO瓶颈。由于kafka做的集群所以需要相互传输数据,所以要考虑网卡瓶颈。

2.1 测试磁盘IO瓶颈

2.1.1 磁盘IO写入瓶颈

1、使用以下命令测试磁盘IO的写入瓶颈

    # sync;time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"

解释:在当前目录下创建一个test.dd的文件,写入20000个1M的数据。

2、使用iostat命令监测磁盘io情况。

使用命令

    # iostat -x 1

解释:扩展查看io性能,每1秒钟刷新一次。

注意:如果没有iostat。请执行yum install sysstat –y命令进行安装iostat命令

3、结果展示

(1)磁盘写入IO结果

    # sync;time -p bash -c "(dd if=/dev/zero of=test.dd bs=1M count=20000)"

记录了20000+0 的读入

记录了20000+0 的写出

20971520000字节(21 GB)已复制,221.314 秒,94.8 MB/秒

real 221.67

user 0.01

sys 21.20

磁盘写入IO为94.8 MB/秒

(2)iostat命令结果


关注wkB/s和%util两个参数

wkB/s:每秒写入设备的数据量(单位:KB)

%util:消耗在I/O请求中的CPU时间百分比(设备带宽利用率)。如果该值接近100%说明设备出现了瓶颈。

2.1.2 磁盘IO读取瓶颈

1、使用以下命令测试磁盘IO的读取瓶颈

    # hdparm -tT --direct /dev/sda

解释:hdparm命令是显示与设定硬盘的参数。-t参数为评估硬盘的读取效率(不经过磁盘cache)。-T参数为评估硬盘的读取效率(经过磁盘cache)

注意:如果没有hdparm命令可以直接yum –y install hdparm即可

2、使用iostat命令监测磁盘io情况。

使用命令

    # iostat -x 1

3、结果展示

    # hdparm -tT --direct /dev/sda

/dev/sda:

 Timing O_DIRECT cached reads: 326 MB in 2.00 seconds = 162.83 MB/sec

 Timing O_DIRECT disk reads: 322 MB in 3.01 seconds = 106.88 MB/sec

解释:经过磁盘cache的磁盘读取为162.83 MB/sec

未经过磁盘cache的磁盘读取为106.88 MB/sec

2.2 磁盘性能总结

以我的服务器SATA磁盘2块,磁盘阵列为RAID1的配置。磁盘写入数据瓶颈为94.8 MB/秒。读取数据瓶颈经过磁盘cache的磁盘读取为162.83 MB/秒,未经过磁盘cache的磁盘读取为106.88 MB/秒。如果kafka集群的写入速度和读取数据的速度达到这个数值,或者iostat的输出结果%util的值接近100%。说明磁盘已经到达一个瓶颈。会影响压测数据的准确性。

2.3 网卡性能总结

我的网卡是千兆网卡,传输数据可以达到1000Mb/s,由于我们使用的单位都为MB/s。所以把Mb换算成MB。1000Mb/s=125MB/s。也就是说传输熟读到达125MB/s的时候是网卡的瓶颈。会影响压测数据的准确性。

3 Kafka测试前期准备

3.1 影响测试结果配置分析

Kafka的性能测试主要测试kafka的吞吐量,kafka吞性能为生产者在向kafka传入消息时的写入量,kafka的吐性能为消费者在kafka集群中消费的能力,也就是读取量。

3.1.1 Borker相关

Kafka的borker是kafka集群的缓存代理,消息中间件处理结点,一个Kafka节点就是一个broker,多个broker可以组成一个Kafka集群。下面是相关broker的参数分析。

1、num.partiton

topic物理上的分组,一个topic可以分为多个partition,每个partition是一个有序的队列。

Partition的数量选取也会直接影响到Kafka集群的吞吐性能。例如我们接口如果开了多个线程去消费kafka的数据,当Partition数量相对于流入流出的数据量显得较少,或由于业务逻辑和Partition数量没有匹配好造成个别Partition读写数据量大,大量的读写请求集中落在一台或几台机器上时就会很影响效率。

2、Default.replication.factor

Replication参数为kafka集群副本数。这个参数决定了kafka的高可用性。也决定了kafka的吞吐量。此数据运算和broker个数和broker上的分区数量都有关系。正常broker为3replication设置为1最好。因为3个节点的集群可以宕机一台可以继续工作,而3个replication可以保证宕机两个节点正常工作。所以多replication会造成资源浪费。如果数据不需要持久化和数据不重要并且写入量特别大的话,可以考虑replication为0。

3、num.network.thread

用于接收并处理网络请求的线程数,默认为3。其内部实现是采用Selector模型。启动一个线程作为Acceptor来负责建立连接,再配合启动num.network.threads个线程来轮流负责从Sockets里读取请求,一般无需改动,除非上下游并发请求量过大。

4、写入数据每条大小

    '{"indexdiy":"catalina","input_type":"log","message":"[2018-09-26 12:30:13,030] [org.apache.tomcat.util.net.NioSelectorPool] [INFO] [Using a shared selector for servlet write/read]","offset":17600578,"project_tag":"catalina","source":"/opt/tomcat7/logs/catalina.out","type":"log"}'

以上面一条日志为例。此条日志大小为283B。所以我们测试基准为200B和500B。

3.1.2 Consumer相关

Consumer为kafka的消费者,同一个topic消费者越多越快,但是需要注意的是,消费者的数量不能超过topic的分区数量,因为每个topic的每个分区只能被一个消费者消费,多出来的消费者会无信息可消费。导致资源浪费。

3.2 测试命令详解

1、创建topic命令

    # ./kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test -7

--replication-factor:指定副本个数
--partitions:指定分区个数
--topic:指定topic名

2、查看topic命令

    # ./kafka-topics.sh --zookeeper 10.10.4.11:2181 --list

3、查看指定topic的详细内容

    # ./kafka-topics.sh --zookeeper 10.10.4.11:2181 --topic test_property --describe

5、 写入数据

    # ./kafka-producer-perf-test.sh --num-records 10000000 --topic test-ref-9 --record-size 500 --throughput 100000 --producer-props bootstrap.servers=10.10.4.11:9092,10.10.4.12:9092,10.10.4.13:9092

--num-records:记录的条数
--topic:指定topic的名字
--record-size:一条记录大小。
--throughput:吞吐数量
--producer-props bootstrap.servers=IP:9092,IP:9092,IP:9092:指定kafka集群

注意:-- throughput参数为写入数量,如果结果接近此数量,建议*10再测试一次。因为和此结果相近说明kafka没有到达瓶颈。

6、消费数据

    # ./kafka-consumer-perf-test.sh --messages 10000000 --threads 3 --zookeeper localhost:2181 --num-fetch-threads 3 --topic test-ref-8

--messages:指定消费条目数
--threads:指定线程数
--num-fetch-threads 3:指定消费人数

注意:执行以上命令在kafka****家目录下的/bin****下执行命令

4 Kafka写入性能测试

在测试kafka写入性能测试的时候一边检测系统的cpu使用情况、内存使用情况和磁盘IO情况。

4.1 测试kafka的partition参数

4.1.1 创建不同partition的topic并写入数据1000万条数据。

1、 创建一个副本,partition分别为1、3、6、12的topic分别为test-0、test-1、test-2、test-3

2、 向topic内写入1000万条500B的数据,一次写入100万条,replication为1。并且开启另一个窗口使用iostat命令实时监控磁盘IO情况。

4.1.2 测试结果

1、写入数据如下表

3、 磁盘IO情况

由于磁盘IO瓶颈在94.8 MB/秒得出的数据只有partition为1的情况下在60MB/秒。所以大多数情况下%util处于一个100%的状态。在partition为1的情况下是隔两秒会出现%util值为100%。


4.2 kafka的partition参数总结

由于压力测试没有到达kafka的瓶颈,而是到达了服务器的瓶颈。所以以上数据仅供参考。如想测试更准确的数据。需要性能更好的磁盘来做测试。

在其他数据相同,而partition不同的时候。结论是partition越多写入速度越快。但是partition数量越多会照成kafka集群可用性越差。所以建议,在实际生产环境。有多少个broker,partition数就为多少。这样可以保证kafka集群的高可用性。可以保证n-1/2个节点宕机而不影响kafka集群使用。

4.3 测试Kafka的replication参数

4.3.1 创建不同replication的topic并写入数据1000万条数据。

1、创建一个副本,replication分别为2和3的topic为test-4、test-5。和之前创建的test-1。一起做测试

2、向topic内写入1000万条500B的数据,一次写入100万条,partition为3(因为我的broker是3个)。并且开启另一个窗口使用iostat命令实时监控磁盘IO情况。

4.3.2 测试结果

1、写入数据如下表

2、磁盘IO情况

由于磁盘IO瓶颈在94.8 MB/秒得出的数据只有replication为3的情况下在70MB/秒。所以大多数情况下%util处于一个100%的状态。在replication为3的情况下也是一直%util值为100%。


4.4 kafka的replication参数总结

由于压力测试没有到达kafka的瓶颈,而是到达了服务器的瓶颈。所以以上数据仅供参考。如想测试更准确的数据。需要性能更好的磁盘来做测试。

在其他数据相同,而replication不同的时候。结论是replication越少写入速度越快。但是replication数量越少会照成kafka集群可用性越差。所以建议,在实际生产环境。Kafka集群broker为3的时候replication为1,可以保证一台节点宕机集群可用。其他架构需继续深入研究。

4.5 测试Kafka的network.thread参数

1、 修改配置文件network.thread的参数为1,重启kafka进行对test-1进行写入测试。

2、 和之前test-1的数据进行对比。

4.5.1 测试结果

1、写入数据如下


2、磁盘IO情况


磁盘已经到达瓶颈。

4.6 Kafka的network.thread参数总结

从结果可看出kafka的network.thread参数越多写入速度越快。但是增加的非常不明显。除非写入速度要求极高的情况,或者机器性能足够好。其他情况建议使用默认值3即可。

4.7 测试kafka的单条数据大小参数

1、 修改命令--record-size参数。

2、 同往test-1里写入进行测试

4.7.1 测试结果

1、写入数据如下


2、磁盘IO情况


磁盘已经到达瓶颈。

4.8 Kafka的单条数据大小参数总结

从结果显示证明如果写入kafka的数据量单条越小,传输速度越快。正常我们的日志大约在300B每条,最大为500B每条。所以我们按照最大的数据量进行传输来测试写入量。

5 Kafka写入数据测试整体总结

在kafka写入数据的时候,主要参数在于partition的数量、replication的数量及单条数据的大小。对于线程数对写入速度并不是特别影响。在测试的时候观察cpu使用情况和内存使用情况。Kafka在有写入的时候对于本身的内存要求不大,jvm设置为1G就可以,但是kafka机制是kafka先写入系统页缓存内,所以需要的内存比较大。不建议和使用内存较大的应用部署在一台机器上,如elasticsearch。如果服务器内存较大,建议kafka使用4G左右jvm。Kafka对cpu要求不是特别大。一般两核以上就可以。

6 Kafka读取性能测试

在测试kafka读取性能测试的时候一边检测系统的cpu使用情况、内存使用情况和磁盘IO情况。

注意事项:写入数据后等一段时间再进行测试,因为可能有些数据还在内存中,所以看不出磁盘IO的瓶颈。

6.1 测试kafka的partition参数

1、由于之前已经写入1000万数据,可以直接在test-0、test-1、test-2、test-3的topic 并且Consumer为3、线程为3。直接读取这些数据进行测试。

6.1.1 测试结果

1、读取数据如下表

2、磁盘IO情况

磁盘IO有时会到达瓶颈,但是次数不多。


6.2 Kafka的partition参数总结

压测结果证明partition越多速度越快,实际情况我们建议和之前一样。有多少个broker,partition数就为多少。这样可以保证kafka集群的高可用性。可以保证n-1/2个节点宕机而不影响kafka集群使用。详细情况kafka写入测试的partition总结。

6.3 测试Kafka的consumer参数

以test1为测试topic。分别使用1、3、6个consumer来进行读取测试。

6.3.1 测试结果

1、写入数据如下表


2、磁盘IO情况

磁盘IO有时会到达瓶颈,但是次数不多。


3、 使用软件KafkaOffsetMonitor监控不同consumer的滞留情况lag为滞留信息条目数

(1)一个consumer三个partition


(2)三个consumer三个partition


(3)三个consumer六个partition


6.4 kafka的consumer参数总结

从测试结果可以看出,consumer这个参数不是越多越好,而是和topic的partition相同时性能最优,如果consumer大于partition的时候,测试开始会报错,内容大意为,有xx个consumer是没有分区可以消费的。这个参数可以根据项目本身去定义。但是不要超过topic的partition数目。但是consumer少会有消息滞留现象。

6.5 测试Kafka的线程参数

通过test-1 topic进行测试。

6.5.1 测试结果

1、 写入数据如下表


2、 磁盘IO


6.6 kafka的线程参数总结

从测试结果来看线程数并不影响kafka的写入速度。

7 Kafka读取性能总结

Kafka写入性能主要在于partition参数和consumer参数。Partition参数和的具体值可以直接参考写入性能总结,这里不再赘述。Consumer的性能测试来看,只要不多于partition的数量都是可以的。如果broker的数量比较多,建议多设置几个。

Kafka读取对于replication无关,因为replication不参与读取,只做容灾备份的。对线程数也没那么大的关系。

读取数据对cpu负载不是特别高,2核以上够用,如果是实时读取数据,对磁盘来说性能要求并不高,因为短时间内,一些数据都是在内存里可以直接取到的。

8 Kafka整体性能总结

对于ELK集群来说,整体性能还是比较好的,一般影响测试结果都是磁盘的瓶颈造成的。对于磁盘来说用SATA磁盘就可以,因为kafka的写入读取机制都是顺序写入、读取的。SATA顺序读写速度大约在53MB/s和SSD的顺序读取都是差不多的。如果做RAID建议做RAID5。

Kafka对于CPU和内存要求不是特别大,一般CPU建议在8核以上,内存建议在8G以上。如果服务器性能好kafka的jvm建议设置4G。

Kafka在我的测试环境下,broker为3的集群情况下。Replication参数为1,partition参数为3,线程数为3,consumer数为3,输入读取的文件大小为500B。整体kafka的写入速度为242665条/秒,传输大小为115.71 MB/秒。读取速度为241390条/秒,传输大小为115MB/秒。

但是以上数据几乎都是遇到了磁盘IO的瓶颈,数据不是特别准确,希望可以有更好的环境,对kafka进行更全面的测试。

最后没有贴上整体数据

你可能感兴趣的:(kafka压力测试说明书(九) - 简书)