Kafka性能优化及性能测试
目的:
充分发挥kafka在低时延,高吞吐等不同场景下的优势。
参数配置:
1)提升吞吐量
2)保证低时延
3)保证高持久
4)相关参数设置说明
1、内存缓冲的大小:buffer.memory
Kafka的客户端发送数据到服务器,一般都是要经过缓冲的,也就是说,你通过KafkaProducer发送出去的消息都是先进入到客户端本地的内存缓冲里,然后把很多消息收集成一个一个的Batch,再发送到Broker上去的。所以这个“buffer.memory”的本质就是用来约束KafkaProducer能够使用的内存缓冲的大小的,他的默认值是32MB。那么既然了解了这个含义,大家想一下,在生产项目里,这个参数应该怎么来设置呢?你可以先想一下,如果这个内存缓冲设置的过小的话,可能会导致一个什么问题?首先要明确一点,那就是在内存缓冲里大量的消息会缓冲在里面,形成一个一个的Batch,每个Batch里包含多条消息。然后KafkaProducer有一个Sender线程会把多个Batch打包成一个Request发送到Kafka服务器上去。
内存缓冲区设置太小可能导致一个问题:消息快速的写入内存缓冲里面,但是Sender线程来不及把Request发送到Kafka服务器。这样是不是会造成内存缓冲很快就被写满?一旦被写满,就会阻塞用户线程,不让继续往Kafka写消息了。所以对于“buffer.memory”这个参数应该结合自己的实际情况来进行压测,你需要测算一下在生产环境,你的用户线程会以每秒多少消息的频率来写入内存缓冲。比如说每秒300条消息,那么你就需要压测一下,假设内存缓冲就32MB,每秒写300条消息到内存缓冲,是否会经常把内存缓冲写满?经过这样的压测,你可以调试出来一个合理的内存大小。
2、多少数据打包为一个Batch合适:batch.size
这个东西是决定了你的每个Batch要存放多少数据就可以发送出去了。比如说你要是给一个Batch设置成是16KB的大小,那么里面凑够16KB的数据就可以发送了。这个参数的默认值是16KB,一般可以尝试把这个参数调节大一些,然后利用自己的生产环境发消息的负载来测试一下。比如说发送消息的频率就是每秒300条,那么如果比如“batch.size”调节到了32KB,或者64KB,是否可以提升发送消息的整体吞吐量。因为理论上来说,提升batch的大小,可以允许更多的数据缓冲在里面,那么一次Request发送出去的数据量就更多了,这样吞吐量可能会有所提升。但是这个东西也不能无限的大,过于大了之后,要是数据老是缓冲在Batch里迟迟不发送出去,那么岂不是你发送消息的延迟就会很高。比如说,一条消息进入了Batch,但是要等待5秒钟Batch才凑满了64KB,才能发送出去。那这条消息的延迟就是5秒钟。所以需要在这里按照生产环境的发消息的速率,调节不同的Batch大小自己测试一下最终出去的吞吐量以及消息的 延迟,设置一个最合理的参数。
3、要是一个Batch迟迟无法凑满怎么办:linger.ms
要是一个Batch迟迟无法凑满,此时就需要引入另外一个参数了,“linger.ms”,他的含义就是说一个Batch被创建之后,最多过多久,不管这个Batch有没有写满,都必须发送出去了。
给大家举个例子,比如说batch.size是16kb,但是现在某个低峰时间段,发送消息很慢。这就导致可能Batch被创建之后,陆陆续续有消息进来,但是迟迟无法凑够16KB,难道此时就一直等着吗?当然不是,假设你现在设置“linger.ms”是50ms,那么只要这个Batch从创建开始到现在已经过了50ms了,哪怕他还没满16KB,也要发送他出去了。所以“linger.ms”决定了你的消息一旦写入一个Batch,最多等待这么多时间,他一定会跟着Batch一起发送出去。避免一个Batch迟迟凑不满,导致消息一直积压在内存里发送不出去的情况。这是一个很关键的参数。这个参数一般要非常慎重的来设置,要配合batch.size一起来设置。举个例子,首先假设你的Batch是32KB,那么你得估算一下,正常情况下,一般多久会凑够一个Batch,比如正常来说可能20ms就会凑够一个Batch。那么你的linger.ms就可以设置为25ms,也就是说,正常来说,大部分的Batch在20ms内都会凑满,但是你的linger.ms可以保证,哪怕遇到低峰时期,20ms凑不满一个Batch,还是会在25ms之后强制Batch发送出去。如果要是你把linger.ms设置的太小了,比如说默认就是0ms,或者你设置个5ms,那可能导致你的Batch虽然设置了32KB,但是经常是还没凑够32KB的数据,5ms之后就直接强制Batch发送出去,这样也不太好其实,会导致你的Batch形同虚设,一直凑不满数据。
4、最大请求大小 :“max.request.size”
这个参数决定了每次发送给Kafka服务器请求的最大大小,同时也会限制你一条消息的最大大小也不能超过这个参数设置的值,这个其实可以根据你自己的消息的大小来灵活的调整。给大家举个例子,你们公司发送的消息都是那种大的报文消息,每条消息都是很多的数据,一条消息可能都要20KB。此时你的batch.size是不是就需要调节大一些?比如设置个512KB?然后你的buffer.memory是不是要给的大一些?比如设置个128MB?只有这样,才能让你在大消息的场景下,还能使用Batch打包多条消息的机制。但是此时“max.request.size”是不是也得同步增加?
5、重试机制:“retries”和“retries.backoff.ms”
“retries”和“retries.backoff.ms”决定了重试机制,也就是如果一个请求失败了可以重试几次,每次重试的间隔是多少毫秒。
这个大家适当设置几次重试的机会,给一定的重试间隔即可,比如给100ms的重试间隔。
6、确认机制:acks
此配置是表明当一次produce请求被认为完成时的确认值。特别是,多少个其他brokers必须已经提交了数据到他们的log并且向他们的leader确认了这些信息。典型的值包括:
0: 表示producer从来不等待来自broker的确认信息(和0.7一样的行为)。这个选择提供了最小的时延但同时风险最大(因为当server宕机时,数据将会丢失)。
1:表示获得leader replica已经接收了数据的确认信息。这个选择时延较小同时确保了server确认接收成功。
-1:producer会获得所有同步replicas都收到数据的确认。同时时延最大,然而,这种方式并没有完全消除丢失消息的风险,因为同步replicas的数量可能是1。如果你想确保某些replicas接收到数据,那么你应该在topic-level设置中选项min.insync.replicas设置一下。
7、min.insync.replicas:
当生产者设置应答为"all"(或“-1”)时,此配置指定了成功写入的副本应答的最小数。如果没满足此最小数,则生产者将引发异常(NotEnoughReplicas或NotEnoughReplicasAfterAppend)
当min.insync.replicas和acks强制更大的耐用性时。典型的情况是创建一个副本为3的topic,将min.insync.replicas设置为2,并设置acks为“all”。如果多数副本没有收到写入,这将确保生产者引发异常。
8、压缩compression.type:
压缩的速度上lz4=snappy<gzip
9、日志保留策略配置
当kafka server的被写入海量消息后,会生成很多数据文件,且占用大量磁盘空间,如果不及时清理,可能磁盘空间不够用,kafka默认是保留7天。
优化建议:
减少日志保留时间,建议三天或则更多时间。log.retention.hours=72
此外,segment段文件配置1GB,有利于快速回收磁盘空间,重启kafka加载也会加快(如果文件过小,则文件数量比较多,kafka启动时是单线程扫描目录(log.dir)下所有数据文件),文件较多时性能会稍微降低。log.segment.bytes=1073741824
10、log数据文件刷盘策略
为了大幅度提高producer写入吞吐量,需要定期批量写文件
优化建议:
每当producer写入10000条消息时,刷数据到磁盘。log.flush.interval.messages=10000
每间隔1秒钟时间,刷数据到磁盘。log.flush.interval.ms=1000
Producer程序优化示例
虚拟机测试环境:
props.put("bootstrap.servers", props.getProperty("kafka.cluster"));
props.put("retries", 0);
props.put("batch.size", 204800);
props.put("linger.ms", 100);
props.put("buffer.memory", 67108864);
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("acks", "0");
props.put("request.timeout.ms", "60000");
props.put("compression.type","lz4");
实际生产环境可参考:
https://my.oschina.net/objcoding/blog/4600179
优化前后对比:
以下优化对比在虚拟机测试环境中进行:
1)优化前:
[root@node02 kafka_2.11-0.10.2.2]# ./bin/kafka-producer-perf-test.sh --topic emq --throughput 100000 --num-records 100000 --producer-props bootstrap.servers=192.168.72.141:9092 --record-size 1000
18224 records sent, 3640.4 records/sec (3.47 MB/sec), 2304.1 ms avg latency, 4117.0 max latency.
38385 records sent, 7677.0 records/sec (7.32 MB/sec), 4753.8 ms avg latency, 5970.0 max latency.
100000 records sent, 7538.635507 records/sec (7.19 MB/sec), 3486.82 ms avg latency, 5970.00 ms max latency, 3541 ms 50th, 5523 ms 95th, 5739 ms 99th, 5957 ms 99.9th.
2)优化后:
## ack为0
[root@node02 kafka_2.11-0.10.2.2]# ./bin/kafka-producer-perf-test.sh --topic emq --throughput 100000 --num-records 100000 --producer-props bootstrap.servers=192.168.72.141:9092 acks=0 compression.type=lz4 batch.size=204800 linger.ms=100 retries=0 buffer.memory=67108864 --record-size 1000
100000 records sent, 77160.493827 records/sec (73.59 MB/sec), 44.78 ms avg latency, 261.00 ms max latency, 42 ms 50th, 96 ms 95th, 111 ms 99th, 128 ms 99.9th.## ack为1
[root@node02 kafka_2.11-0.10.2.2]# ./bin/kafka-producer-perf-test.sh --topic emq --throughput 100000 --num-records 100000 --producer-props bootstrap.servers=192.168.72.141:9092 acks=1 compression.type=lz4 batch.size=204800 linger.ms=100 retries=0 buffer.memory=67108864 --record-size 1000
100000 records sent, 79365.079365 records/sec (75.69 MB/sec), 59.57 ms avg latency, 251.00 ms max latency, 52 ms 50th, 124 ms 95th, 179 ms 99th, 195 ms 99.9th.
优化后吞吐量显著提升,延迟也下降明显。
Kafka性能优化及性能测试相关推荐
- SQL性能优化以及性能测试
SQL性能优化以及性能测试 博主介绍 笛卡尔连接 分页limit的sql优化的几种方法
- 前端性能优化之性能测试
前端性能优化是一个很宽泛的概念,有很多教程都有前端性能优化的方法,这也是我们一直在关注的一件重要事情.配合各种方式.手段.辅助系统,前端优化的最终目的都是提升用户体验,改善页面性能,我们常常竭尽全力进 ...
- kafka性能优化入门
当我们谈论 Kafka 性能调优时,需要考虑很少的配置参数.因此,为了提高性能,最重要的配置是控制磁盘刷新速率的配置. 此外,我们可以根据组件划分这些配置.因此,让我们先谈谈Producer.因此,在 ...
- Kafka 性能调优实战:同等资源配置性能提升 20 几倍的秘诀
作者 | 丁威 责编 | 欧阳姝黎 抛出问题 笔者最近在折腾数据异构体系,在实现MySQL增量数据同步到MQ(Kafka.RocketMQ),本文的故事就从这里开始. 众所周知,为了提高写 ...
- 跨境茶话会8月期丨性能优化的艺术
大师兄说 众所周知,对于现在国内的互联网环境,不管什么样的系统,一旦等用户的访问量上去之后,我们每增加一个功能实际上都是要考虑它的吞吐量和延迟,在加工上都是要做一个缜密的思考的.所以我相信在这方面许多 ...
- Kafka性能篇:为何Kafka这么快?
『码哥』的 Redis 系列文章有一篇讲透了 Redis 的性能优化 --<Redis 核心篇:唯快不破的秘密>.深入地从 IO.线程.数据结构.编码等方面剖析了 Redis " ...
- 网站性能优化有哪些方法
网站性能优化有哪些方法 一.总结 一句话总结: web前端性能优化:浏览器访问优化.CDN加速.反向代理 应用服务器性能优化:分布式缓存.异步操作.使用集群.代码优化 web前端性能优化方法有哪些 1 ...
- 漫游Kafka设计篇之性能优化(7)
Kafka在提高效率方面做了很大努力.Kafka的一个主要使用场景是处理网站活动日志,吞吐量是非常大的,每个页面都会产生好多次写操作.读方面,假设每个消息只被消费一次,读的量的也是很大的,Kafka也 ...
- 漫游Kafka设计篇之性能优化
原文地址:http://blog.csdn.net/honglei915/article/details/37564757 Kafka视频教程同步首发,欢迎观看! Kafka在提高效率方面做了很大努力 ...
最新文章
- JavaScript中函数作为另一个函数的参数的时候它存在于哪个作用域
- jquery判断多选框是否选中
- C语言内存泄露很严重该怎么办?这几招告诉你
- 从mysql读取数据保存成excel_小程序读取excel表格数据,并存储到云数据库
- 洛谷P2622 关灯问题II【状压dp+bfs】
- 北京人工智能工程师职称评定政策出台,明年起一年一评
- react和angualr动态插入带html标签或不带html标签的数据
- es6.0 java,es6.0.0源码idea启动问题
- c# winform中datagridview空间添加序号和表头“序号”
- Webbrowser若干点
- 机器人控制学习机器编程代码_带上机器人,让他们维护我们的代码!
- 【100%通过率】华为OD机试真题 Java 实现【处理器问题/ 高性能AI处理器】【2022.11 Q4 新题】
- php将文本文件中的内容呈现到一个表格中
- Servlet的监听器实现在线人数统计
- 计算机报名没有有效的安全证书,win10 因为没有使用有效的安全证书进行签名怎么解决...
- 【课设分享】基于51单片机的恒温控制器系统
- 信息无障碍相关会议网址链接
- linux的chmod与chown
- OpenCV4中读取摄像头参数YAML文件(C++和C#)
- java实现第二届蓝桥杯四方定理