ECS容器服务抛出java.io.IOException: Too many open files问题排查咨询

1. 确认进程当前文件句柄使用基础信息 #

• 进入ECS容器后，执行ps -ef | grep java获取服务进程ID（记为$PID）
• 查看进程已占用文件句柄总数：lsof -p $PID | wc -l
• 查看进程对应的打开文件数限制：cat /proc/$PID/limits | grep "Max open files"，确认是否已触碰到软/硬限制阈值

2. 分类统计打开文件类型，定位占用来源 #

执行以下命令输出各类文件的数量排序，判断高占比资源类型：

lsof -p $PID | awk '{print $5}' | sort | uniq -c | sort -nr

不同类型对应排查方向：

• REG（普通文件）：优先检查业务代码的文件读写、日志写入逻辑，是否存在未正确关闭IO流的问题，可执行lsof -p $PID | grep REG查看重复打开的文件名，对应到具体业务代码
• SOCK（网络套接字）：对应TCP连接、数据库连接、HTTP调用、MQ连接等网络资源，可结合netstat -natp | grep $PID查看对端IP、端口，确认是否存在连接池配置不合理（最大连接数超过ulimit阈值）、空闲连接回收逻辑失效、请求未正确释放连接的问题
• FIFO/pipe（管道文件）：排查进程间通信相关逻辑是否存在资源未释放问题
• CHR（字符设备文件）：排查硬件交互类资源的占用逻辑

3. 验证容器级限制配置 #

ECS容器的ulimit限制可能被编排配置覆盖，而非使用默认值：

• 若为Docker直接启动的容器，检查启动参数是否配置了--ulimit nofile
• 若为K8s编排的ECS容器，检查Pod yaml的securityContext配置下是否设置了ulimit相关参数，确认容器级限制是否符合预期

4. 根因验证 #

针对排查到的可疑逻辑，在线下环境模拟相同的并发量、请求量，监控文件句柄变化趋势：

• 若句柄随请求量线性增长且请求结束后不回落，可确定为资源泄漏问题，修复对应逻辑即可
• 若句柄仅在业务峰值时触碰到限制，无持续增长趋势，属于合理业务量级超过默认限制的场景，再调整ulimit配置即可

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