“too many open files”多数是单个进程ulimit卡住而非系统资源真耗尽，需分两层排查：先查系统级file-max和file-nr第二列已用量，再查目标进程fd数、/proc/pid/limits软限制及lsof分布类型。
进程报“Too many open files”时，别急着调大限制——先确认是不是真耗尽、谁在占、为什么不放。多数情况是单个进程的 ulimit 卡住，不是系统资源真用光。
看清楚当前用了多少、上限是多少
分两层查：系统级总量和进程级限制。
- 系统总共能开多少：运行 cat /proc/sys/fs/file-max，一般几百万够用；再看已分配了多少：cat /proc/sys/fs/file-nr（第二列是已用数）
- 目标进程当前开了多少 fd：lsof -p PID | wc -l 或更轻量的 ls /proc/PID/fd/ | wc -l
- 该进程实际生效的软硬限制：cat /proc/PID/limits | grep "Max open files"，注意 soft limit 才是真正起作用的值
- 快速找占用最多的进程：lsof -n | awk '{print $2}' | sort | uniq -c | sort -nr | head -10
定位泄漏源头：开的是什么、为什么不开就关不了
只看数量不够，得知道它在反复打开哪类资源。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 对高占用 PID，执行 lsof -p PID | awk '{print $5,$9}' | sort | uniq -c | sort -nr | head -20，重点看是否大量 IPv4/IPv6（连接未关闭）、pipe（管道堆积）、eventpoll（epoll 实例泄漏）、或 /tmp 下成批 .tmp 文件
- Java 进程可结合 jstack PID 和 lsof -p PID 对照线程栈与 fd 路径，看是否有阻塞在 I/O 或未关闭的流
- Go/Python 程序留意 defer 是否覆盖所有分支、goroutine panic 后资源是否清理、HTTP response body 是否被读取并关闭
临时止血和永久修复不能混着来
线上先保服务，再改配置；改完必须验证是否生效。
- 临时提升当前会话限制（供后续启动子进程用）：ulimit -n 65536，但无法影响已在运行的进程
- 永久改用户级限制：在 /etc/security/limits.conf 加 * soft nofile 65536 和 * hard nofile 65536，并确认 /etc/pam.d/common-session 包含 session required pam_limits.so
- systemd 服务必须单独配：/etc/systemd/system/xxx.service.d/override.conf 中写 LimitNOFILE=65536，然后 systemctl daemon-reload && systemctl restart xxx
- 别盲目调高 fs.file-max：2097152（2M）足够大多数场景，过高反而增加内核内存开销
别忽略配置陷阱和常见误操作
很多“改了没用”是因为没绕过 systemd 的限制机制或权限链路。
- 用 sudo 启动的服务，要检查 /etc/sudoers 是否有 Defaults env_reset 且未保留 ulimit
- systemd --user 服务需改 ~/.config/systemd/user.conf 中的 DefaultLimitNOFILE，而非 limits.conf
- 日志框架如 logback 若未启用 prudent=true 或 append=false，可能因并发写同一文件反复 open
- Nginx/Apache 连接突增时，若 worker_connections 和 ulimit 不匹配，也会快速打满句柄
