Linux ZFS 的 arc_max / arc_min 与 adaptive replacement cache 调优曲线

zfs的arc_max并非越大越好，过高会挤压内核其他内存子系统引发direct reclaim或oom；arc_min过低则破坏arc自适应能力导致命中率骤降；需结合arcstats监控与系统负载动态调优。

arc_max 设置太高反而让系统变慢

linux ZFS 的 arc_max 不是“越大越好”，它限制的是自适应缓存（ARC）能占用的最高内存。设得过高，会导致内核其他子系统（比如 page cache、slab、网络缓冲区）争不到内存，触发频繁的 direct reclaim，甚至 OOM killer 干掉进程。

常见错误现象：dmesg 里反复出现 page allocation failure 或 low memory pressure；zpool iostat -v 显示 ARC 命中率不升反降；top 里 kswapd0 CPU 占用持续偏高。

• 生产环境建议值：不超过物理内存的 50%～60%，且必须预留至少 4GB 给非 ARC 内存需求
• 动态调整命令：echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_max（即 8GB）
• 注意：该值不能超过 zfs_arc_meta_limit，否则元数据缓存会被压制，影响小文件性能

arc_min 太低会让 ARC 失去自适应能力

arc_min 是 ARC 允许收缩到的下限。设得太低（比如默认的 128MB），ZFS 在内存压力下会把 ARC 缓存清空到几乎为零，再遇到重复读请求时只能重新加载——这直接破坏 ARC 的自适应替换逻辑（ART），命中率断崖下跌。

使用场景：IO 密集型数据库或虚拟机宿主，缓存稳定性比瞬时内存释放更重要。

• 合理范围：物理内存的 5%～15%，最低不低于 2GB（除非机器只有 4GB 总内存）
• 不要依赖“自动收缩”：ARC 不像 page cache 那样有成熟 LRU 回收路径，arc_min 过低会让 arc_reclaim 过度激进
• 验证方式：cat /proc/spl/kstat/zfs/arcstats | grep -E "(c_min|c_max|hits|misses)"，观察 c（当前大小）是否长期贴近 c_min

adaptive replacement cache 的调优不是调两个参数就够的

ZFS 的 ARC 不是传统 LRU，它同时维护 MRU 和 MFU 链表，并根据访问模式动态调整权重。但这个“自适应”高度依赖三个隐含前提：足够大的初始空间、稳定的内存水位、以及不被外部压力打断的统计周期。只调 arc_max 和 arc_min，相当于只拧了油门和刹车，却没碰转向和悬挂。

容易踩的坑：在启用 zfs_prefetch 或运行大量 zfs send/receive 时，ARC 统计会被干扰，MFU/MRU 比例失真，导致“冷数据滞留、热数据被踢”。这时单靠增大 arc_max 无效。

• 必须同步检查：zfs_arc_pmin（prefetch 最小触发阈值，默认 1）和 zfs_arc_meta_limit（元数据上限，默认无限制）
• 若发现 mfu_ghost_hits 远高于 mfu_hits，说明预读把真正热的数据挤出了 MFU，应降低 zfs_prefetch 或调高 zfs_arc_meta_limit
• ARC 曲线没有通用“最优值”：同一台机器，跑 postgresql 和跑 NFS 文件服务时，理想 c_min/c_max 比值可能差 3 倍

监控 ARC 状态比调参更关键

很多人花几小时调参，却从不看 arcstats 里的实际行为。ARC 的健康度不体现在数字大小，而在于各链表间流量是否平衡、回收是否平滑、ghost list 是否过载。

真实运维中，最常被忽略的是 l2_hits/l2_misses 和 deleted 字段：前者暴露 L2ARC 是否成了性能拖累，后者反映 ARC 是否在反复丢弃刚加载的块（说明 arc_min 或工作集估算严重失配）。

• 必查字段：c（当前大小）、mru_hits/mfu_hits（主链表命中）、mru_ghost_hits/mfu_ghost_hits（ghost 链表命中）、deleted（每秒丢弃条目数）
• 健康信号：deleted mru_ghost_hits ≈ mfu_ghost_hits；异常信号：deleted > 5000/sec 或 mfu_ghost_hits 占总 hits 超过 30%
• 临时诊断命令：arcstat -c 1 10（每秒采样 10 次），比反复改参数更能定位瓶颈来源

ARC 调优真正的复杂点不在公式，而在它和 Linux 内存管理器的耦合深度——你看到的 arc_max 是 ZFS 的上限，但内核的 vm.vfs_cache_pressure 和 swappiness 会悄悄绕过它回收 slab 对象。没人告诉你，关掉 swap 后 arc_min 可能突然失效。