Kafka因文件句柄数过多导致挂掉的排查与解决

一、问题现象

在k8s集群中部署了多个服务，包括Kafka、TDengine集群和Java等。这些服务使用NFS作为持久化存储方案。最近遇到了一个问题：Kafka频繁报错并最终挂掉。错误日志如下：

2025-02-09T09:39:07,022] INF0 LogLoader partition=__consumer_offsets-7, dir=/bitnami/kafka/data producer state recovery took oms 2025-02-09T09:39:07 ERROR Error while loading log dir /bitnami/kafka/data (kafka.log.LogManager) /bitnami/kafka/data/_consumer_offsets-7/00000000000000000000.timeindex (Too many open files in system)

从日志可以看出，Kafka在尝试加载日志目录时遇到Too many open files in system错误，这表明系统中的打开文件句柄数超过了限制。

二、初步排查

（一）检查句柄数限制

1. 查看当前进程的句柄数限制
   • 使用命令ulimit -n来查看当前用户或进程的最大打开文件数限制。
2. 检查系统级别的文件句柄使用情况
   • 通过cat /proc/sys/fs/file-nr可以获取系统当前已分配、已使用和最大可用的文件句柄数。

我们发现尽管Kafka已经挂掉，但句柄数占用仍然很大，这意味着可能存在某些资源未被正确释放的情况。

（二）定位占用句柄的进程

由于所有服务都使用了NFS远程挂载，因此怀疑可能是其他服务占用了大量句柄。通过以下步骤进行排查：

• 在NFS服务器端，遍历各个进程的文件描述符：ls -l /proc/[pid]/fd | wc -l
• 发现taosd（TDengine的服务进程）存在异常高的文件句柄占用。

三、原因分析与解决方案

经过与TDengine官方团队沟通，得知这是TDengine3.3.2.0的一个已知bug，并建议升级到最新版本3.3.5.2以解决问题。

四、总结与预防措施

（一）总结

本次故障的根本原因是TDengine服务中的一个bug导致其占用了过多的文件句柄，进而影响到了同处于NFS存储上的Kafka服务。通过对日志的详细分析以及对系统资源使用的深入排查，最终确定了问题所在并成功解决了问题。

（二）预防措施

1. 定期更新组件版本：确保集群中的各个组件保持最新稳定版本，及时应用官方发布的补丁。
2. 监控系统资源使用：建立完善的监控机制，特别是对于关键资源如文件句柄、内存等的监控，以便提前预警潜在问题。
3. 优化配置参数 ：根据实际业务需求合理调整相关服务的配置参数，例如适当增加ulimit值，但需注意不要设置得过高以免引发其他风险。

---

以上就是关于此次Kafka因文件句柄数过多导致挂掉的问题记录及解决方案分享，希望能给有类似困扰的朋友带来帮助。