启用 open_file_cache 可显著降低 stat()/open()/close() 系统调用频次，提升小文件高频访问性能；它仅缓存文件元数据和描述符，不缓存内容，并需合理配置 max、inactive、valid 等参数及协同 noatime、worker_rlimit_nofile 等优化。
直接启用 open_file_cache 是提升磁盘读写性能最有效、成本最低的手段之一——它不减少实际文件读取，但大幅降低 stat()、open()、close() 这类元数据系统调用频次，尤其在小文件高频访问场景下，iowait 和 CPU 软中断会明显下降。
缓存什么：只缓元数据，不缓内容
open_file_cache 缓存的是文件是否存在、大小、权限、最后修改时间等属性，以及已打开的文件描述符（fd），不是文件内容本身。这意味着：
- 命中缓存后，Nginx 可跳过一次
stat()系统调用，直接确认文件可读、未被删改； - 若缓存中已有有效 fd，可复用句柄，避免重复
open()/close()开销； - 对静态资源服务、fastcgi 缓存文件检查、proxy cache 文件验证等路径都生效。
关键参数配置逻辑
参数不是越大越好，需结合磁盘 I/O 特性与业务访问模式来设：
- max=20000：建议设为预期活跃文件数的 1.5–2 倍（如站点有 8000 个常用 JS/CSS/图片，设 12000–16000 即可）；超大会占用过多内存且增加哈希查找延迟；
-
inactive=30s：适用于高更新频率场景（如 CMS 静态页每分钟生成）；若资源稳定（如 CDN 边缘节点），可放宽至
60s或120s； -
open_file_cache_valid 60s：每 60 秒主动
stat()一次缓存项，校验文件是否仍存在或被修改；太短加重 I/O，太长导致 stale 检测滞后； - open_file_cache_min_uses 2：同一文件至少被连续访问 2 次才进缓存，防低频文件污染空间；
- open_file_cache_errors on：把 404、403 等错误也缓存，避免反复探测不存在路径（如 favicon.ico、robots.txt 缺失时）。
配合底层磁盘与内核优化
仅配 open_file_cache 不足以榨干 I/O 性能，需协同调整：
- 确保静态文件所在分区挂载时含
noatime，禁用访问时间戳更新，消除大量 write I/O； - 若使用 SSD，建议启用
discard（或定期 fstrim），维持长期随机写性能； - worker 进程需足够文件句柄：设置
worker_rlimit_nofile 65535，并确认/proc/sys/fs/file-max足够； - 避免和
sendfile on冲突：当启用 sendfile 时，Nginx 会绕过用户态读取，此时 open_file_cache 对内容读取无影响，但仍对存在性判断和错误缓存有效。
验证是否生效
可通过以下方式观察效果：
- 用
pidstat -d 1查看每秒 I/O 请求次数（%util 和 tps），开启前后对比； - 用
perf record -e syscalls:sys_enter_stat,syscalls:sys_enter_openat -a sleep 30抓取系统调用频次，应显著下降； - 添加
add_header X-Open-Cache "$upstream_cache_status";（需配合 proxy_cache）或自定义日志变量，间接反映元数据判断效率。
