文件句柄耗尽需定位干预而非脚本修复：脚本应监控fd使用率、分类统计句柄类型、执行安全降载（如kill -usr1、reload）、检查三层系统限制并输出整改建议。
文件句柄耗尽不是脚本能“修复”的故障，而是必须先定位、再干预的系统级资源瓶颈。运维脚本的作用是快速发现异常、辅助判断根因、触发安全响应，而不是直接“解决”耗尽本身。
实时监控进程句柄使用率
脚本应定期采样关键服务进程的 fd 数量，与软限制对比预警：
- 用 cat /proc/
/limits | awk '/Max open files/ {print $4}' 获取该进程硬限制 - 用 ls -1 /proc/
/fd 2>/dev/null | wc -l 统计当前打开数 - 当使用率持续 ≥85%，记录日志并触发告警（如发钉钉/邮件）
区分句柄类型，缩小问题范围
仅知道“fd多”没用，脚本要自动分类统计，避免误判：
- 对目标进程执行 lsof -p
2>/dev/null | awk '{print $5}' | sort | uniq -c | sort -nr | head -5 - 若输出含大量 IPv4 或 TCP，说明是网络连接未释放（如短连接风暴、连接池泄漏）
- 若含大量 REG 且路径带 (deleted)，说明是日志轮转后文件未关闭，空间和句柄双占
安全响应：不重启，先降载再处置
脚本不能擅自 kill -9，但可执行低风险干预：
- 对 Java/Go 等支持热重载的日志进程，调用 kill -USR1
触发日志 reopen（释放 deleted 句柄） - 对 Nginx/Apache，执行 nginx -s reload 或 systemctl reload httpd，平滑重建 worker 进程
- 若确认是临时性 spike（如批量任务），可临时扩大该服务 systemd 的 LimitNOFILE（需配合 systemctl daemon-reload）
关联检查系统级限制是否过低
脚本应一并验证三层限制是否合理，避免“调了 ulimit 却无效”：
- 查用户级：ulimit -n（当前 shell）
- 查服务级：systemctl show --property=LimitNOFILE
- 查全局级：sysctl fs.file-max
- 任一值明显低于业务峰值并发（如 5000+ 连接的服务仍设为 1024），则写入整改建议到报告
