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 操作系统调优

禁掉 atime 更新。在挂载（Mount）文件系统时禁掉 atime 更新。atime 的全称是 access time，记录的是文件末了被访问的时间。记录 atime 需要操作系统访问 inode 资源，而禁掉 atime 可以制止 inode 访问时间的写入操作，减少文件系统的写操作数。可以实行 mount -o noatime 命令进行设置。
文件系统。建议至少选择 ext4 或 XFS。尤其是 XFS 文件系统，它具有高性能、高伸缩性等特点，特别实用于生产服务器。
swap空间设置。建议将 swappiness 设置成一个很小的值，比如 1～10 之间，以防止 Linux 的 OOM Killer 开启随意杀掉进程。你可以实行 sudo sysctl vm.swappiness=N 到临时设置该值，如果要永久生效，可以修改 /etc/sysctl.conf 文件，增长 vm.swappiness=N，然后重启机器即可。
ulimit -n 和 vm.max_map_count。前者如果设置得太小，你会碰到 Too Many File Open 这类的错误，而后者的值如果太小，在一个主题数超多的 Broker 机器上，你会碰到 OutOfMemoryError：Map failed 的严重错误，因此，建议在生产情况中得当调大此值，比如将其设置为 655360。详细设置方法是修改 /etc/sysctl.conf 文件，增长 vm.max_map_count=655360，保存之后，实行 sysctl -p 命令使它生效。
操作系统页缓存巨细。给 Kafka 预留的页缓存越大越好，最小值至少要容纳一个日志段的巨细，也就是 Broker 端参数 log.segment.bytes 的值。该参数的默认值是 1GB。预留出一个日志段巨细，至少能包管 Kafka 可以将整个日志段全部放入页缓存，如许，消耗者程序在消耗时能直接命中页缓存，从而制止昂贵的物理磁盘 I/O 操作。

3.2 JVM 层调优

设置堆巨细。建议将你的 JVM 堆巨细设置成 6～8GB。如果想精确调解的话，建议可以检察 GC log，特别是关注 Full GC 之后堆上存活对象的总巨细，然后把堆巨细设置为该值的 1.5～2 倍。如果你发现 Full GC 没有被实行过，手动运行 jmap -histo:live < pid > 就能人为触发 Full GC。
GC 收集器的选择。强烈建议使用 G1 收集器，主要原因是方便省事，至少比 CMS 收集器的优化难度小得多。

3.3 Brocker 端调优

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

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

不要频繁地创建 Producer 和 Consumer 对象实例。构造这些对象的开销很大，尽量复用它们。
用完实时关闭。这些对象底层会创建很多物理资源，如 Socket 连接、ByteBuffer 缓冲区等。不实时关闭的话，势必造成资源走漏。
公道利用多线程来改善性能。Kafka 的 Java Producer 是线程安全的，你可以放心地在多个线程中共享同一个实例；而 Java Consumer 虽不是线程安全的，但我们有很多多线程的方案来改善性能。

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。

调优目的：高吞吐量、低延时。
优化漏斗：自上而下分为应用程序层、框架层、JVM 层和操作系统层。层级越靠上，调优的效果越明显。
操作系统层调优的4个关键：挂载文件系统时禁掉 atime 更新；选择 ext4 或 XFS 文件系统；swap 空间的设置；页缓存巨细。
JVM 层调优的2个关键：堆设置和 GC 收集器。
Brocker 端调优的关键：保持服务器端和客户端版本一致。
应用层调优：不要频繁地创建 Producer 和 Consumer 对象实例；用完实时关闭；公道利用多线程来改善性能。
调优吞吐量和延时，参照 2 个参数列表。

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

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)