“too many open files”需四层限制对齐：内核、用户、服务管理器、应用自身。依次检查/proc/sys/fs/file-nr、ulimit -n、/proc/pid/limits，并同步配置sysctl、limits.conf、systemd limitnofile及应用层参数，最后验证并监控fd使用与泄漏。
“Too many open files”不是配置漏了，而是四层句柄限制没对齐——内核、用户、服务管理器、应用自身必须全部调通，缺一不可。
先确认到底卡在哪一层
别急着改配置，先分层定位瓶颈点：
- 查系统全局：运行 cat /proc/sys/fs/file-nr，看三个数字（已分配｜未使用｜系统上限），若第一个接近第三个，说明内核级已满
- 查当前用户限制：用目标用户（如 www、nginx）执行 ulimit -n，注意必须是启动服务的同一用户会话
- 查进程实际生效值：找到服务 PID 后，运行 cat /proc/PID/limits | grep "Max open files"，这才是进程真正拿到的数值
- 查服务是否绕过 PAM：如果用 systemd 启动（如 Nginx、Swoole、Tomcat），LimitNOFILE 必须显式设置，否则默认仍是 1024
四层限制必须同步调整
每层都设到目标值（例如 65536 或更高），不能只改其中一两处：
- 内核层：编辑 /etc/sysctl.conf，添加 fs.file-max = 1000000，再执行 sysctl -p
-
用户层：在 /etc/security/limits.conf 中写入（以 nginx 用户为例）：
nginx soft nofile 65536
nginx hard nofile 65536
并确认 /etc/pam.d/common-session 或 /etc/pam.d/login 中有 session required pam_limits.so -
服务管理器层：若用 systemd，编辑服务单元文件（如 /etc/systemd/system/nginx.service），在 [Service] 下加：
LimitNOFILE=65536
然后执行 systemctl daemon-reload && systemctl restart nginx - 应用层：Nginx 需在 main 块中加 worker_rlimit_nofile 65536;；Swoole/Tomcat 则需在启动脚本开头加 ulimit -n 65536
验证与日常监控不能少
改完不验证等于白改，建议每次调整后做三件事：
- 重启服务后，立刻检查 cat /proc/PID/limits，确认 Max open files 已更新
- 用 lsof -p PID | wc -l 统计当前打开数，观察是否随请求增长而持续上升（提示泄漏）
- 加个简单巡检脚本，定期记录 /proc/sys/fs/file-nr 和关键进程 fd 数，配合 Prometheus 或日志告警
别忽略程序本身的问题
如果 fd 数随时间线性上涨且不回落，大概率是代码泄漏：
- Java 应用重点查未关闭的 InputStream/OutputStream/Socket/Connection
- Python 推荐统一用 with open(...)，避免裸 open + forget close
- Node.js 注意 fs.createReadStream 后是否调用了 .destroy() 或监听了 close 事件
- Nginx 场景下，若缓存目录含数万小文件，还要配好 open_file_cache，减少重复 open
