1>.java.lang.OutOfMemoryError:Map failed
发生上述问题，原因是发生OOM啦，会导致kafka进程直接崩溃掉！因此我们只能重新启动broker节点了，但是我们为了让broker节点启动成功快一点的话，可以将一个参数的之调大：“num.recovery.threads.per.data.dir=30”，没错就是他，我们将他的值越调大越好。这个线程数主要是负责停止和启动broker的。我是32core的服务器，因此我给他分配了30个，咱们可以尽量的把这个参数调大，便于该broker节点更快的加入到ISR列表当中。
首先，根据上面的提示恢复服务是第一件要做的事情，接下来，我们得分析分析为什么会出这个事情，我们一起看一下，我给我的kafka集群分配了20G内存，如下图：
查看了近2个星期的监控图，发现可用内存在持续减少，初步怀疑可能发生了内存泄漏。
这也只是怀疑，因为出错之前我没有监控JVM的情况，吃一堑，长一智，赶紧用zabbix将kafka的jvm监控起来。
之后，我百度了一下，调整了下面的参数，不知是否有效，先观察一段时间再说。
sysctl vm.max_map_count=262144 #进程中内存影视区域的最大数量。在调用malloc，直接调用mmap和mprotect和加载共享库时产生内存映射区域。虽然大多数程序需要的内存映射区域不超过1000个，但是特定的程序，特别是malloc调试器，可能需要很多，例如每次分破都会产生一道两个内存映射区域，默认值是65536。
解决方案:
第一：kafka的heap内存分配不要大于6G，我们知道kafka并不吃堆内存，如果设置默认的1G的话也并不太合理。推荐设置配置为6G即可。我服务器是32G内存，然后给kafka就分配了22G的heap内存。经过参考《kafka权威指南》和《Apache kafka实战》两位大佬的笔记，他们推荐设置kafka的heap大小为5G或者6G。最后我将kafka的heap内存配置成了6G。
第二：调整“vm.max_map_count”参数，没错，就是上面我提到的那个参数。在实际生产环境中，如果单台broker上topic数过多，用户可能碰到“java.lang.OutOfMemoryError:Map failed”的严重错误以导致kafka节点崩溃。这是因为大量创建topic将极大的消耗操作系统内存，用于内存映射操作。在这种情况下，用户需要调整“vm.max_map_count”参数。具体方法可以使用命令：“sysctl vm.max_map_count=N”来设置。该参数默认值是65535，可以考虑线上环境设置更大的值，比如262144甚至更大。
2>.