kafka集群一台broker挂掉，解决办法

Posted 2023-04-01

参考技术A 4台kafka服务器39挂掉了，一直起不来 ，kafka 数据日志目录 服务器器上磁盘被占超过80%，告警
数据日志：$KAFKA_HOME/config/server.properties log.dirs配置项
操作日志：$KAFKA_HOME/logs目录
在同一台机器上进行不同磁盘的负载均衡,执行 kafka-reassign-partitions.sh 失败之后，重启kafka失败
想重新负载一下，结果失败
Partitions reassignment failed due to from /export1/kafka-log/ to /export2/kafka-log/
参考 https://www.cnblogs.com/set-cookie/p/9614241.html

1、查看

正常如下：
/usr/hdf/current/kafka-broker/bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list xx.xx.40.38:9092 --topic filebeat-dwlong-brush --time -1
filebeat-dwlong-brush:2:2964861
filebeat-dwlong-brush:1:2964843
filebeat-dwlong-brush:3:2948928
filebeat-dwlong-brush:0:2964749
每个分区offset 正常，如有消费，数值会有增加。

caseStudy-20180913-Kafka进程挂掉&解决办法

问题描述

2018年xx月xx日 下午4点20分左右 xxx无意中看到xxx正在排查线上Kafka集群遇到的问题，随后问明情况，有一台机器上Kafka进程挂了，当时他正在lark平台上查看错误日志信息，随后我一起加入排查问题。
事故起止时间：2018年xx月xx日 16时30分~2018年9月13日 17时25分
业务影响：理论上无影响，业务自动容错，生产和消费读写失败重试路由到其他Kafka节点上。
参与处理人：xxx、xxx

处理过程

2018年xx月xx日 16时42分 xxx查看lark日志，分析错误日志
2018年xx月xx日 16时48分 xxx登录Kafka机器10.136.40.2 查看系统参数
2018年xx月xx日 16时55分 xxx整理系统优化参数列表
2018年xx月xx日 17时12分  xxx修改系统参数
2018年xx月xx日 17时25分 xxx通过开源cloudera平台重启Kafka服务，观察日志，启动正常

定位过程

1.查看lark错误日志

 

 

 

 

 

看到 more Caused by: java.lang.OutOfMemoryError: Map failed at sun.nio.ch.FileChannelImpl.map0(Native Method) 错误

登录上机器(ssh 10.136.40.2)查看：

 

 

如上图不是jvm heap OutofMemoryError报错，是新创建索引文件做mmap内存映射时报错，通过判断分析，很可能是max_map_count数量不足导致的。
google搜索问题原因：https://stackoverflow.com/questions/43042144/kafka-server-failed-to-start-java-io-ioexception-map-failed

 

 

基本确定是max_map_count配置过低导致的
查看系统参数配置
[worker@c3-d13-136-40-2 kafka]$ sudo sysctl -a | grep "max_map_count"
vm.max_map_count = 65530

通过Kafka系统参数配置，想到了elastic search启动前强制配置系统参数，否则启动报错

 

 

es中vm.max_map_count参数配置

 

 

es启动强制优化的做法，值得借鉴 

 

 

为什么会出现此次故障

• 1.缺乏完善监控报警系统，无法做到及时预警
• 2.我们对Kafka集群线上运行情况不掌握，不了解
• 3.centos系统未做参数优化

为什么缺乏监控报警系统

• 因为我们的Kafka生态圈处于建设中

为什么Kafka集群线上运行情况不掌握，不了解

• 因为之前对Kafka了解甚少，缺乏对Kafka整体把控和认识

为什么系统未做参数优化

• 因为系统是运维安装的，我们就直接用了，没有注意到会有如此影响，对Kafka运行环境要求理解不深刻

max_map_count作用分析

名词解释：进程中虚拟内存映射区域的最大数量。
官方解释：https://www.oschina.net/translate/understanding-virtual-memory?print
max_map_count文件包含限制一个进程可以拥有的VMA(虚拟内存区域)的数量。虚拟内存区域是一个连续的虚拟地址空间区域。在进程的生命周期中，每当程序尝试在内存中映射文件，链接到共享内存段，或者分配堆空间的时候，这些区域将被创建。调优这个值将限制进程可拥有VMA的数量。限制一个进程拥有VMA的总数可能导致应用程序出错，因为当进程达到了VMA上线但又只能释放少量的内存给其他的内核进程使用时，操作系统会抛出内存不足的错误。如果你的操作系统在NORMAL区域仅占用少量的内存，那么调低这个值可以帮助释放内存给内核用。
百度质量部分析参考：http://www.10tiao.com/html/473/201606/2651473114/1.html

 

 

程序底层调研malloc、直接调用mmap和mprotect和加载共享库时、java中类FileChannel.map方法都会产生内存映射区域。

Kafka服务使用scala语言开发，运行与jvm平台上，因为jvm heap是预分配的内存，所以占用虚拟虚拟内存区域很少。在Kafka程序中占用最大是做文件映射(调用mmap函数)，Kafka中存储分为数据文件和索引文件，数据文件直接读写不进行mmap映射，而索引文件为了加快读写速度就实现了mmap映射机制，每创建一个索引文件做一次虚拟内存映射，map_count数量就加1，直到当前map_count > 系统 max_map_count，就会抛出OutofMemoryError，接着java进程退出了。下面是索引文件做映射的代码

 

后续工作

Kafka集群面临的风险
如果其他节点不进行系统参数优化，Kafka节点可能因为请求高峰或数据倾斜，也有挡掉的风险，所以Kafka集群所有的节点都要进行调整，防患于未然。下面TODO工作。

梳理系统参数列表 列出所有系统优化参数  xxx    xx月xx日 DONE
编写脚本上线执行 提交工单，运维负责执行 xxx  xx月xx日 DONE 

 

博客地址引用：https://www.cnblogs.com/lizherui/p/12650254.html