Kafka线上单partition积压问题定位

举报
张俭 发表于 2023/12/29 17:43:38 2023/12/29
【摘要】 现象近期,参与了一次处理线上Kafka单partition积压问题的定位处理。总结一下 处理过程我上线的情况是,16个partition的消息,其中有一个partition的积压特别大,而且该partition所在消费者同时消费者两个partition。同事反馈之前已经尝试过重启,该partition已经迁移到了其他服务所在的机器,情况仍没有好转。其实当时就有想过,是否是处理该partit...

现象

近期,参与了一次处理线上Kafka单partition积压问题的定位处理。总结一下

处理过程

我上线的情况是,16个partition的消息,其中有一个partition的积压特别大,而且该partition所在消费者同时消费者两个partition。
同事反馈之前已经尝试过重启,该partition已经迁移到了其他服务所在的机器,情况仍没有好转。

其实当时就有想过,是否是处理该partition的消息太慢,导致单topic积压,但同事反馈该代码仅仅是插入数据库,而且同时数据库没有任何慢日志。所以没往这个方向继续。

接下来怀疑kafka broker端返回慢,kafka侧开启debug日志查看了fetch和commit,其中有很重要的信息,是两次commit之间间隔大概在20多秒,然后offset差有四五百条消息,这可commit的太慢了。本着代码处理速度正常的思路(该思路已经是错的了,这个时候就应该去追查代码处理慢的问题),接下来我们尝试抓包分析,是否是fetch来回慢导致的,查到fetch其实很快。

唉,接下来我们又尝试了扩容,试图让单partition落到一台机器,排除其他partition的干扰。(从事后来看,这一步也是错误的,浪费了一些时间)
也有这部分处理时长没有监控,打开info日志,难以查找的因素。

然后运气很好,扩容后,单partition确实落到了一台机器上,果然问题没有解决。这个时候打开了INFO日志,另一位同事此时在后台查找到了处理异常的消息,处理时长达数十秒。

之前有抓包,我们打开了抓包,才发现,该代码逻辑支持批量,这条处理数十秒的消息,其实里面有数千条批量消息,在代码中执行了for循环入库,导致耗时很长。

经验教训

  • 关键的线程池的执行任务超长一定要进行监控
  • 如果在消息中间件中插入了一条消息,但这条消息代表了很多条消息,会导致线上出现很严重的偏移
【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。