kafka单条消息过大导致线上OOM，运维连夜跑路了！

48 阅读 0 评论 32 点赞

我是靠谱客的博主苹果早晨，最近开发中收集的这篇文章主要介绍kafka单条消息过大导致线上OOM，运维连夜跑路了！，觉得挺不错的，现在分享给大家，希望可以做个参考。

1 线上问题

kafka生产者罢工，停止生产，生产者内存急剧升高，导致程序几次重启。

查看日志，发现Pro程序爆异常kafka.common.MessageSizeTooLargeException。

查看kafka配置，默认单条消息最大1M，当单条消息长度超过1M，就会出现发送到broker失败，从而导致消息在producer的队列一直累积，直到Pro OOM。

赶紧修改kafka配置，解决问题。

修改kafka的broker配置：message.max.bytes（默认1000000B），单条消息最大长度。使用kafka时，应预估单条消息的最大长度，不然会发送失败
修改kafka的broker配置：replica.fetch.max.bytes (默认1MB)，broker可复制的消息的最大字节数。应该比message.max.bytes大，否则broker会接收此消息，但无法将此消息复制出去，从而造成数据丢失
修改消费者程序端配置：fetch.message.max.bytes (默认1MB) – 消费者能读取的最大消息。应该≥message.max.bytes。若不调节该参数，会导致消费者无法消费到消息，且不会爆出异常或警告，导致消息在broker累积

按需调整上三参数。

或者说，单条消息越大越好？参考http://www.mamicode.com/info-detail-453907.html说法：

通过性能测试，kafka在消息为10K时吞吐量达到最大，更大消息降低吞吐量，在设计集群的容量时，尤其要考虑。

Brokers会为每个分区分配replica.fetch.max.bytes参数指定的内存空间，假设

replica.fetch.max.bytes=1M

且有1000个分区，则需近1G内存，确保分区数最大的消息不会超过服务器内存，否则OOM。

消费端的fetch.message.max.bytes指定最大消息需要的内存空间，同样，分区数最大需要内存空间不能超过服务器内存。所以，若你有大消息要传送，则在内存一定时，只能：

更大的消息会让GC更长（因为broker需分配更大的块），关注GC日志和服务器日志信息。若长时间的GC导致kafka丢失了zk的会话，则需配置zookeeper.session.timeout.ms参数为更大的超时时间。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供，作为学习参考使用，或来自网络收集整理，版权属于原作者所有。