IT评测·应用市场-qidao123.com

标题: 【Kafka系列 04】Kafka 性能调优,怎么做? [打印本页]

作者: 西河刘卡车医    时间: 2024-7-22 18:32
标题: 【Kafka系列 04】Kafka 性能调优,怎么做?
1. 调优目的

通常来说,调优是为了满意系统常见的非功能性需求。在浩繁的非功能性需求中,性能绝对是我们最关心的那一个。不同的系统对性能有不同的诉求,比如对于数据库用户而言,性能意味着请求的响应时间,用户总是希望查询或更新请求能够被更快地处置惩罚完并返回。
对 Kafka 而言,性能一样平常是指吞吐量延时
吞吐量,即TPS,是指 Broker 端进程或 Client 端应用程序每秒能处置惩罚的字节数或消息数,这个值天然是越大越好。
延时,与雷同响应时间,它表现从 Producer 端发送消息到 Broker 端持久化完成之间的时间隔断。这个指标也可以代表端到端的延时(End-to-End,E2E),也就是从 Producer 发送消息到 Consumer 成功消耗该消息的总时长。和 TPS 相反,我们通常希望延时越短越好。
总之,高吞吐量、低延时是调优 Kafka 集群的主要目的。
2. 优化漏斗

优化漏斗是一个调优过程中的分层漏斗,我们可以在每一层上实行相应的优化调解。总体来说,层级越靠上,其调优的效果越明显,整体优化效果是自上而下衰减的,如下图所示:

 第 1 层:应用程序层。它是指优化 Kafka 客户端应用程序代码。这一层的优化效果最为明显,通常也是比较简单的。
第 2 层:框架层。它指的是公道设置 Kafka 集群的各种参数。毕竟,直接修改 Kafka 源码进行调优并不容易,但根据实际场景恰本地设置关键参数的值,还是很容易实现的。
第 3 层:JVM 层。Kafka Broker 进程是普通的 JVM 进程,各种对 JVM 的优化在这里也是实用的。优化这一层的效果固然比不上前两层,但偶然也能带来巨大的改善效果。
第 4 层:操作系统层。对操作系统层的优化很重要,但效果往往不如想象得那么好。与应用程序层的优化效果相比,它是有很大差距的。
3. 底子性调优

3.1 操作系统调优


3.2 JVM 层调优


3.3 Brocker 端调优

Broker 端的调优原则:努力保持客户端版本和 Broker 端版本一致。版本不一致会令 Kafka 丧失很多性能收益,比如 Zero Copy。下面用一张图来说明一下。

图中蓝色的 Producer、Consumer 和 Broker 的版本是相同的,它们之间的通信可以享受 Zero Copy 的快速通道;相反,一个低版本的 Consumer 程序想要与 Producer、Broker 交互的话,就只能依赖 JVM 堆中转一下,丢掉了快捷通道,就只能走慢速通道了。因此,在优化 Broker 这一层时,你只要保持服务器端和客户端版本的一致,就能获得很多性能收益了。
3.4 应用层调优


4. 性能指标调优

4.1 调优吞吐量


在 Broker 端,参数 num.replica.fetchers 表现的是 Follower 副本用多少个线程来拉取消息,默认使用 1 个线程。如果你的 Broker 端 CPU 资源很富足,不妨得当调大该参数值,加快 Follower 副本的同步速率。由于在实际生产情况中,设置了 acks=all 的 Producer 程序吞吐量被拖累的主要因素,就是副本同步性能。增长这个值后,你通常可以看到 Producer 端程序的吞吐量增长。
在 Producer 端,要改善吞吐量,通常的标配是增长消息批次的巨细以及批次缓存时间,即 batch.size 和 linger.ms。它们的默认值都偏小,特别是默认的 16KB 的消息批次巨细一样平常都不实用于生产情况。假设你的消息体巨细是 1KB,默认一个消息批次也就约莫 16 条消息,显然太小了。
除了这两个,你最好把压缩算法也设置上,以减少网络 I/O 传输量,从而间接提拔吞吐量。当前,和 Kafka 适配最好的两个压缩算法是 LZ4 和 zstd,不妨一试。
同时,由于我们的优化目的是吞吐量,最好不要设置 acks=all 以及开启重试。前者引入的副本同步时间通常都是吞吐量的瓶颈,而后者在实行过程中也会拉低 Producer 应用的吞吐量。
末了,如果你在多个线程中共享一个 Producer 实例,就可能会碰到缓冲区不够用的情况。倘若频繁地遭遇 TimeoutException:Failed to allocate memory within the configured max blocking time 如许的非常,那么你就必须显式地增长 buffer.memory 参数值,确保缓冲区总是有空间可以申请的。
在 Consumer 端,提拔吞吐量的本领是有限的,你可以利用多线程方案增长整体吞吐量,也可以增长 fetch.min.bytes 参数值。默认是 1 字节,表现只要 Kafka Broker 端积攒了 1 字节的数据,就可以返回给 Consumer 端。
4.2 调优延时


在 Broker 端,可以增长 num.replica.fetchers 值以加快 Follower 副本的拉取速率,减少整个消息处置惩罚的延时。
在 Producer 端,消息尽快地被发送出去,所以必须设置 linger.ms=0,同时不要启用压缩。由于压缩操作自己要消耗 CPU 时间,会增长消息发送的延时。另外,最好不要设置 acks=all。我们刚刚在前面说过,Follower 副本同步往往是降低 Producer 端吞吐量和增长延时的主要原因。
在 Consumer 端,保持 fetch.min.bytes=1 即可,也就是说,只要 Broker 端有能返回的数据,立刻令其返回给 Consumer,紧缩 Consumer 消耗延时。
5. 小结

分享一个性能调优的真实小案例。
曾经,我碰到过一个线上情况的标题:该集群上 Consumer 程序一直表现精良,但是某一天,它的性能突然下降,表现为吞吐量显著降低。我在检察磁盘读 I/O 使用率时,发现其明显上升,但之前该 Consumer Lag 很低,消息读取应该都能直接命中页缓存。此时磁盘读突然飙升,我就怀疑有其他程序写入了页缓存。后来颠末排查,我发现果然有一个测试 Console Consumer 程序启动,“污染”了部门页缓存,导致主业务 Consumer 读取消息不得不走物理磁盘,因此吞吐量下降。找到了真实原因,解决起来就简单多了。
末了,总结下如何调优Kafka。


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。




欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/) Powered by Discuz! X3.4