提升 nginx 文件 i/o 效率的关键是让文件元数据常驻内存、减少系统调用、避免冗余拷贝，其中 open_file_cache 是最直接有效的手段，配合前缀匹配、日志缓存与内核调优才能充分发挥性能。
提升 Nginx 文件 I/O 效率，关键不是堆参数，而是让文件元数据常驻内存、减少系统调用、避免冗余拷贝。描述符缓存（open_file_cache）是其中最直接有效的手段，配合路径匹配、日志控制和内核协同，才能真正释放磁盘与内存的协同潜力。
用好 open_file_cache 缓存句柄与元数据
每次请求静态资源时，Nginx 默认都要执行 open() 和 stat() 系统调用——查文件是否存在、权限是否合法、修改时间是否变化。高并发下这会迅速成为瓶颈。启用 open_file_cache 可将这些操作结果缓存起来，复用句柄与元信息。
-
基础配置：设置
open_file_cache max=10000 inactive=60s;，最多缓存 1 万个文件项，60 秒未访问即淘汰 -
主动验证有效性：加
open_file_cache_valid 60s;，每分钟检查一次缓存项是否仍对应真实文件（如防止文件被删后继续命中） -
过滤低频访问：配
open_file_cache_min_uses 2;，同一文件至少被访问两次才进缓存，避免缓存抖动 -
别漏掉错误结果：开启
open_file_cache_errors on;，把“文件不存在”也缓存住，防恶意路径扫描反复穿透磁盘
静态路径匹配要快，别让正则拖慢 stat
匹配规则本身不读文件内容，但正则表达式每次都要做字符串解析和模式比对；更隐蔽的是，它还会触发大量 stat() 调用——比如判断 /assets/app.js 是否存在时，Nginx 会逐级检查目录权限与可读性。前缀匹配则无此开销。
- ✅ 推荐写法：
location /static/ { ... }或location = /favicon.ico { ... } - ❌ 避免写法：
location ~* \.(js|css|png|jpg)$ { ... }—— 即使只服务几百个静态文件，正则在万级 QPS 下也会显著抬高 CPU 和 I/O 延迟 - 若必须按扩展名分流，可先用前缀隔离（如
/media/），再在子 location 中用正则做精细控制
关闭或缓存日志，减少隐性 I/O 压力
access_log 看似只是写一行文本，但它背后要频繁 stat() 日志文件是否存在、是否可写、inode 是否变更；还要处理轮转、锁竞争、缓冲区刷新等。纯静态服务中，这是典型的“低价值高开销”操作。
- CDN 边缘节点、前端托管服务建议直接关掉：
access_log off; - 若需保留日志，启用日志文件缓存：
open_log_file_cache max=1000 inactive=1h valid=1h min_uses=2;，避免每次写日志都重新打开文件 - 日志格式尽量精简，避免记录非必要字段（如
$request_time在边缘层通常无需每条都记）
协同内核与 worker 进程，让 page cache 更高效
Nginx 的 sendfile、open_file_cache 都高度依赖内核 page cache。如果系统频繁回收 dentry/inode 缓存，或因 swap 挤占内存，所有优化都会打折扣。
- 限制 swap 使用：
vm.swappiness=1，让内存优先留给文件缓存 - 降低 inode/dentry 回收倾向：
vm.vfs_cache_pressure=50 - 为 worker 绑定物理核：
worker_processes auto;+worker_cpu_affinity auto;（Nginx ≥ 1.19.10），避免跨核迁移导致 L1/L2 缓存失效 - 挂载 SSD 分区时加上
noatime（禁用访问时间更新），XFS 还可加logbufs=8 logbsize=256k减少日志开销
