sidecar 内存 limit：设了是「定时 OOM」，不设是「裸奔」——这个数你们到底怎么定的？

【背景】 上周又被叫起来处理节点 OOM：一个跑在 8C16G 节点上的 Envoy sidecar，内存从稳态 400MB 缓慢爬到 6.2GB，最后把同节点的 Java 主应用一起拖崩。排查发现是上游一个 batch 接口返回了异常大的 JSON（单条 48MB），Envoy 的 per-connection buffer 和 LRU cache 被撑爆，而 cgroup memory.max 设的是 8G——刚好够它「慢慢吃满」再 OOM。

这件事让我重新审视一个我们团队一直没有明确共识的问题：sidecar / agent 类进程的内存预算，到底应该怎么定？

【常见的几种做法】

1. 一刀切 cgroup limit：给 Envoy 设 1G，给 log agent 设 512M，超了直接 OOM-kill。简单粗暴，但 Envoy 的内存使用和上游响应体大小强相关，1G 在正常流量下够用，遇到一次 10MB 的大响应就反复 OOM，反而比不限更伤——每次 OOM 重启都意味着 mTLS 断链、存量连接闪断。
2. 不设 limit，靠 node-level OOM killer 兜底：赌 sidecar 的 oom_score_adj 比主应用低（通常确实低，因为 sidecar 没有 cgroup 保护时 oom_score 偏低）。但 node-level OOM 是全局事件，内核选谁杀不完全可控，而且杀了 sidecar 之后日志断流、mTLS 断链，影响面反而更大。
3. soft limit + 告警：在 sidecar 进程内做内存水位监控，到 80% 告警，到 95% 主动降级（比如 Envoy 的 drain 或 log agent 的 drop-oldest）。问题是：谁来定这个 80%？基线怎么算？流量模型变了基线就漂了。
4. 预算制（budget）：先算节点总内存，减去主应用 p99 峰值，剩下的按 sidecar 数量均分，每个 sidecar 拿到一个「预算」，cgroup limit = 预算 × 安全系数（1.3~1.5）。这是我个人比较倾向的做法，但落地时发现安全系数怎么定非常依赖流量模型，batch 流量和在线流量的内存画像差异极大。

【我的倾向】 我倾向于「进程内软限 + cgroup memory.high（soft）+ cgroup memory.max（hard）」三层护栏：

• 第一层：进程内软限。比如 Envoy 的 per_connection_buffer_limit_bytes + LRU cache max_entries，让 sidecar 在 80% 预算时就主动释放 buffer / 淘汰 cache entry，而不是等到 OS 层面介入；
• 第二层：cgroup memory.high（soft limit，cgroup v2）。触发时内核增加回收压力（写回 dirty pages、回收 slab），但不 kill，给 sidecar 一个「喘息窗口」——这一层是我最近才开始用的，想听听大家线上效果；
• 第三层：cgroup memory.max（hard limit）。最后兜底，触发即 OOM-kill，但正常情况下不应该走到这里。如果频繁走到，说明前两层没配好。

关键问题是：这个「预算」的基数怎么定？我目前的算法是「节点总内存 × 主应用 p99 峰值占比」反推，但 p99 窗口取 7 天还是 30 天？batch job 和在线服务混跑时，内存画像差异大到 7 天窗口完全不够覆盖。

【想听大家的】

1. 你们线上 sidecar（Envoy / Fluent Bit / VictoriaMetrics agent / 自研 log shipper）的内存 limit 是怎么定的？有公式吗，还是拍脑袋？拍脑袋的话，拍完 OOM 频率大概多少？
2. 有没有人真的在用 cgroup v2 的 memory.high 做「软护栏」？效果怎么样，跟直接设 memory.max 比，OOM 频率和 P99 延迟有没有可观测的差异？
3. 混跑节点上（主应用 + 2~3 个 sidecar），你们的内存预算分配比例大概是什么？主应用占多少、sidecar 各占多少？这个比例是固定的还是随流量动态调的？
4. 有没有遇到过「limit 设了反而更糟」的情况？比如 Envoy 反复 OOM 重启导致连接闪断，比不设 limit 还伤？这种情况你们后来怎么处理的？
5. 如果 sidecar 的内存使用跟「上游响应体大小」强相关（比如 Envoy buffer），你们有没有在 sidecar 配置层面做「单请求内存上限」（比如 Envoy 的 per_connection_buffer_limit_bytes 或 log agent 的 chunk_limit）？这个值和 cgroup limit 是什么关系？

欢迎带具体数字来聊：节点规格、sidecar 类型、稳态/峰值内存、你们设的 limit 值、实际 OOM 频率。空对空的理论讨论意义不大，我更需要的是「你们线上到底怎么配的、配完效果如何」。