线上服务突然出现 too many open files，通常意味着进程无法继续获得文件描述符。这里的“文件”不只包括磁盘文件，还可能是网络套接字、管道、日志句柄、epoll、eventfd 等。Docker 容器共享宿主机内核，因此排查时不能只看容器配置，还要同时检查进程限制、Docker 配置和宿主机系统级容量。🔍
一、先判断耗尽发生在哪一层
Linux 的文件描述符限制至少涉及三层：单进程软限制、单进程硬限制，以及宿主机系统级上限。软限制是进程当前实际使用的边界，硬限制则约束软限制能够提升到的最大值。如果应用打开句柄的数量触及软限制，即使宿主机仍有余量，也可能立即报错。
进入容器后，可先执行：
docker exec 容器名 sh -c 'ulimit -Sn; ulimit -Hn'
随后查看主进程限制：
docker exec 容器名 sh -c 'cat /proc/1/limits | grep -i "open files"'
若容器内主进程的限制明显低于业务并发所需，应重点检查容器启动参数。如果进程限制仍有大量余量，则需要继续观察宿主机的全局文件句柄使用情况，避免误判。
二、确认当前打开了多少描述符
每个进程打开的描述符都会显示在 /proc/PID/fd 目录中，并以符号链接指向文件、套接字或匿名 inode；这一机制可参考 proc_pid_fd 手册。citeturn1search11
查看容器主进程当前数量：
docker exec 容器名 sh -c 'ls -1 /proc/1/fd 2>/dev/null | wc -l'
若应用并非 PID 1，应先通过 ps 找到真实业务进程，再替换对应 PID。建议间隔数分钟连续采样；如果数量只升不降，通常要怀疑连接、文件流或监听器未正确关闭。📈
进一步识别句柄类型，可执行：
docker exec 容器名 sh -c 'ls -l /proc/1/fd 2>/dev/null | head -n 50'
大量 socket 可能与连接池、长连接或下游超时有关；大量普通文件可能指向日志轮转、临时文件或文件流泄漏；大量 anon_inode 则应检查 epoll、inotify、eventfd 等对象的创建与释放。
三、检查宿主机是否整体承压
在宿主机执行：
cat /proc/sys/fs/file-nr
cat /proc/sys/fs/file-max
前者可辅助观察系统文件句柄分配情况，后者表示系统级容量配置。Linux 内核 /proc 文档说明了 procfs 可用于读取系统与进程信息，并可通过 /proc/sys 管理部分内核参数。citeturn1search7
还可以使用：
lsof -nP | wc -l
lsof -nP -p 进程PID
若 lsof 输出量很大，生产环境应限定 PID 或容器范围，避免一次全量扫描带来额外开销。发现宿主机整体接近上限时，应找出消耗最多的进程，而不是只重启报错容器。⚠️
四、正确调整 Docker 的 nofile 限制
临时验证可在创建容器时指定：
docker run --ulimit nofile=65535:65535 镜像名
该数值仅为写法示例，实际值应根据峰值并发、连接模型、监控数据和宿主机容量评估，不能机械照搬。
使用 Compose 时，可在服务的 ulimits 下配置 nofile 的 soft 与 hard；需要统一默认值时，也可在 Docker daemon 配置中设置 default-ulimits，再按变更流程重启 Docker。已有容器通常需要重新创建才能可靠应用新的启动级限制。Docker 强调容器资源约束需要结合宿主机内核能力进行配置，详情可查看 Docker 资源约束文档。citeturn1search1
注意：提高 nofile 只能扩大可用空间，无法修复文件描述符泄漏。若句柄数量持续线性增长，单纯调大限制只会延后故障发生时间。
五、从应用层定位根因
- 检查 HTTP、数据库、Redis、消息队列等客户端是否正确复用连接，并设置连接池上限。
- 确认文件流、响应体、压缩流和目录遍历对象在异常分支中也能关闭。
- 核对日志轮转后旧文件是否仍被进程占用，可使用 lsof +L1 查找已删除但尚未释放的文件。
- 检查连接超时、重试策略和下游故障，防止大量半关闭或长期等待的套接字堆积。
- 为进程文件描述符数量、使用率和增长速度建立监控，而不是只监控 CPU 与内存。🛠️
六、推荐的处置顺序
- 记录报错时间、容器 ID、镜像版本和近期发布变更。
- 核对容器内 ulimit 与 /proc/PID/limits，确认是否触及单进程边界。
- 统计 /proc/PID/fd，并按文件、socket、pipe、anon_inode 分类观察。
- 检查宿主机 file-nr、file-max 及其他高消耗进程。
- 短期通过限流、回滚、滚动重启或合理提升 nofile 恢复服务。
- 长期修复资源释放逻辑，并通过压测验证句柄能够稳定回落。
总结
排查 Docker 的 too many open files，核心是区分“限制过低”和“资源泄漏”。先比较当前使用量与进程限制，再核对宿主机全局容量，最后根据描述符类型追踪应用行为。合理提高 nofile 可以改善正常高并发场景，但只有关闭泄漏、控制连接和建立监控，才能真正避免异常反复出现。✅
