文件句柄耗尽导致“Too many open files”错误，需分层排查：先查系统级/proc/sys/fs/file-nr第二列活跃使用量，再查目标进程/proc/<PID>/limits软限制与/proc/<PID>/fd/实际占用，结合lsof定位高消耗进程及句柄类型，最后确认systemd、容器等环境配置是否真正生效。
遇到“Too many open files”报错、服务突然拒绝新连接或日志里频繁出现 socket 相关异常（如 java.net.SocketException、accept() failed (24: Too many open files)），大概率是文件句柄（file descriptor, fd）耗尽所致。排查重点不是“有没有报错”，而是“谁在用、用了多少、上限在哪、是否泄漏”。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
看系统级真实使用量：盯住 /proc/sys/fs/file-nr 的第二列
执行：cat /proc/sys/fs/file-nr
输出类似 15680 2842 2097152，三列含义依次是：
- 第一列：已分配的 fd 总数（含空闲）
- 第二列：当前正在被使用的 fd 数（即活跃占用）——这是关键指标
- 第三列：系统上限（fs.file-max）
如果第二列持续接近第三列的 80% 以上，说明全局资源紧张；若稳定在几百或几千，那问题基本不在系统层，要往下查进程。
查目标进程的实际限制与实时占用
不要只信 ulimit -n，它反映的是当前 shell 的软限制，对 systemd 启动的服务无效。
正确做法：
- 找出进程 PID（如 pgrep nginx 或 systemctl show --property MainPID nginx）
- 查它的运行时限制：cat /proc/<PID>/limits | grep "Max open files"
关注 Soft Limit 值，这才是进程实际能打开的上限。
- 查它此刻开了多少 fd：ls -l /proc/<PID>/fd/ | wc -l
这个数字应明显小于 Soft Limit。如果接近或等于，就触发了限制；如果远小于却仍报错，可能是 fd 类型异常（如 memfd）或内核参数 nr_open 不足。
定位高消耗进程和句柄类型
快速找出“吃”得最多的进程：lsof -n | awk '{print $2}' | sort | uniq -c | sort -nr | head -10
结果第一列是 fd 数量，第二列是 PID。
再针对可疑 PID 进一步分析：
- 看句柄分布：lsof -p <PID> | awk '{print $5}' | sort | uniq -c | sort -nr
可识别大量 IPv4（TCP/UDP）、REG（普通文件）、anon_inode（eventfd、timerfd）等，帮助判断是网络连接堆积、日志写满还是第三方库泄漏。
- 检查 TCP 连接状态：lsof -p <PID> -iTCP | awk '{print $9}' | sort | uniq -c
若大量 CLOSE_WAIT 或 TIME_WAIT，说明连接未正常关闭，可能是应用未调用 close() 或连接池配置不当。
确认配置是否真正生效
常见“改了没用”原因：
- 对 systemd 服务，/etc/security/limits.conf 完全无效。必须在 service 文件中加：LimitNOFILE=65535
并执行 systemctl daemon-reload && systemctl restart xxx。
- 容器环境（Docker/K8s），宿主机改 ulimit 或 file-max 没用，需在 docker run --ulimit 或 Pod 的 securityContext.fdsLimit 中显式设置。
- fs.file-max 调太大但 fs.nr_open 不够，会导致 ulimit -n 设不上去。检查：cat /proc/sys/fs/nr_open
若小于你设的 file-max，需通过内核启动参数（如 nr_open=2097152）调整，否则静默失败。
