kafka问题集(二):__consumer_offsets topic的分区中有一个分区数据很多,多达1T

仅个人实践中所遇到的问题,若有不对的,欢迎交流!


一、场景描述

  kafka集群中有几台突然挂了,后台日志显示设备空间满了,消息无法写入__consumer_offsets topic的分区中了。查看kafka数据目录下各个文件的大小,发现__consumer_offsets topic分区中有一个分区__consumer_offsets-5数据很多,多达1T,而其他分区只有4KB,相差巨大。且__consumer_offsets-5中保留了一年多的数据。什么情况?不应该自动清除吗?

二、问题分析

  1)__consumer_offsets分区中数据量相差这么大?

    __consumer_offsets topic的分区中存放的是consumer的offset等信息,其存放机制是用消费组id的hash值对分区数取模得到的。而我们只有一个消费组,所以会导致__consumer_offsets topic中的数据都写入一个分区。

  2)__consumer_offsets-5保留的一年多数据,为什么没有被清理?不是已经设置了log.retention.hours、log.retention.bytes这些参数了吗?

    首先说一点,__consumer_offsets的cleanup.policy策略是compact,而我们新建topic的清理策略默认是deleted,前者可以使用--describe 加上--topic  __consumer_offsets 可以看到,而后者可以在server.properties上可以看到。参数log.cleaner.enable参数对清理策略为compact起作用,且不是通过压缩(compact)文件达到减少数据的目的,通过测试,我们发现当文件属性不满足log.retention.hours、log.retention.bytes其中任何一项时,.log的数据文件文件就会被删除。当然也不是直接删除,是先将文件标记为-deleted,然后被清除。因为测试的时候被标记为-deleted后,再次执行ll命令时,文件已经被删除了,不知道删除时间间隔是否和参数log.retention.check.interval.ms有关,若有大佬知道欢迎留言分享。

    知道文件清理规则后,检查log.cleaner.enable设置,为false,故将其改为true即可。

三、测试过程

  修改参数log.segment.bytes的大小为1M,使得__consumer_offsets topic的分区中.log文件大小保留为1M;为了尽快确定log.cleaner.enable改为true是否会减小__consumer_offsets topic的分区中数据量的大小,需要修改触发删除的阈值。为减小阈值,修改log.retention.bytes为2M。但是在实际测试中我们发现当__consumer_offsets topic的分区中的.log大小为50M的时候还是没有触发删除。使用以下命令查看__consumer_offsets topic时发现,其默认的configure :segment.bytes大小为104857600,即为100M。

1 kafka-topics --decribe --zookeeper localhost:2181/kafka --topic __consumer_offsets

  通过查看kafka官网上有关segment bytes配置说明,发现删除时是以一个文件执行的,这个参数控制着文件大小。原文如下:

This configuration controls the segment file size for the log. Retention and cleaning is always done a file at a time so a larger segment size means fewer files but less granular control over retention.

  使用命令将这个segment.bytes改为10M,发现__consumer_offsets-5分区的数据很快就变为400+KB了。修改命令如下:

1 kafka-topics --zookeeper localhost:2181/kafka --alter --topic __consumer_offsets --config segment.bytes=10485760

四、应急策略

  当时因为是生产环境出现问题,来不及分析,要尽快将生产恢复正常,只能临时将日志等信息保留下来,以待后续分析。上述的分析还是自己后来查找资料知道的。当时采取的策略如下:

  停止程序;增加磁盘;删除topic;新建topic;启动程序;

  耗时近一个半小时,消费正常。这个步骤肯定是不行的,但是当时不是很懂,所以采取了临时的策略,欢迎大佬分享自己遇到这种问题时采取的措施!    

五、参考文献

  1)https://support.huawei.com/enterprise/zh/knowledge/KB1000676043/

  2)https://www.sohu.com/a/136881236_487514

    

上一篇:结合mmdetection对Anchor和RPN的浅薄理解


下一篇:CV基石-GoogleNet-V4论文研读