kafka 同步：“java.io.IOException：打开的文件太多”

Question

我们遇到了卡夫卡的问题。 有时突然，我们在没有警告的情况下退出同步并在发出事件时开始出现异常。

我们得到的例外是

java.io.IOException: Too many open files

在许多情况下，这似乎是 Kafka 抛出的通用异常。 我们对其进行了一些调查，我们认为根本原因是在尝试向某个主题发出事件时，它失败了，因为 kafka 没有该主题的领导分区

有人可以帮忙吗？

Answer 1

我假设您使用的是 Linux。 如果是这种情况，那么发生的情况是您的打开文件描述符用完了。 真正的问题是为什么会发生这种情况。

默认情况下，Linux 通常会将这个数字保持在相当低的水平。 您可以通过 ulimit 检查实际值：

ulimit -a | grep "open files"

然后，您可以再次通过 ulimit 设置该值：

sudo ulimit -n 4096

也就是说，除非有问题的 Kafka 主机有很多主题/分区，否则达到该限制是不寻常的。 可能发生的事情是其他一些进程保持文件或连接打开。 为了找出哪个进程，您将不得不使用 lsof 进行一些侦查工作。

Answer 2

发生这种情况的一种情况是，当您有很大的分区号时，因为每个分区映射到代理中文件系统中的一个目录，该目录由两个文件组成。 其中一个用于索引，另一个用于数据。 经纪人打开这两个文件。 所以更多的分区号有更多的打开文件。 正如 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

或任何硬配置。 之后关闭您的会话并再次检查打开文件的限制

Answer 3

我在 Linux/CentOS 上有类似的“java.io.IOException: Too many open files”问题。 就我而言，在使用isof检查打开 fd 后，是 kafka-web-console 打开了太多连接。 停止这解决了我的问题。

Answer 4

在我们的例子中，我们的 Kafka 主题被意外配置为"segment.ms" = 20000并且在默认值为 604800000（1 周）时每 20 秒生成一次新的日志段。

我们正在使用亚马逊的 msk，所以我们自己没有能力运行这些命令，但是亚马逊支持人员能够为我们监控它。 这导致了这个问题，但随后一些节点没有恢复。

我们走了两步..

1) 强制压实

我们将保留率和比率设置得较低以进行清理

"delete.retention.ms" = 100
"min.cleanable.dirty.ratio" = "0.01"

其中一个节点能够恢复……但另一个节点似乎没有恢复到 Kafka 实际运行压缩的程度，它似乎是最大主题之一的“领导者”。

2）释放空间

我们决定销毁大主题，希望它能解除节点的阻塞。 最终，压缩似乎在所有节点上运行。

后来我们用新的分段设置恢复了我们破坏的主题，并且从那时起一直运行良好。