Linux进程fd耗尽致“Too many open files”错误，需按确认耗尽、定位占用、分析未释放、优化四步排查：查系统/进程级fd限制与使用量，用lsof等定位高占用进程及文件类型，排查Web服务器、Java/Go/Python常见泄漏场景与配置陷阱，临时扩容或重启服务，长期需监控、代码资源自动管理及strace验证。
Linux进程句柄过多导致文件描述符（file descriptor，简称fd）耗尽，常表现为“Too many open files”错误，服务响应变慢甚至崩溃。核心排查思路是：确认是否真耗尽、定位谁在占用、分析为何不释放、针对性优化。
确认系统级和进程级fd使用情况
先看全局限制和实际使用量：
-
系统最大可打开fd数：
cat /proc/sys/fs/file-max -
当前已分配fd总数：
cat /proc/sys/fs/file-nr（输出三列，第二列为已分配未释放的fd数） -
单个进程默认软/硬限制：
ulimit -n（当前shell环境），或查具体进程：cat /proc/<pid>/limits | grep "Max open files" -
某进程当前打开fd数量：
ls /proc/<pid>/fd/ | wc -l，或更直观：lsof -p <pid> | wc -l（需安装lsof）
定位高fd占用的进程和文件类型
不要只盯PID，要看出“开什么、为什么开这么多”：
- 列出所有进程按fd数排序：
ls /proc/[0-9]*/fd/ 2>/dev/null | cut -d'/' -f3 | sort | uniq -c | sort -nr | head -10 - 对可疑PID，查看其fd详情：
lsof -p <pid> | awk '{print $5,$9}' | sort | uniq -c | sort -nr | head -20（统计文件类型和路径） - 重点关注：socket连接（IPv4/IPv6）、管道（pipe）、eventpoll（epoll实例）、inotify实例、大量临时文件或日志轮转未关闭的句柄
检查常见泄漏场景和配置陷阱
fd不释放不一定是代码bug，也可能是配置或使用方式问题：
-
Web服务器/反向代理：Nginx/Apache未调高
worker_connections或ulimit -n，连接数突增时快速占满；长连接未合理超时也会堆积 -
Java应用：未关闭InputStream/OutputStream/Socket，或使用了未设maxIdle的连接池（如DB连接、HTTP client），或logback/log4j中文件appender未启用
append=false或prudent=true导致重复打开 - Go/Python等语言：defer未覆盖所有分支、goroutine panic后资源未清理、异步I/O未正确await/close
-
系统级误配：/etc/security/limits.conf 设置了 soft nofile 但未重启登录会话，或systemd服务未继承limit（需在service文件中加
LimitNOFILE=65536）
临时缓解与长期修复建议
线上先保服务，再根治问题：
-
临时扩容：对运行中进程无法直接改limit，但可调高系统级
/proc/sys/fs/file-max（需root），或重启对应服务并确保启动环境已设好ulimit -
快速回收异常fd：确认无业务影响前提下，可用
gdb -p <pid>进入后执行call close(<fd_num>)（慎用，仅调试） -
监控固化：在Zabbix/Prometheus中采集
/proc/sys/fs/file-nr和各关键进程/proc/PID/fd/数量，设置阈值告警（如>80% soft limit） -
代码层防御：统一使用try-with-resources（Java）、with语句（Python）、defer（Go）；上线前用
strace -e trace=open,openat,close -p <pid>抽样观察fd生命周期
不复杂但容易忽略：很多问题不是“开太多”，而是“该关没关”。从lsof结果里找重复路径、长时间存在的socket、状态为"can't identify protocol"的fd，往往就是突破口。
