Kafka参数影响及性能测试_tom_fans的博客-CSDN博客

标签: | 发表时间:2020-02-02 11:55 | 作者:
出处:https://blog.csdn.net

Kafka提供了2个测试脚本,kafka-producer-perf-test.sh以及kafka-consumer-perf-test.sh,  kafka参数非常多,有些使用默认即可,有些对性能影响极大,只有经过测试,你才能够对这些参数有直观的感觉。 下面我们先测试producer.

先看看producer脚本怎么使用:

      [hdfs@namenode02 tmp]$  /opt/cloudera/parcels/KAFKA/lib/kafka/bin/kafka-producer-perf-test.sh
usage: producer-performance [-h] --topic TOPIC --num-records NUM-RECORDS --record-size RECORD-SIZE --throughput THROUGHPUT
                            --producer-props PROP-NAME=PROP-VALUE [PROP-NAME=PROP-VALUE ...]

This tool is used to verify the producer performance.

optional arguments:
  -h, --help             show this help message and exit
  --topic TOPIC          produce messages to this topic
  --num-records NUM-RECORDS
                         number of messages to produce
  --record-size RECORD-SIZE
                         message size in bytes
  --throughput THROUGHPUT
                         throttle maximum message throughput to *approximately* THROUGHPUT messages/sec
  --producer-props PROP-NAME=PROP-VALUE [PROP-NAME=PROP-VALUE ...]
                         kafka producer related configuaration properties like bootstrap.servers,client.id etc..
[hdfs@namenode02 tmp]$

默认测试命令如下, 发送100000条记录,每个记录100 bytes

      /opt/cloudera/parcels/KAFKA/lib/kafka/bin/kafka-producer-perf-test.sh --topic jlwang --num-records 1000000 --record-size 100 --producer-props  bootstrap.servers=datanode04.isesol.com:9092 --throughput 1000000

由于默认参数没有去做修改,那么主要的几个参数如下:

buffer.memory = 33554432              这个就是消息缓存,producer发消息默认先发给buffer

block.on.buffer.full = false                如果发送的消息量太大,撑满了buffer怎么办? 我相信kafka会有清理 buffer的功能,但是如果即使清理也赶不到发送速度呢? 这个参数的

                                                              意义就是如果出现这个情况,是堵塞发送,还是报错?

request.timeout.ms = 30000

acks = 1

retries = 0

max.request.size = 1048576

linger.ms = 0                                    

batch.size = 16384

接下来我们主要测试 batch, buffer, ack, linger.ms的影响。


默认:

1000000 records sent, 288184.438040 records/sec (27.48 MB/sec), 574.34 ms avg latency, 918.00 ms max

acks=all :

1000000 records sent, 121212.121212 records/sec (11.56 MB/sec), 1566.87 ms avg latency, 2640.00 ms max latency

acks=all, linger.ms=100ms :

1000000 records sent, 128188.693757 records/sec (12.23 MB/sec), 1506.37 ms avg latency, 1960.00 ms max latency

buffer.memory=100000 :

1000000 records sent, 66427.527567 records/sec (6.34 MB/sec), 1.06 ms avg latency, 307.00 ms max latency

batch.size=1, acks=1 :

16669 records sent, 3333.8 records/sec (0.32 MB/sec), 2587.5 ms avg latency, 4303.0 max latency.

随后报错:org.apache.kafka.common.errors.TimeoutException: Batch Expired   生产的数据速度远远超过发送速度,导致失败timeout,然后失败。


其实已经不用测了,上面这几个参数对整个发送性能都有相当大的影响, 如果发送量很大,可以考虑增加buffer, batch.size, linger.ms的值,acks设置为1.  至于设置多大,坦白说我觉得给个double就行了,也不需要太大。 如果发送量不大,其实默认值kafka给的很不错,可以应付大部分系统。

另外要提一点record.size也严重影响发送速度,生产上尽量避免太大的record.size, 看下面测试结果,我设置record.size=10000,速度严重不行

24499 records sent, 4899.8 records/sec (46.73 MB/sec), 364.1 ms avg latency, 748.0 max latency.
28500 records sent, 5700.0 records/sec (54.36 MB/sec), 346.4 ms avg latency, 742.0 max latency.
28134 records sent, 5626.8 records/sec (53.66 MB/sec), 363.0 ms avg latency, 806.0 max latency.
28037 records sent, 5607.4 records/sec (53.48 MB/sec), 362.7 ms avg latency, 821.0 max latency.
23201 records sent, 4640.2 records/sec (44.25 MB/sec), 429.9 ms avg latency, 1088.0 max latency.
17055 records sent, 3411.0 records/sec (32.53 MB/sec), 605.7 ms avg latency, 1361.0 max latency.
21415 records sent, 4283.0 records/sec (40.85 MB/sec), 490.0 ms avg latency, 1019.0 max latency.
26560 records sent, 5312.0 records/sec (50.66 MB/sec), 383.6 ms avg latency, 853.0 max latency.
23193 records sent, 4638.6 records/sec (44.24 MB/sec), 446.7 ms avg latency, 1225.0 max latency.
26156 records sent, 5231.2 records/sec (49.89 MB/sec), 387.6 ms avg latency, 1068.0 max latency.
28024 records sent, 5604.8 records/sec (53.45 MB/sec), 372.2 ms avg latency, 855.0 max latency.
27209 records sent, 5441.8 records/sec (51.90 MB/sec), 377.0 ms avg latency, 842.0 max latency.


对于consumer就不做具体测试了,主要是因为影响参数没那么多,receive.buffer.bytes,auto.offset.reset,max.partition.fetch.bytes,fetch.min.bytes,isolation.level,max.poll.interval.ms,receive.buffer.bytes,request.timeout.ms  

估计真正会设置的几个参数也就这个,其他基本都不太用。





相关 [kafka 参数 性能] 推荐:

Kafka参数影响及性能测试_tom_fans的博客-CSDN博客

- -
Kafka提供了2个测试脚本,kafka-producer-perf-test.sh以及kafka-consumer-perf-test.sh,  kafka参数非常多,有些使用默认即可,有些对性能影响极大,只有经过测试,你才能够对这些参数有直观的感觉. 下面我们先测试producer.. 先看看producer脚本怎么使用:.

高性能消息系统——Kafka

- - 互联网 - ITeye博客
引用官方原文: “Kafka is a distributed, partitioned, replicated commit log service.”. 它提供了一个非常特殊的消息机制,不同于传统的mq. 官网:https://kafka.apache.org.     传统的MQ,消息被消化掉后会被mq删除,而kafka中消息被消化后不会被删除,而是到配置的expire时间后,才删除.

kafka监控之kafka-run-class.sh

- - 开源软件 - ITeye博客
kafka自带了很多工具类,在源码kafka.tools里可以看到:. 这些类该如何使用呢,kafka的设计者早就为我们考虑到了,在${KAFKA_HOME}/bin下,有很多的脚本,其中有一个kafka-run-class.sh,通过这个脚本,可以调用其中的tools的部分功能,如调用kafka.tools里的ConsumerOffsetChecker.scala,.

闲扯kafka mq

- - 开源软件 - ITeye博客
本文主要讲解关于kafka mq的设计思想及个人理解. 关于kafka的详细信息,大家可以参考官网的文献 http://kafka.apache.org/documentation.html这是一篇相当不错的文章,值得仔细研读. 第一个问题:消息队列(Message Queue)是干嘛用的. 首先,要对消息队列有一个基本的理解.

Kafka优化

- - ITeye博客
配置优化都是修改server.properties文件中参数值. 1.网络和io操作线程配置优化. # broker处理消息的最大线程数. # broker处理磁盘IO的线程数. 一般num.network.threads主要处理网络io,读写缓冲区数据,基本没有io等待,配置线程数量为cpu核数加1.

Kafka Connect简介

- - 鸟窝
Kafka 0.9+增加了一个新的特性 Kafka Connect,可以更方便的创建和管理数据流管道. 它为Kafka和其它系统创建规模可扩展的、可信赖的流数据提供了一个简单的模型,通过 connectors可以将大数据从其它系统导入到Kafka中,也可以从Kafka中导出到其它系统. Kafka Connect可以将完整的数据库注入到Kafka的Topic中,或者将服务器的系统监控指标注入到Kafka,然后像正常的Kafka流处理机制一样进行数据流处理.

kafka consumer group offset

- - 开源软件 - ITeye博客
     kafka0.9及以前版本kafka offset 保存在zookeeper, 因频繁读写zookeeper性能不高;从0.10开始,主题分区offset存储于kafka独立主题中.     管理监控kafka主题及分区offset至关重要,原网上很开源流行工具KafkaOffsetMonitor、kafka-manager,旧版offset保存于zookeeper,kafka consumer无相应API,从kafka0.10.1.1以后提供相应API读取主题分区offset(也可以调用KafkaClient API,kafka管理API由scala语言编写).

Kafka跨集群迁移方案MirrorMaker原理、使用以及性能调优实践 - CSDN博客

- -
Kakfa MirrorMaker是Kafka 官方提供的跨数据中心的流数据同步方案. 其实现原理,其实就是通过从Source Cluster消费消息然后将消息生产到Target Cluster,即普通的消息生产和消费. 用户只要通过简单的consumer配置和producer配置,然后启动Mirror,就可以实现准实时的数据同步.

Kafka跨数据中心迁移方案MirrorMaker使用及性能调优实践 | 网易乐得技术团队

- -
Kakfa MirrorMaker是Kafka 官方提供的跨数据中心的流数据同步方案. 其实现原理,其实就是通过从Source Cluster消费消息然后将消息生产到Target Cluster,即普通的消息生产和消费. 用户只要通过简单的consumer配置和producer配置,然后启动Mirror,就可以实现准实时的数据同步.

Kafka设计解析(二):Kafka High Availability (上)

- -
Kafka在0.8以前的版本中,并不提供High Availablity机制,一旦一个或多个Broker宕机,则宕机期间其上所有Partition都无法继续提供服务. 若该Broker永远不能再恢复,亦或磁盘故障,则其上数据将丢失. 而Kafka的设计目标之一即是提供数据持久化,同时对于分布式系统来说,尤其当集群规模上升到一定程度后,一台或者多台机器宕机的可能性大大提高,对Failover要求非常高.