0


“坏邻居”导致的kafka生产者TPS下降原因排查

背景:

今天测试了两种不同的场景下kafka producer的tps性能数据,两种场景下都是使用3个线程,每个线程都是对应一个kafka producer,测试发送到kafka集群的消息的量,两个场景的区别是场景A只发送kafka消息,场景B是除了发送kafka消息之外,还使用logback记录日志(异步模式),但是得到的发送到kafka集群的消息的量相差较大,大概20%,本文就记录下造成kafka消息发送的tps相差较大的原因

追查原因:

一.还原下测试场景

首先说明下场景A和场景B的压测环境,
在这里插入图片描述

服务器:两个场景都是使用12核12G的容器进行测试的
消息大小: 两个场景使用的消息大小都是1k,logback记录到日志中的文本大小也是1k
kafka producer 数量: 两者都是3个生产者,分别对应3个发送消息的线程

最终压测的结果:
场景A也就是只有发送消息到kafka的TPS为80000,而场景B也就是既发送消息到kafka,也是用logback日志落盘的场景TPS为58000,两者相差将近1/3的TPS,

二.分析场景

gc影响: 场景A和场景B压测过程中的gc次数都差不多,总的gc停顿时间都差不多,都没有明显的gc停顿

cpu:在整个压测的过程中场景A的CPU使用率是60%,也就是使用到了12核 * 0.6 = 7.2核,场景B的cpu使用率是100%,也就是使用到了12核 * 1.0 = 12核

分析整个过程中的cpu火焰图,发现场景A中发送kafka消息的Run方法占用的cpu为40%,而场景B中发送kafka消息的Run方法占用的cpu为17%,也就是说场景A中总共使用的cpu核心=7.2核 * 0.4=2.9核,而场景B中总共使用的cpu核心=12核 * 0.17=2.1核,

是不是大概看出了问题所在?

场景A中每个核心发送的kafka消息的TPS为:80000/2.9核心 = 26600,而场景B中每核心发送kafka消息的TPS为:58000/2.1核心 = 27600

这两个场景中归结到每个cpu核上的TPS几乎是差不多的,所以问题也就明显了,场景B中cpu资源不足,也就是logback等模块占用了不少的cpu的资源,导致消耗在发送kafka消息上的cpu资源少了

总结:

1.从这个问题的查找可以得出一个结论,当对两个场景进行压测时,最好不要让cpu跑满100%,因为这样会限制对应场景能获得的cpu的资源,压测的结果就明显受限于cpu。

2.当我们进行压测时,压测的场景要尽量符合真实的场景,因为真实场景下有很多“坏邻居”,比如这里的场景B的logback模块,他们有可能对要压测的指标有很负面的影响.

标签: kafka 分布式

本文转载自: https://blog.csdn.net/lixia0417mul2/article/details/131691716
版权归原作者 lixia0417mul2 所有, 如有侵权,请联系我们删除。

““坏邻居”导致的kafka生产者TPS下降原因排查”的评论:

还没有评论