启用 open_file_cache 可显著减少 open() 和 stat() 系统调用，需同时配置 max、inactive、valid、min_uses 和 errors 五项参数，并配合 sendfile、tcp_nopush 等优化 IO 性能。

直接启用 open_file_cache 是最有效的方式——它不缓存文件内容，而是把文件是否存在、大小、修改时间、权限、甚至“打不开”这种错误结果都记在内存里，后续请求直接复用，跳过 open() 和 stat() 系统调用。对图标、JS、CSS、index.html 这类高频小文件特别管用。

必须配齐的四个核心参数

单独写 open_file_cache on; 不生效。需在 http 或 server 块中同时配置以下四项：

• 容量与淘汰：open_file_cache max=5000 inactive=60s; —— 最多缓存 5000 个条目；60 秒内未被访问的自动清理
• 元数据校验周期：open_file_cache_valid 30s; —— 每 30 秒检查一次缓存中的文件是否被删改或权限变化
• 准入门槛：open_file_cache_min_uses 2; —— 同一文件需在 inactive 时间窗内被访问至少 2 次才进缓存，防冷文件占位
• 错误也缓存：open_file_cache_errors on; —— 把 404、403 等失败结果也记下来，避免反复探测同一不存在路径

按场景调整关键数值

参数不是固定值，要结合业务节奏调：

• 如果静态资源平均 10 秒就被刷一次（如网关健康检查），inactive 设为 20–30s 更合适，太长会导致缓存滞留过期信息
• valid 不宜超过 inactive 的一半；设太短（如 5s）会频繁轮询，增加 CPU 开销；设太长（如 5 分钟）可能返回已删除文件的 200 响应
• 内存充裕且资源总数超万（如大型前端项目），可将 max 提至 10000–50000；每个条目约占 1KB，注意别吃光可用内存
• 若日志中频繁出现 could not build optimal open_file_cache，可能是系统 inotify 限制低了，需调大 /proc/sys/fs/inotify/max_user_watches

搭配使用效果更明显

单开 open_file_cache 是基础，再加这几项能进一步压降 IO 和系统调用：

• sendfile on; —— 让内核直接把文件内容发给客户端，绕过 Nginx 用户态拷贝，对小文件提升显著
• tcp_nopush on; —— 合并多个小响应包，减少 TCP 小包数量，降低网络栈压力
• access_log off; log_not_found off; —— 在纯静态资源配置块（如 location ~ \.(js|css|png)$）中关闭日志，省掉磁盘写入开销
• 对明确不变更的路径（如 /healthz、/index.html），可在对应 location 块里单独启用缓存，避免影响动态路径

验证是否真正起效

不能只看配置 reload 成功，要观察实际变化：

• 用 lsof -p $(pgrep nginx) | grep REG | wc -l 对比开启前后 worker 进程打开的普通文件数——稳定下降说明 fd 复用成功
• 压测时关注 iostat -x 1 中的 %util（磁盘利用率）和 sysstat 中的 %sys（系统调用占比）是否明显降低
• 开启调试日志（需编译含 --with-debug）并配置 open_file_cache_log on;，从 error_log 查看 cache hit/miss 统计