zone_reclaim_mode=1 使进程更易OOM，因其强制本地NUMA节点内回收内存，当该节点内存紧张且无法快速回收（如脏页回写慢）时，跳过跨节点分配直接触发OOM killer。
zone_reclaim_mode 设为 1 时，为什么进程反而更容易 OOM？
因为 zone_reclaim_mode=1 强制内核在本地 NUMA node 内回收页面，不跨 node 分配；当该 node 内存紧张、又无法快速回收足够页面（比如大量不可回收的 page cache 或脏页），分配失败就直接触发 OOM killer，跳过了本可成功的跨 node 分配路径。
- 典型现象：
Out of memory: Kill process <code>xxx(xxx) scoreyyy日志频繁出现，但free -h显示系统总内存仍有富余 - 适用场景：仅当明确需要避免远程内存访问延迟（如低延迟数据库实例），且已确保各 node 负载均衡、脏页能及时回写时才考虑启用
-
zone_reclaim_mode=1不影响 slab 回收，也不触发 kswapd 全局扫描，只调用shrink_zone()本地收缩 - 若启用了
vm.dirty_ratio但磁盘写入慢，zone_reclaim_mode=1会卡在等待脏页回写，加剧分配延迟
zone_reclaim_mode=2 和 =4 的实际行为差异在哪？
zone_reclaim_mode=2 表示“尝试回收文件页（page cache）”，zone_reclaim_mode=4 表示“尝试回收匿名页（anon pages，如堆内存）”；两者可叠加（例如 6 = 2+4），但内核对匿名页回收更保守——除非 swappiness > 0，否则 =4 几乎无效。
-
zone_reclaim_mode=2在页面分配路径中调用shrink_inactive_list()扫描inactive_fileLRU，但只限当前 zone -
zone_reclaim_mode=4同样扫描inactive_anon，但若swappiness==0，shrink_list()会跳过 anon 链表，此时设为 4 等同于没设 - 注意：
zone_reclaim_mode不改变vm.swappiness的全局倾向，它只是“是否允许在 zone 级别尝试回收”的开关
NUMA 环境下，zone_reclaim_mode 和 numactl --membind 的冲突表现
当进程用 numactl --membind=1 绑定到 node 1，同时 zone_reclaim_mode=1，内核会在 node 1 的每个 zone 内独立尝试回收；但如果 node 1 的某个 zone（如 DMA32）已耗尽，而其他 zone（如 Normal）仍有空闲，zone_reclaim_mode=1 不会跨 zone 补偿——它只管“当前分配请求落入的 zone”，不是整个 node。
- 常见错误：以为
--membind+zone_reclaim_mode=1就能“完全隔离”，结果因 zone 碎片导致分配失败 - 验证方法：分配大页时观察
/sys/devices/system/node/node1/meminfo中各 zone 的PagesFree，而非只看MemFree - 若应用有明显 zone 倾向（如某些驱动固定分配 DMA32），
zone_reclaim_mode=1可能比=0更早触发回收，但未必提升成功率
如何安全地动态调整 zone_reclaim_mode？
运行时写入 /proc/sys/vm/zone_reclaim_mode 是立即生效的，但不会回滚正在执行的内存分配路径；所以切忌在高负载时从 0 改成 1，可能瞬间激增回收开销，拖慢关键进程。
- 推荐操作顺序：先确认
vm.swappiness合理（如 10–30），再临时设为1观察/proc/vmstat中pgpgin/pgpgout和pgmajfault是否异常升高 - 禁止在容器环境（尤其是 CRI-O / containerd 默认配置）中启用，因为 cgroup v1 的 memory controller 与 zone reclaim 存在竞争，易引发
Cannot allocate memory错误 - 若需长期开启，务必配合
vm.min_free_kbytes调高（至少为物理内存的 1%），否则回收启动太晚，失去意义
真正难的是平衡：NUMA 局部性收益 vs. 回收延迟成本，而 zone_reclaim_mode 没有中间态——开或关，全看 workload 是否真的对 remote access 敏感，而不是“听说 NUMA 要调这个”。
