etcd 手动 defrag 时内存尖峰把托管 etcd 顶到 OOM：compaction 收敛方案（867）之外，defrag 那一刻的内存预算怎么留、怎么在托管集群上防 OOM？

背景 我在一个 3 节点自建 K8s（1.28.9 + containerd 1.6.24，节点 16C64G，内核 5.15.0-91，cgroup v2）里把 etcd 拆到独立节点单独管，数据目录在本地 NVMe。业务侧 revision 增长很快（ConfigMap/Secret/Lease 轮转 + 一个 CRD reconcile 频繁写 status，etcd_server_proposed_duration_seconds 看着正常，但 db_total_size 从 1.2G 两周涨到 9.8G）。

现象

1. 按站内 867 那篇的思路，我先把 compaction 收敛做成了定时任务（etcdctl compact + 周期性跑），历史 revision 能跟上，db_total_size 的"虚胖"确实压下来了——但 db_size_in_use 和 db_total_size 之间长期差 2~3G，说明被删的 revision 标记了没回收，物理空间不释放，这块我知道就是缺 defrag。
2. 真正卡住我的是：我手动跑 ETCDCTL_API=3 etcdctl defrag --cluster 那一下，etcd 进程 RSS 瞬时从稳态 ~1.1G 冲到 4.7G（我后来用 etcd_server_follower_promote_duration_seconds 之外的 process_resident_memory_bytes 抓到的），节点当时还压着一个 6G 的日志采集器，直接触发了 kubelet 内存驱逐 + etcd 容器被 OOM，一次 defrag 把本来该收敛的库搞成了要 snapshot 恢复的事故。
3. 复现性：在"库大 + 节点内存水位本来就高"的组合下，defrag 的内存放大是稳定出现的，不是偶发。我在想这个尖峰是不是跟 MVCC 把 defrag 前的写缓冲/页缓存一起 hold 住有关，但没找到权威说法。

已尝试的排查与结果

1. 错峰：把 defrag 挪到低峰（凌晨 3 点）跑——缓解但没根治，因为根因是"节点总内存水位"而不是"时刻"，低峰只要采集器还在，水位依旧。
2. 限制 defrag 并发：只 defrag 单节点（去掉 --cluster，逐节点串行）——内存尖峰从 4.7G 降到 ~2.8G，比之前好，但在 64G 节点压了别的服务时仍然危险，而且逐节点串行让集群 defrag 窗口拉长了。
3. 给 etcd 加 memory limit（cgroup memory.max）——加了之后 OOM 还是发生，但这次是 etcd 自己先被 cgroup OOM kill，更糟（节点至少还活着，现在连库都翻了）。
4. 查了 etcd_mvcc_db_total_size_in_bytes 与 in_use 的差值，确认确实有 ~2.5G 可回收，但没找到"defrag 瞬时内存 = f(可回收量, 当前水位)"的量化经验。

期望得到的答案形态 希望做过同类 defrag 的朋友给可复现的做法，最好包含：

1. defrag 前的内存预算怎么留：有没有一个可量化的经验公式（比如"defrag 瞬时峰值 ≈ 可回收量 × N + 当前 RSS"，N 大概几），还是直接看 memory.current / PSI 给一个硬阈值（比如"节点可用内存 < X 就不许 defrag"）？
2. 托管/受限集群上怎么防 OOM：cgroup memory.max 到底该设成防不住还是该设成兜底？有没有人在 defrag 前临时把同节点的重服务（采集器之类）驱逐走再跑？
3. 逐节点串行 vs --cluster：在 3 节点里，哪种 defrag 顺序对内存尖峰最友好？Leader 先 defrag 还是 follower 先？
4. 有没有把"compaction 收敛 + defrag 防 OOM"做成一套带前置水位检查的 SOP（脚本/告警）能直接抄的？

我会把最终落地的 SOP 沉淀成经验文章，欢迎贴你们线上的真实数字。