Kafka启动失败报错Too many open files，寻求永久解决方案

你遇到的java.io.IOException: Too many open files报错核心是Kafka进程的文件句柄耗尽，临时调整全局ulimit不生效是因为systemd管理的服务默认不继承全局ulimit配置，加上大概率存在客户端连接泄漏，才会每天重复触发问题。

1. 统计Kafka连接总数量 #

默认Kafka监听9092端口，你可以替换为你实际使用的端口，执行以下命令统计各状态的连接数：

ss -ant | grep :9092 | awk '{print $2}' | sort | uniq -c

输出结果中：

• ESTAB对应的数值就是已建立的连接数
• TIME_WAIT、CLOSE_WAIT等其他状态的数值总和就是等待中的连接数

2. 定位建立大量连接的微服务 #

首先按客户端IP统计连接数，从高到低排序：

ss -ant | grep :9092 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr

拿到连接数异常高的IP后，登录对应服务器执行以下命令，即可定位到对应的微服务进程：

ss -antp | grep :9092

这类大量连接的场景基本都是客户端代码问题，多数是没有复用生产者/消费者实例，每次请求都新建连接且用完未释放。

第一步：配置Kafka服务永久句柄限制 #

systemd管理的服务需要单独配置句柄限制，编辑/etc/systemd/system/kafka.service文件，在[Service]段新增以下两行配置：

[Service]
LimitNOFILE=655360
LimitNPROC=655360

修改完成后执行以下命令重载配置并重启Kafka：

systemctl daemon-reload
systemctl restart kafka

重启后验证配置是否生效，替换<kafka_pid>为实际Kafka进程ID：

cat /proc/<kafka_pid>/limits | grep 'Max open files'

确认输出的软限制、硬限制均为655360即配置生效。

第二步：修复客户端连接泄漏 #

定位到异常微服务后，检查Kafka客户端配置和代码：

• 禁止每次发消息都新建KafkaProducer/KafkaConsumer实例，全局复用单例即可
• 确认临时创建的客户端实例用完后必须调用close()方法释放资源
• 调整connections.max.idle.ms参数，不要设置为-1（永不超时），建议设置为300000（5分钟），让服务端自动释放空闲过久的连接

内容的提问来源于stack exchange，提问作者Nick