背景:
今天测试了两种不同的场景下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。文章来源:https://www.toymoban.com/news/detail-556860.html
2.当我们进行压测时,压测的场景要尽量符合真实的场景,因为真实场景下有很多“坏邻居”,比如这里的场景B的logback模块,他们有可能对要压测的指标有很负面的影响.文章来源地址https://www.toymoban.com/news/detail-556860.html
到了这里,关于“坏邻居”导致的kafka生产者TPS下降原因排查的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!