启用 open_file_cache 可压平高并发下日志写入引发的 cpu 小毛刺和 i/o 波动，它仅复用已打开的文件描述符和元信息，跳过每次 open/close 系统调用。

直接用 open_file_cache 缓存日志文件句柄，能有效压平高并发下因频繁 open/close 日志引发的 CPU 小毛刺和 I/O 波动。它不缓存日志内容，只复用已打开的 fd 和元信息，让每条日志写入跳过系统级文件打开流程。

为什么日志会产生“小毛刺”

默认情况下，Nginx 每次写 access_log 都会触发一次 open() + write() + close()（尤其在未启用缓冲或轮转频繁时）。当 QPS 上千、日志路径又按时间/主机名动态生成时，大量进程争抢文件句柄、内核 inode 查找、磁盘 seek，就会在 top 或 perf 中看到周期性 CPU 尖峰和 iostat 中的 await 抖动——这就是“小毛刺”的根源。

关键配置：四参数必须齐备

仅写 open_file_cache on 无效。需在 http 块中同步配置：

• open_file_cache max=2000 inactive=90s：设为 2000 起步，覆盖多虚拟主机+按日期切分的日志路径；90s 淘汰窗口比默认 60s 更适配日志写入节奏
• open_file_cache_valid 30s：每 30 秒校验一次日志文件是否仍可写（比如 logrotate 后原文件被 mv，新文件未重建）
• open_file_cache_min_uses 3：同一日志路径需在 90s 内被写入至少 3 次才进缓存，防止单次调试日志或错误路径占位
• open_file_cache_errors on：缓存“Permission denied”或“No such file”等错误状态，避免反复探测缺失日志目录

配合策略才能稳住句柄数

缓存本身不持有 fd，真正减少句柄波动要靠协同控制：

• 关闭非必要日志：location ~* \.(js|css|png|woff2)$ { access_log off; }，从源头砍掉 60%+ 的日志写入量
• 启用缓冲写入：access_log /var/log/nginx/app.log main buffer=128k flush=3s;，批量落盘降低系统调用密度
• 轮转改按大小而非时间：logrotate 配置 size=100M，避免每分钟强制 close 导致缓存频繁失效
• 调大系统限制：worker_rlimit_nofile 65535;，防止缓存条目增多后触发进程级句柄上限

验证有没有真起效

别只看 reload 成功，盯住三个实时指标：

• 执行 lsof -p $(pgrep nginx) | grep 'REG.*log' | wc -l：开启前随请求线性增长，开启后稳定在 max 值附近（如 1980±20）
• 查 error_log 是否有 open_log_file_cache: cache miss：持续出现说明 min_uses 过高或轮转太勤；出现 cache full 则需调大 max
• 压测时运行 iostat -x 1：若 %util 峰值下降 30%+、await 抖动消失，说明磁盘 I/O 毛刺已被抑制