怎么利用 open_file_cache 缓存热点静态文件描述符及修改时间彻底消除频繁磁盘 open 损耗

必须配齐max、inactive、valid、min_uses、errors五项参数才能使open_file_cache生效，它仅缓存fd、大小、mtime、存在性及权限等元数据，跳过open()/stat()调用以消除磁盘open损耗；events为推荐增强项，还需配合worker_rlimit_nofile、sendfile等协同优化。

直接配齐五个参数才能让 open_file_cache 真正生效，它不缓存文件内容，只缓存文件描述符（fd）、大小、最后修改时间（mtime）、存在性、权限等元数据——这些正是 Last-Modified、Content-Length 和 404/403 判定所依赖的信息。跳过重复的 open() 和 stat() 系统调用，才是彻底消除磁盘 open 损耗的核心。

必须同时配置的五个基础参数

单独写 open_file_cache on; 完全无效。以下五项需全部出现在 http 块中：

• 容量与淘汰策略：open_file_cache max=10000 inactive=60s;——最多缓存 1 万个条目；60 秒内未被访问即标记为非活跃，等待清理
• 元数据主动校验周期：open_file_cache_valid 30s;——每 30 秒检查一次缓存项对应文件是否仍存在、大小或 mtime 是否变化，避免返回过期信息
• 准入门槛防污染：open_file_cache_min_uses 2;——同一文件需在 60 秒内被至少访问 2 次才进入缓存，过滤爬虫乱扫或单次请求
• 错误结果也缓存：open_file_cache_errors on;——把 “404 文件不存在”“403 权限拒绝” 等错误状态一并缓存，防止反复触发磁盘查询
• 变更感知增强项（推荐）：open_file_cache_events on;——依赖 inotify 实时监听文件变更，比轮询更及时；若环境不支持可关闭，靠 valid 轮询兜底

让缓存真正复用 fd 和 mtime 的关键配合

仅配置 open_file_cache 不足以释放全部收益，还需底层联动：

• 确保 worker_rlimit_nofile 65535;，否则缓存再多句柄也无法实际打开
• 静态资源 location 中启用 sendfile on;，让内核直接 DMA 传输，绕过用户态拷贝，与 fd 缓存形成黄金搭档
• 关闭无关日志：access_log off; log_not_found off;，减少磁盘写入干扰
• 挂载文件系统时加 noatime，避免每次读取都更新访问时间，降低额外 I/O
• 若启用 events，检查 /proc/sys/fs/inotify/max_user_watches 是否足够（建议 ≥ max × 1.5）

按热点静态文件特征调优参数

不同访问模式对缓存行为影响显著，不能套用默认值：

• SPA 首页及 JS/CSS 热点资源：设 max=2000 inactive=30s valid=20s，短窗口提升复用率，匹配前端发版节奏
• CDN 回源节点（含大量图标/字体）：增大容量，用 max=8000 inactive=60s valid=60s min_uses=3，提高命中率
• 健康检查路径（如 /healthz）：设 min_uses=3 inactive=30s，过滤瞬时抖动，避免误入缓存
• 频繁轮转的日志或临时文件目录：缩短 inactive=20s valid=10s，防止缓存残留失效路径

验证缓存是否真正起效

没有直接日志输出，但可通过以下方式确认：

• 用 lsof -p $(cat /var/run/nginx.pid) | wc -l 观察句柄数是否趋于稳定（不再随 QPS 线性增长）
• 用 perf stat -e syscalls:sys_enter_openat,syscalls:sys_enter_statx -p $(cat /var/run/nginx.pid) 对比开启前后系统调用次数
• 观察 iostat -x 1 中 %util 和 r/s 是否明显下降，尤其在小文件密集请求时段
• 检查响应头中 Last-Modified 是否始终一致且准确，说明 mtime 已从缓存读取而非实时 stat