nginx 不支持 manager_files 配置，其缓存管理器每秒扫描最多 100 个子目录（由宏 ngx_http_cache_manager_files 硬编码），单次处理文件数不可调；可通过优化 levels、配足 keys_zone 内存、分级设置 inactive 时间来降低 cpu/i/o 压力。
Nginx 并不支持 manager_files 这个配置参数。它不是官方指令，也不在任何稳定版 Nginx 的 proxy_cache_path 语法中存在。你在配置里写 manager_files=100 会导致 nginx 启动失败，或被静默忽略——这是长期被误传的常见错误。
真正起作用的，是 Nginx 缓存管理器（cache manager）源码中硬编码的行为逻辑：
- 每秒自动唤醒一次；
- 每次最多扫描 100 个缓存子目录（不是文件数），由宏
NGX_HTTP_CACHE_MANAGER_FILES控制（默认值为 100）； - 在每个目录内，按需检查部分文件是否满足
inactive条件，再决定是否清理； - 扫描深度、单次处理文件数量、休眠时长等，全部不可配置。
所以，“调优单次清理文件上限”这个动作，在 Nginx 当前架构下无法通过配置实现。但你可以从三个可调维度，实质性降低清理带来的 CPU 和 I/O 压力：
优化缓存目录结构
用好 levels 参数，避免单目录堆积海量文件：
- ❌
levels=1→ 最多 16 个目录，易达数万文件/目录，遍历开销剧增； - ✅
levels=1:2→ 4096 个目录，百万级缓存也能保持单目录平均 - ✅
levels=1:2:2→ 更适合千万级小文件场景（如图标、API 响应）。
配足 keys_zone 内存
keys_zone 不仅存 key，还维护每个缓存项的最后访问时间（用于 inactive 判断）：
- 内存不足 → key 被挤出 → manager 只能靠全盘 stat 补救 → CPU 翻倍；
- 经验公式：每 1000 个活跃缓存条目 ≈ 128 KB 共享内存；
- 例：支撑 50 万缓存，建议
keys_zone=mycache:64m。
分级设置 inactive 时间
避免所有缓存集中在同一时刻过期，引发清理“脉冲”：
- API 响应类：
inactive=15m～30m； - 静态资源（JS/CSS/图片）：
inactive=2h～6h； - 归档页、PDF 等低频内容：
inactive=3d～7d； - 配合
max_size使用，让空间回收更平滑，减少集中扫描压力。
其他有效辅助手段：
-
use_temp_path=off：避免临时文件残留，减少 manager 额外判断； - 确保缓存路径在 ext4/xfs 本地磁盘上，避开 NFS 或低性能云盘；
- 监控
error_log level debug中的cache manager started日志，观察单次耗时是否频繁超 200ms（说明目录或 inode 层面已成瓶颈）。
不复杂但容易忽略。
