生产环境Kafka集群400W/Tps为啥就扛不住了?

开发 架构
通过监控平台观察Kafka集群中相关的监控节点,发现cpu使用率才接近20%左右,磁盘IO等待等指标都并未出现任何异常,那会是什么问题呢?

最近公司日志Kafka集群出现了性能瓶颈,单节点还没达到60W/tps时消息发送就出现了很大延迟,甚至最高超过了10s,截图说明如下:

虽说使用的机械磁盘,但这点压力对Kafka来说应该是小菜一碟,这引起了我的警觉,需要对其进行一番诊断了。

通过监控平台观察Kafka集群中相关的监控节点,发现cpu使用率才接近20%左右,磁盘IO等待等指标都并未出现任何异常,那会是什么问题呢?

通常CPU耗时不大,但性能已经明显下降了,我们优先会去排查kafka节点的线程栈,获取线程栈的方法比较简单,命令为:

ps -ef | grep kafka // 获取pid
jstack pid > j1.log

通过上述命令我们就可以获取到kafka进程的堆栈信息,通过查看线程名称中包含kafka-request-handler字眼的线程(Kafka中处理请求),发现了大量的锁等待,具体截图如下所示:

并且在jstack文件中发现很多线程都在等待这把锁,截图如下:

我们先根据线程堆栈查看代码,找到对应的源代码如下图所示:

通过阅读源码,这段代码是分区Leader在追加数据时为了保证写入分区时数据的完整性,对分区进行的加锁,即如果对同一个分区收到多个写入请求,则这些请求将串行执行,这个锁时必须的,无法进行优化,但仔细观察线程的调用栈,发现在锁的代码块出现了GZIPInputstream,进行了zip压缩,一个压缩处在锁中,其执行性能注定低下,那在什么时候需要在服务端进行压缩呢?

故我们继续看一下LogValidator的validateMessagesAndAssignOffsets方法,最终调用validateMessagesAndAssignOffsetsCompressed方法,部分代码截图如下所示:

这段代码的注释部分详细介绍了kafka在服务端需要进行压缩的4种情况,对其进行翻译,其实就是两种情况:

  • 客户端与服务端端压缩算法不一致
  • 客户端与服务端端的消息版本格式不一样,包括offset的表示方法、压缩处理方法

关于客户端与服务端压缩算法不一致,这个基本不会出现,因为服务端通常可以支持多种压缩算法,会根据客户端的压缩算法进行自动匹配。

最有可能的就是服务端与客户端端消息协议版本不一致,如果版本不一致,则需要在服务端重新偏移量,如果使用了压缩机制,则需要重新进行解压缩,然后计算位点,再进行压缩存储,性能消耗极大。

后面排查日志使用端,确实是客户端版本与服务端版本不一致导致,最终需要对客户端进行统一升级。

责任编辑:武晓燕 来源: 中间件兴趣圈
相关推荐

2021-01-29 07:45:27

if-else代码数据

2023-09-08 15:48:13

2009-05-09 15:14:58

多核四核电源

2022-02-10 23:20:45

2G运营商中国移动

2020-03-26 08:30:39

运营商5G网络

2018-12-29 11:17:47

2021-04-16 23:33:48

区块链安全私钥

2021-11-28 17:01:49

工业公司网络攻击黑客

2021-06-01 22:20:07

私钥互联网安全

2023-06-29 07:22:11

功率12V电脑

2023-08-29 23:28:19

2020-07-24 07:38:20

Nginx并发量日志

2021-05-26 08:48:33

数据MySQL业务迁移

2015-01-05 10:04:25

2015-06-24 12:58:04

数据中心雾霾

2021-03-16 11:10:37

Redis数据库命令

2022-12-26 09:16:56

请求量代码QPS

2023-01-29 14:22:08

承包商OpenAIAI

2022-12-22 16:27:23

马斯克推特

2021-05-10 10:22:53

美帝国产OS
点赞
收藏

51CTO技术栈公众号