如何把一个运行完好的Kafka搞崩溃

原 如何把一个运行完好的Kafka搞崩溃https://blog.csdn.net/u013256816/article/details/82804525版权声明：本文为博主原创文章，未经博主朱小厮允许不得转载。 https://blog.csdn.net/u013256816/article/details/82804525
欢迎支持笔者新作：《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》，同时欢迎关注笔者的微信公众号：朱小厮的博客。
Kafka其实也只是一个JVM进程，要想把一个进程搞崩溃，相信大家的nice idea（骚操作）也不少。本文中只是用了一种很常见的方式来使得Kafka的进程崩溃，通过分析崩溃的原因来让我们可以更合理的使用Kafka。
你可以试着在一台普通的Linux机器上创建10000个分区的主题。比如下面示例中创建一个主题topic-bomb：
[root@node1 kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka 
--create --topic topic-bomb --replication-factor 1 --partitions 10000
Created topic "topic-bomb".
1
2
3
执行完成之后你可以检查一下Kafka的进程是否还存在（比如通过jps命令或者ps -aux|grep kafka命令）。一般情况下，你会发现原本运行完好的Kafka服务已经崩溃。此时，你或许会想到，创建这么多个分区，是不是内存不够而引起的进程崩溃，我在启动Kafka的时候将JVM堆设置的大一点是不是就可以解决了。其实不然，创建这点儿分区而引起的内存增加完全不足以让Kafka畏惧。
想要知道真相，我们可以打开Kafka的服务日志文件（$KAFKA_HOME/logs/server.log）来一探究竟，你会发现服务日志中出现大量的如下异常：
[2018-09-13 00:36:40,019] ERROR Error while creating log for topic-bomb-xxx in dir /tmp/kafka-logs (kafka.server.LogDirFailureChannel)
java.io.IOException: Too many open files
 at java.io.UnixFileSystem.createFileExclusively(Native Method)
 at java.io.File.createNewFile(File.java:1012)
 at kafka.log.AbstractIndex.<init>(AbstractIndex.scala:54)
 at kafka.log.OffsetIndex.<init>(OffsetIndex.scala:53)
 at kafka.log.LogSegment$.open(LogSegment.scala:634)
 at kafka.log.Log.loadSegments(Log.scala:503)
 at kafka.log.Log.<init>(Log.scala:237)
1
2
3
4
5
6
7
8
9
异常中最关键的信息是：“Too many open flies”，这是一种常见的Linux系统错误，通常意味着文件描述符不足，它一般会发生在创建线程、创建Socket、打开文件这些场景下。在Linux系统中的默认设置下，这个文件描述符的个数不是很高，可以通过ulimit查看：
[root@node1 kafka_2.11-2.0.0]# ulimit -n
1024
[root@node1 kafka_2.11-2.0.0]# ulimit -Sn
1024
[root@node1 kafka_2.11-2.0.0]# ulimit -Hn
4096
1
2
3
4
5
6
ulimit是在系统允许的情况下，提供对特定shell可利用的资源的控制。（Provides control over the resources avaliable to the shell and to processes started by it, on systems that allow such control）
-H和-S选项设定指定资源的硬限制和软限制。硬限制设定之后不能再添加，而软限制则可以增加到硬限制规定的值。如果-H和-S选项都没有指定，则软限制和硬限制同时设定。限制值可以是指定资源的数值或者hard、soft、unlimited这些特殊值，其中hard代表当前硬限制, soft代表当前软件限制, unlimited代表不限制。如果不指定限制值, 则打印指定资源的软限制值, 除非指定了-H选项。硬限制是可以在任何时候任何进程中设置 但硬限制只能由超级用户提起。软限制是内核实际执行的限制，任何进程都可以将软限制设置为任意小于等于对进程限制的硬限制的值
我们可以通过测试来验证一下本案例中的Kafka崩溃是否是由于文件描述符的限制而引起的。首先启动Kafka集群，集群中有3个节点，配置一样。挑选其中的一台节点node1做具体分析，通过jps命令我们可以查看到kafka的进程pid的值：
[root@node1 kafka_2.11-2.0.0]# jps -l
31796 kafka.Kafka
1
2
查看当前Kafka进程所占用的文件描述符的个数（注意这个值并不是Kafka第一次启动时就需要占用的文件描述符的个数，示例中的Kafka环境下已经存在了若干主题）：
[root@node1 kafka_2.11-2.0.0]# ls /proc/31796/fd | wc -l
194
1
2
我们再新建一个只有一个分区的主题，并查看Kafka进程所占用的文件描述符的个数：
[root@node1 kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic topic-bomb-1 --replication-factor 1 --partitions 1
Created topic "topic-bomb-1".
[root@node1 kafka_2.11-2.0.0]# ls /proc/31796/fd | wc -l
195
1
2
3
4
可以看到增加了一个分区对应的也只增加了一个文件描述符。
之前我们通过ulimit命令可以看到软限制是1024，不妨我们就创建一个具有829（1024-195=829）个分区的主题：
[root@node1 kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic topic-bomb-2 --replication-factor 1 --partitions 829
Created topic "topic-bomb-2".
[root@node1 kafka_2.11-2.0.0]# ls /proc/31796/fd | wc -l
1024
1
2
3
4
可以看到Kafka进程此时占用了1024个文件描述符，并且运行完好。这时我们还可以联想到硬限制4096这个关键数字，不妨我们再创建一个包含有3071（4096-1024=3072，这里特定少创建1个分区）个分区的主题，示例如下：
[root@node1 kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic topic-bomb-3 --replication-factor 1 --partitions 3071
Created topic "topic-bomb-3".
[root@node1 kafka_2.11-2.0.0]# ls /proc/31796/fd | wc -l
4095
1
2
3
4
Kafka进程依旧完好，文件描述符占用为4095，逼近最高值4096。最后我们再次创建一个只有一个分区的主题：
[root@node1 kafka_2.11-2.0.0]# bin/kafka-topics.sh --zookeeper localhost:2181/kafka --create --topic topic-bomb-4 --replication-factor 1 --partitions 1
Created topic "topic-bomb-4".
[root@node1 kafka_2.11-2.0.0]# ls /proc/31796/fd | wc -l
ls: cannot access /proc/31796/fd: No such file or directory
0
1
2
3
4
5
此时Kafka已经崩溃，查看进程号时已没有相关信息。查看Kafka中的日志，还会发现报错文章开头的异常“java.io.IOException: Too many open files”，表明已到达上限。
如何避免这种异常情况？对于一个高并发高性能的应用来说，1024或者4096的文件描述符限制未免太少，可以适当的调大这个参数。比如使用ulimit -n 65535命令将上限提高到65535，这样足以应对大多数的应用情况，再高也完全没有必要了。
[root@node1 kafka_2.11-2.0.0]# ulimit -n 65535
#可以再次查看一下相应的软硬限制数
[root@node1 kafka_2.11-2.0.0]# ulimit -Hn
65535
[root@node1 kafka_2.11-2.0.0]# ulimit -Sn
65535
1
2
3
4
5
6
也可以在/etc/security/limits.conf文件中设置，参考如下：
#nofile - max number of open file descriptors
root soft nofile 65535
root hard nofile 65535
1
2
3
limits.conf文件修改之后需要重启才能生效。limits.conf与ulimit的区别在于前者是针对所有用户的，而且在任何shell都是生效的，即与shell无关，而后者只是针对特定用户的当前shell的设定。在修改最大文件打开数时，最好使用limits.conf文件来修改，通过这个文件，可以定义用户，资源类型，软硬限制等。也可修改/etc/profile文件加上ulimit的设置语句来是的全局生效。
设置之后可以再次执行文中开头的创建10000个分区的主题的命令，试一下，Kafka是否还会再次崩溃？欢迎在下方留言区留下你的探索-
欢迎支持笔者新作：《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》，同时欢迎关注笔者的微信公众号：朱小厮的博客。