当 Docker 容器突然出现 Too many open files、服务无法建立新连接、日志写入失败，甚至健康检查持续超时时，往往意味着进程可用的文件描述符已经耗尽。这里的“文件”不仅指普通文件，还包括网络套接字、管道、设备句柄及部分事件监听对象。🔍 如果只通过重启容器恢复服务，却不追查描述符的去向，故障通常还会再次发生。
一、先理解文件描述符限制
Linux 为每个进程维护文件描述符表，并通过软限制与硬限制控制可打开数量。软限制是进程当前生效的上限，硬限制则约束软限制能够提升到的最大值。进程的实际限制可从 /proc/PID/limits 查看，相关字段含义可参考 Linux proc_pid_limits 手册。
容器共享宿主机内核，因此需要同时关注三个层面：容器内进程的 nofile 限制、宿主机的系统级文件句柄容量，以及应用自身配置的连接数或文件数上限。只调整其中一层，不一定能彻底解决问题。
二、确认是否真的耗尽
第一步是在容器内查看当前 shell 的限制：
docker exec 容器名 sh -c 'ulimit -Sn; ulimit -Hn'
其中 ulimit -Sn 显示软限制，ulimit -Hn 显示硬限制。不过，进入容器后启动的 shell 不一定与业务主进程处于完全相同的运行环境，因此还应直接检查目标进程：
docker exec 容器名 sh -c 'cat /proc/1/limits | grep -i "open files"'
如果应用并非 PID 1，应先通过 ps 找到真实 PID，再读取对应的 limits 文件。接着统计进程当前持有的文件描述符数量：
docker exec 容器名 sh -c 'ls /proc/1/fd 2>/dev/null | wc -l'
若当前数量持续逼近软限制，基本可以确认异常与进程级 nofile 有关。注意，某些精简镜像没有 lsof、ps 或完整 shell，此时可以在宿主机使用 docker inspect 获取容器主进程 PID，再检查 /proc/该PID/fd。
三、定位哪些句柄没有释放
确认耗尽后，不要立即把上限调得很大，应先判断描述符类型。可在具备 lsof 的环境中执行：
lsof -p 目标PID
重点观察同一路径、同一远端地址或同一类型的条目是否异常集中。大量 REG 可能指向日志、缓存或临时文件未关闭；大量 TCP、IPv4、IPv6 条目通常与连接池、长连接或请求超时配置有关；大量 pipe、eventpoll、anon_inode 则可能涉及线程、子进程或事件监听器泄漏。
还可以直接检查描述符符号链接：
ls -l /proc/目标PID/fd | head
ls -l /proc/目标PID/fd | grep socket | wc -l
建议间隔数分钟重复采样。如果业务流量已经回落，而 FD 数量仍然只增不降，应优先怀疑资源泄漏。常见原因包括：文件流未在异常分支关闭、HTTP 响应体未释放、数据库连接未归还连接池、日志切割后旧文件仍被进程占用，以及不断创建监听器或子进程。🧩
四、排除宿主机系统级瓶颈
即使单个进程没有触碰 nofile，宿主机也可能面临系统级文件句柄压力。可以在宿主机执行：
cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max
file-nr 用于观察系统文件句柄分配情况，file-max 表示系统级上限。proc 文件系统是 Linux 内核向用户空间提供进程和系统信息的重要接口，详细说明可参考 Linux 内核 proc 文档。如果宿主机整体使用量异常，应扩大排查范围，找出占用最多的进程，避免误把其他服务造成的资源压力归因于当前容器。
五、正确调整 Docker 的 nofile
临时验证方案
使用 docker run 启动容器时，可以显式设置软限制和硬限制：
docker run --ulimit nofile=65536:65536 镜像名
这里的数值只是配置示例，不代表所有服务都应使用相同上限。应结合并发连接数、日志文件数量、数据库连接池规模和压力测试结果确定合理值，并预留必要余量。
Docker Compose 配置
使用 Compose 时，可在服务下配置 ulimits，并分别设置 nofile 的 soft 与 hard。修改后需要重新创建容器，仅重启旧容器未必会应用新的创建参数。完成部署后，应再次检查 /proc/1/limits，不要只根据配置文件判断是否生效。
设置 Docker 守护进程默认值
如果多个容器都需要统一限制，可以通过 Docker 守护进程的 default-ulimits 配置默认值。修改 daemon 配置前应先校验 JSON 格式，并评估重启 Docker 对现有业务的影响。Docker 支持在容器运行参数中设置资源限制，具体选项应以 docker container run 官方文档及当前部署版本为准。
不建议尝试在 Dockerfile 的 RUN 指令中永久设置 ulimit，因为构建步骤中的 shell 限制不会自然成为未来容器主进程的运行时限制。nofile 更适合在容器启动参数、Compose 编排文件或平台任务定义中配置。⚙️
六、建立监控与预防机制
- 监控使用率：持续采集进程 FD 当前值与软限制，使用率接近阈值时提前告警。
- 关联业务指标：同时观察并发连接、请求量、连接池、错误率和响应延迟，避免孤立分析。
- 执行趋势采样：关注 FD 是否随流量回落，识别缓慢增长型泄漏。
- 完善代码释放逻辑：确保文件、响应体、数据库连接和套接字在成功与异常路径中都能关闭。
- 开展压力测试：验证峰值并发下的描述符余量，而不是直接复制其他环境的配置。
总结
排查 Docker 的 Too many open files，推荐遵循“确认限制、统计占用、识别类型、检查宿主机、调整配置、持续监控”的顺序。提高 nofile 可以扩大运行空间，却不能修复连接或文件未释放的问题。✅ 最稳妥的处理方式，是先用证据判断属于容量不足还是资源泄漏，再通过运行时配置和应用修复共同解决，避免把一次故障变成周期性隐患。
