我们遇到了卡夫卡的问题。有时突然间，我们会在没有警告的情况下退出同步，并在发出事件时开始获得异常。
我们得到的例外是
java.io.IOException: Too many open files
在许多情况下，这似乎是Kafka抛出的一般异常。我们调查了一下，我们认为根本原因是当尝试将事件发布到某个主题时，它失败了，因为kafka没有针对此主题的领导分区
有人可以帮忙吗？
答案 0 :(得分：7)
我认为你在Linux上。如果是这种情况，那么正在发生的事情是你的文件描述符用完了。真正的问题是为什么会这样。
Linux默认情况下通常会将此数字设置得相当低。您可以通过ulimit检查实际值：
ulimit -a | grep "open files"
然后您可以再次通过ulimit：
设置该值sudo ulimit -n 4096
尽管如此，除非有问题的Kafka主持人有很多话题/分区，否则很难达到这个限制。可能发生的事情是，其他一些进程正在保持文件或连接处于打开状态。为了弄清楚你将要用lsof做一些侦探工作的过程。
答案 1 :(得分：1)
我在Linux / CentOS上遇到了类似的“java.io.IOException：Too many open files”问题。 在我的情况下，在用 isof 检查打开fd之后，它是kafka-web-console，它打开了太多的连接。停止这解决了我的问题。
答案 2 :(得分：0)
发生这种情况的一种情况是，当您拥有较大的分区号时，因为每个分区都映射到由两个文件组成的代理中的文件系统中的目录。其中一个用于索引，另一个用于数据。 broker打开这两个文件。所以更多的分区号有更多的打开文件。因为Doomy说你可以增加linux中的打开文件，但是这个配置不是永久性的，当你关闭会话时，这个配置就会消失。如果使用此命令检查，则在下一个登录名中
ulimit -a | grep "open files"
你可以看到旧号码。但是使用此配置，您可以将其永久化：
打开此文件：
sudo nano /etc/pam.d/common-session
并添加以下行：
session required pam_limits.so
之后你可以在limits.config中设置限制：
sudo nano /etc/security/limits.conf
然后您可以在此文件中设置限制例如
* soft nofile 80000
或任何硬配置。之后关闭会话并再次检查打开文件的限制
答案 3 :(得分：0)
在我们的案例中，我们的Kafka主题被意外配置"segment.ms" = 20000，并且默认情况下为604800000（1周）时，每20秒生成新的日志段。
我们正在使用亚马逊的msk，因此我们自己没有能力运行命令，但是亚马逊支持能够为我们监控它。造成了这个问题，但是随后某些节点无法恢复。
我们采取了两个步骤。
1）强制压实
我们将保留率和比率设置为较低以进行清理
"delete.retention.ms" = 100
"min.cleanable.dirty.ratio" = "0.01"
其中一个节点可以恢复...但是另一个节点似乎无法恢复到Kafka实际进行压缩的程度，它似乎是最大主题之一的“领导者”。
2）释放空间
我们决定销毁大型主题，希望它可以解除对节点的封锁。最终，压缩似乎在所有节点上进行。
稍后，我们使用新的细分设置恢复了我们销毁的主题，此后运行良好。