【问题标题】:Kafka broker node goes down with "Too many open files" errorKafka 代理节点因“打开的文件过多”错误而关闭
【发布时间】:2019-08-03 06:27:43
【问题描述】:

我们有一个 3 节点的 Kafka 集群部署,共有 35 个主题,每个主题有 50 个分区。总的来说,我们已经配置了replication factor=2。 我们看到一个非常奇怪的问题,即 Kafka 节点间歇性地停止响应并出现错误:

ERROR Error while accepting connection (kafka.network.Acceptor)
java.io.IOException: Too many open files
  at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
  at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
  at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
  at kafka.network.Acceptor.accept(SocketServer.scala:460)
  at kafka.network.Acceptor.run(SocketServer.scala:403)
  at java.lang.Thread.run(Thread.java:745)

我们已经部署了最新的 Kafka 版本,并使用 spring-kafka 作为客户端:

kafka_2.12-2.1.0 (CentOS Linux release 7.6.1810 (Core))

  • 有三个观察结果:
    1. 如果我们执行lsof -p <kafka_pid>|wc -l,我们得到的打开描述符总数大约只有 7000 个。
    2. 如果我们只做lsof|grep kafka|wc -l,我们会得到大约 150 万个开放式 FD。我们已经检查过它们都只属于 Kafka 进程。
    3. 如果我们将系统降级到 Centos6,那么lsof|grep kafka|wc -l 的输出将回到 7000。

我们已尝试将文件限制设置为非常大,但仍然遇到此问题。以下是为kafka进程设置的限制:

cat /proc/<kafka_pid>/limits
    Limit                     Soft Limit           Hard Limit           Units
    Max cpu time              unlimited            unlimited            seconds
    Max file size             unlimited            unlimited            bytes
    Max data size             unlimited            unlimited            bytes
    Max stack size            8388608              unlimited            bytes
    Max core file size        0                    unlimited            bytes
    Max resident set          unlimited            unlimited            bytes
    Max processes             513395               513395               processes
    Max open files            500000               500000               files
    Max locked memory         65536                65536                bytes
    Max address space         unlimited            unlimited            bytes
    Max file locks            unlimited            unlimited            locks
    Max pending signals       513395               513395               signals
    Max msgqueue size         819200               819200               bytes
    Max nice priority         0                    0
    Max realtime priority     0                    0
    Max realtime timeout      unlimited            unlimited            us

我们这里有几个问题:

  • 当我们已经配置了如此大的进程限制时,为什么代理会间歇性关闭? kafka 是否需要更多可用的文件描述符?
  • 为什么centos中lsoflsof -p的输出有差异 6 和 centos 7?
  • broker节点的数量是不是少了3个?将复制因子视为 2,我们每个主题有大约 100 个分区,分布在 3 个节点中,因此每个节点大约有 33 个分区。

编辑 1: 好像我们遇到了 Kafka 问题:https://issues.apache.org/jira/browse/KAFKA-7697

我们将计划将 Kafka 版本降级到 2.0.1。

【问题讨论】:

  • 通过 Kafka 的流量是多少?您是否确保生产者和消费者正在做正确的事情并做他们必须做的事情......?文件描述符的数量确实很大.. ?通常我们使用 ubuntu,部署非常大,100K msg / sec,从未见过这样的问题..
  • 目前所有主题的总流量仅为 2K msg/sec。生产者和消费者似乎没有错。值得一提的是,我们已将 kafka 日志保留策略更改为 1 小时,因为我们的消息不需要长期存在。
  • 你调整过 KAFKA_LOG_ROLL_MS 吗?它目前的价值是多少?
  • 是的.. 我们配置了以下值:log.retention.check.interval.ms=300000 log.retention.ms=3600000 log.roll.ms=3600000
  • 这些值看起来不错,正如您提到的,您在 CentOS6 上看不到这个问题,所以您不认为它可能与操作系统有关 ..

标签: apache-kafka centos spring-kafka ulimit lsof


【解决方案1】:

根据提问者之前的更新,他发现他在打https://issues.apache.org/jira/browse/KAFKA-7697

现在快速检查显示它已解决,并且基于 jira 似乎该问题的解决方案是使用 Kafka 2.1.1 及更高版本。

【讨论】:

    猜你喜欢
    • 2020-02-26
    • 2017-12-09
    • 2013-11-15
    • 2019-06-20
    • 2013-11-02
    • 1970-01-01
    • 2012-02-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多