确认文件描述符耗尽，需先执行 ulimit -n 和 ls /proc/1/fd | wc -l 比对使用率是否≥90%，再结合 EMFILE 等日志报错锁定；须同步检查 dockerd 自身限制，避免守护进程也卡住。

崩溃不是因为代码写错了，而是系统拒绝分配新文件描述符。Too many open files 是资源耗尽的明确信号，不是异常，而是内核在“关门”。

临时调高 ulimit -n 只能延缓崩溃。不查泄漏源，等于给漏水的船只顾舀水，却不停止进水。

先判断：是否真的是 fd 耗尽

怎么确认真是 fd 耗尽，而不是其他故障伪装？

别一看到服务挂了就重启。应先验证是否真卡在 fd 上。

• 进入进程所在环境执行 ulimit -n，查看软限制值，常见为 1024、4096
• 查看当前使用量：ls /proc/1/fd | wc -l（PID 1 是容器主进程；宿主机上用 lsof -p $PID | wc -l）
• 若使用量 ≥ 90% 的 ulimit -n 值，且日志里出现 EMFILE、accept: too many open files 或 ja va.io.IOException: Too many open files，基本可以锁定
• 顺手检查 Docker daemon 自身限制：cat /proc/$(pgrep dockerd)/limits | grep "Max open files"，避免守护进程自己也卡住

配置不生效的常见原因

为什么改了 limits.conf 还没生效？systemd 服务常被忽略的关键点

systemd 管理的服务，如 nginx、mysqld、myapp.service，默认不读取 /etc/security/limits.conf。

哪怕写了 * soft nofile 65535，也不会自动生效。

• 必须显式在服务单元中配置：sudo systemctl edit myapp.service，添加：

  [Service]
  LimitNOFILE=65535

• 如果服务由用户启动，比如 www-data，需同时配置 /etc/security/limits.conf 和 systemd override，两者缺一不可
• 修改后必须执行 systemctl daemon-reload && systemctl restart myapp，reload 不等于 restart
• 验证是否生效：cat /proc/$(pgrep -f myapp.jar)/limits | grep "Max open files"，查看 Soft Limit 列是否为预期值

定位泄漏源

泄漏点在哪？lsof 输出怎么看才不被误导

lsof -p $PID 往往会输出几百行。重点不是数总量，而是看类型分布和异常路径。

• 高频 IPv4 或 IPv6：说明连接未关闭，可能是 HTTP 客户端没设 Connection: close、没复用连接池、或 gRPC 长连接未正确 shutdown
• 大量 REG 类型指向 /tmp 或日志目录：常见于未关闭的临时文件、日志轮转时旧文件句柄未释放，如 logback 的 prudent=true 缺失
• 一堆 pipe 或 eventpoll：Go 程序 goroutine panic 后 defer 未执行，或 Python 异步任务未 await 就 return
• 出现 deleted 标记的文件：日志被 logrotate 切走但进程还在写，这是典型泄漏场景，需发 SIGUSR1 通知重开句柄

容器环境要分层处理

容器环境下必须分层调优，单改一处等于白做

Docker 不是黑盒。fd 限制从下到上共三层，漏一层就会断在中间。

• 宿主机全局上限：fs.file-max（写入 /etc/sysctl.conf 并 sysctl -p）
• Docker daemon 自身限制：在 /etc/systemd/system/docker.service.d/override.conf 加 LimitNOFILE=1000000，否则它连给容器分配的资格都没有
• 容器启动参数：用 --ulimit nofile=65536:65536 或 docker-compose 的 ulimits 字段，硬限制不能低于软限制
• 容器内应用仍需主动管理资源。调高限制只是买时间，不修复泄漏，迟早再爆

别忽视“延迟显现”问题

最容易被忽略的，其实是泄漏的“延迟显现”。Go 的 runtime GC、Ja va 的 finalizer、Python 的循环引用，都可能让 lsof 里看起来句柄还在，但实际上早就没有业务用途了。

这时单看数量远远不够。 还得结合 strace -p $PID -e trace=open,openat,socket,close 去抓实时系统调用，才能判断到底是关晚了、漏关了，还是压根就没关。

《夸克》非常好用的免费AI浏览器

下载APP查看