这类问题我又碰上了一次。业务日志突然刷句柄不足，进程还在但请求全部失败，重启之后恢复，隔一段时间同样的错误又出现。
真正麻烦的地方在于，几个原因的现象几乎一样。连接没有关闭，套接字句柄持续累积；日志文件被频繁打开却没有释放；进程的句柄上限本身设置过低。
动手时先统计进程打开的句柄类型
ls -l /proc/$(pidof app)/fd | awk '{print $11}' | sort | uniq -c然后看套接字数量与状态
ss -s再往下确认上限配置
grep files /proc/$(pidof app)/limits剩下的就是重启服务后观察增长
systemctl restart app这类改动我都写进变更记录，过两周再出问题时能对上号。
我习惯把每一步的执行时间和结果记在一边，后面复盘省事。
改完先别撤，确认这几项。句柄总数稳定在合理区间，不再随时间单调增长，报错消失。
补一句。只调大上限会把问题推迟，如果是真泄漏迟早还会撞墙；先用句柄统计找到泄漏的那一类才是正解。改动前把原配置备份一份，出问题能马上回滚，这比任何技巧都实用。