消费者太多!RocketMQ又炸了!

开发 前端
问题找到了,直接的解决方式是删除文件中无用的consumerGroup name​,重启broker进行加载。由于是线下环境,不需要担心位点丢失的问题,同时当客户端请求时会自动创建新的位点信息,所以可以考虑直接删除。

1、问题现象

先说明下RocketMQ版本, 4.6.0的老版本了。

线下环境客户端启动会频繁报错响应超时,导致consumer实例化失败,无法启动应用。

图片图片

2、排查

确认线下环境RocketMQ集群流量、生产消费数量无异常。

集群gc次数不多,但是耗时高。(原本监控看板异常数据缺失,所以少了前面一段)

图片图片

master节点cpu使用率、load极高。

图片图片

升配,4c8g升级8c32g,扩大jvm内存。

系统指标略有下降,但是客户端异常没有明显改善。

只能进一步排查根因,还得上arthas。

thread -n 3

查看cpu高的线程在做什么。

发现两个异常线程。

1)一个线程在执行AdminBrokerProcessor.queryTopicConsumerByWho()。

图片图片

这个是查询Topic的conusmerGroup信息。

比较奇怪的是,这个请求很频繁,后来发现是控制台应用dashboard有个定时任务,30s查询一次。

这个请求的耗时主要是在数组的遍历处理上,说明内存中的数据非常大。

图片图片

而这个源码中的offsetTable,就是RocketMQ中保存consumerGroup位点信息的对象。它的key是topic@group拼接的。

图片图片

先临时处理,把dashboard应用关闭了,减少请求。但是效果并不明显。

2)另一个线程在执行定时任务ConsumerOffsetManager.persist()。

(线程调用信息忘记截图了)

这个是RocketMQ集群持久化consumerGroup的offset信息的定时任务。

图片图片

会将整个内存对象转化为jsonString写入磁盘文件中。

这个内存对象就是前面提到的offsetTable,就是RocketMQ中保存consumerGroup位点信息的对象。

这里消耗资源多,还是说明我们的内存对象非常大。

因为是线下环境,可靠性要求不高。所以先临时处理,把定时任务默认配置5s改成50s,减少持久化次数。

效果显著,机器cpu、负载都明显改善。

好了,现在问题的矛头都指向了这个offsetTable,那它到底有多大,为什么这么大?

3、定位根因

3.1 直接原因

大对象的定位,一般来说需要dump看看,不过这个对象有点特殊,刚刚也提到了它会被持久化到文件中,所以直接看文件大小和内容就行了。

持久化文件的配置路径,可以看下启动的conf.properties

storePathRootDir=/usr/local/rocketmq/store1
storePathCommitLog=/usr/local/rocketmq/store1/commitlog
storePathConsumerQueue=/usr/local/rocketmq/store1/consumequeue
storePathIndex=/usr/local/rocketmq/store1/index

在/usr/local/rocketmq/store1目录下找到config文件夹的consummerOffset.json文件,44M,amazing~

对一个几十M的对象频繁序列化和持久化,加上内网磁盘比较差,难怪负载如此高。

图片

(这里截图是当时应急时备份的文件,新的文件目前是414K)

3.2 根本原因

为什么这个内存对象这么大呢?

查看了下文件内容,是RocketMQ中保存consumerGroup位点信息的对象,它的key是topic@group拼接的。

我们发现大量奇怪的consumerGroup name,跟一个topic联合产生了几千个key。

查看了下内部封装的客户端代码,找到了罪魁祸首。

图片图片

线下环境会根据小环境(比如自己起的测试、单测环境、CI测试环境等)拼接一个独立的consumerGroup name。

在线下,每次CI的测试环境名字会变化,所以导致consumerGroup name数量急剧膨胀。

4、优化

问题找到了,直接的解决方式是删除文件中无用的consumerGroup name,重启broker进行加载。

由于是线下环境,不需要担心位点丢失的问题,同时当客户端请求时会自动创建新的位点信息,所以可以考虑直接删除。

图片图片

先停止broker进程(否则会自动落盘内存数据,创建新的文件),然后重命名相关文件(用于备份回滚),重新启动broker进程,读取空文件加载空对象。

重启后,各个客户端在请求集群时,会自动创建订阅关系和消费位点记录,负载略有升高,然后就恢复到较低的负载水位了。

24h的监控显示,优化效果显著,整个机器负载降低,请求读写耗时也显著降低。

图片图片

注意:保存订阅关系的subscriptionGroup.json也存在同样consumerGroup过多导致膨胀的问题,同样的原因和优化方式。默认订阅关系也是会自动创建的。这里就不展开赘述了。

5、扩展一下

如果类似的问题出在线上怎么办?

事后来看,类似问题是能够提前避免的,主要考虑两个措施:

  • 要做好持久化文件(对应内存对象)大小监控,避免出现内存大对象。如果发现异常增长,必须提前排查处理。
  • 磁盘要足够好,使用SSD是基本要求,避免频繁刷盘导致负载升高。

责任编辑:武晓燕 来源: 阿丸笔记
相关推荐

2024-01-24 09:00:31

SSD订阅关系内存

2023-03-27 09:50:16

RocketMQ中间件

2022-07-07 09:00:49

RocketMQ消费者消息消费

2022-03-14 11:05:01

RocketMQRedis缓存

2021-07-12 10:25:03

RocketMQ数据结构kafka

2022-11-08 07:36:17

RocketMQ消费者消息堆积

2022-05-09 11:15:05

RocketMQPULL 模式PUSH 模式

2023-03-28 07:08:09

RocketMQ消费者堆栈

2023-06-01 08:08:38

kafka消费者分区策略

2015-08-26 09:39:30

java消费者

2011-08-05 16:21:24

2011-07-22 16:25:38

CA TechnoloIT消费化

2023-01-29 08:46:08

2009-08-13 13:14:31

C#生产者和消费者

2015-06-15 11:29:34

数据中心绿色数据中心

2021-12-22 11:00:05

模型Golang语言

2018-05-16 23:37:55

携号转网运营商网络

2015-08-31 10:45:02

数据

2009-04-15 11:17:23

2022-01-04 06:51:53

AI消费者行为
点赞
收藏

51CTO技术栈公众号