排查open_log_file_cache句柄泄漏需聚焦三点：一查缓存是否生效（strace验证openat调用频次及配置启用状态），二查动态路径变量致缓存膨胀（lsof统计句柄数并检查/proc/PID/fd/），三查轮转后旧句柄残留（比对inode及确保kill -USR1触发fd刷新）。
排查 open_log_file_cache 缓存失效引发的句柄泄漏，关键不是“缓存失效”本身导致泄漏，而是配置不当让缓存无法及时清理、或日志路径动态变化后缓存失控，最终使大量文件描述符长期滞留未释放。重点看三点：缓存是否真在起作用、是否因路径变量爆炸式增长、是否轮转后旧句柄持续写入。
确认缓存是否实际生效
先验证 Nginx 是否真的在用缓存，而不是每次请求都重新 open 日志文件：
- 用
strace -e trace=openat,closeat -p $(pgrep nginx | head -1)抓一个 worker 进程，观察高并发下是否有大量重复openat(..., "/var/log/nginx/xxx.log", ...)调用；若频繁出现，说明缓存没生效或被绕过 - 检查配置中是否启用了
open_log_file_cache，且没被更外层（如 http 块）的off覆盖；注意该指令不能出现在 if 或 map 块内 - 确认日志路径不含未预期的变量（比如误写
$request_uri），否则每个不同 URI 都生成独立路径，缓存条目数会随请求多样性线性暴涨
检查动态路径导致的缓存膨胀
当 access_log 路径含变量（如 $host、$time_iso8601），变量展开后路径不同即视为不同文件，缓存按完整路径索引：
- 执行
lsof -p $(pgrep nginx | head -1) | grep log | wc -l，若数值远超实际日志文件数（比如有 50 个 server 块但句柄数达 2000+），大概率是路径变量导致缓存条目失控 - 用
ls -l /proc/$(pgrep nginx | head -1)/fd/ | grep log查看具体打开了哪些日志路径，确认是否存在大量形如xxx-access-2026-10-09T22:xx:xx.log的瞬时文件 - 建议统一使用固定路径写日志（如
/var/log/nginx/access.log），或至少用稳定变量（如$hostname）替代高基数变量
验证日志轮转后缓存是否残留旧句柄
轮转后若未触发 kill -USR1 或 SIGHUP，Nginx 仍会向旧文件描述符写入，造成“句柄未释放”假象（实为继续写已删除文件）：
- 轮转前记下某日志文件的 inode：
ls -i /var/log/nginx/access.log - 执行轮转（如
logrotate或手动mv+kill -USR1），再查同路径 inode 是否变化 - 若 inode 不变但文件已不存在，说明 Nginx 仍在往已删除文件写入——此时
/proc/PID/fd/中对应条目会显示deleted，数量不会自动下降 - 必须确保轮转脚本末尾调用
kill -USR1 $(cat /var/run/nginx.pid)，否则缓存中的 fd 不会刷新
核对缓存参数是否合理
参数失配会让缓存“既不淘汰也不校验”，间接导致句柄堆积：
-
max过小（如默认 100）：高频多租户场景下频繁 LRU 淘汰，失去缓存意义；建议设为实际日志文件数 × 2～3（如 1000） -
inactive过长（如 300s）：低频日志（如错误日志）长时间挂载在缓存中，fd 无法释放；建议设为 20s～60s -
min_uses过低（如 1）：一次访问就进缓存，把临时路径也塞进去；建议 ≥ 2，过滤掉偶然请求 -
valid过长（如 10m）：轮转后需等很久才检测到文件消失；建议 ≤ 1m，确保快速感知变更
