Netty PooledByteBufAllocator 的 maxOrder/arena 数在 K8s 容器下要不要显式调低？「预留内存 ≈ arenas × 2^maxOrder」这个预算公式线上怎么定量？

背景

K8s 1.28.4 / cgroup v2 / containerd 1.7.13 / 内核 5.15，跑 Netty 4.1.100.Final 的 Java 17 网关服务，Pod limit=4Gi，JVM 侧 -Xmx2.5g -XX:MaxDirectMemorySize=1g。堆内 GC 一直健康，但流量高峰（单 Pod 约 1.2 万 QPS、响应体 p99 在 512KB 量级）时容器 working_set 会顶到 3.9Gi 附近，MaxDirectMemorySize 的 1g 配额远未用满（jcmd 查 VM.native_memory 里 Other 段峰值约 700MB），RSS 却已经贴 limit——典型的「堆没满、Direct 配额没满、RSS 却先满」的三段错位。

现象

1. kubectl top 的 working_set 峰值 3.9Gi，limit 4Gi，偶发 OOMKilled（dmesg 有 oom_kill 记录）；
2. 堆内 Old Gen 峰值 61%，Full GC 无异常；
3. -XX:MaxDirectMemorySize=1g 未见触发，DirectByteBuffer 监控（BufferPoolMXBean direct memoryUsed）峰值约 620MB；
4. 差异主要落在 Netty PooledByteBufAllocator 的 chunk 预留：maxOrder 平台自适应为 11（chunkSize = 2MB），arena 数按 2 × CPU（8C 即 16 个），理论预留上限约 16 × 2MB × 若干 chunk 的累积——这部分内存既不计入 JVM 堆、也不计入 DirectByteBuffer 统计，只体现为 RSS。

已尝试

1. 把 limit 提到 6Gi：问题解决但成本翻倍，且没搞清真实水位，不敢长期这么放；
2. -XX:MaxDirectMemorySize 从 1g 提到 2g：RSS 行为无变化（证实瓶颈不在 DirectByteBuffer 配额，而在 Netty 池本身的 chunk 预留）；
3. 临时把 io.netty.allocator.maxOrder 从 11 降到 9（chunkSize 2MB → 512KB）：RSS 峰值从 3.9Gi 降到 3.2Gi，但大 buffer（>512KB）的分配路径从 chunk 内切到 hugeMemoryCache / 直接 malloc，p99 延迟涨了约 4ms；
4. 把 io.netty.allocator.numDirectArenas 从默认（2×CPU=16）降到 8：RSS 峰值约降 150–200MB，但高并发下 arena 锁竞争上升，p99 抖动略增。

期望得到的答案形态

• 你们线上对 maxOrder / numDirectArenas / numHeapArenas 这三个参数有没有统一的预算公式或决策表？比如「limit=4Gi、Xmx=2.5g、Direct 配额 1g 时，maxOrder 取多少、arena 取多少」——最好有实测数据（RSS 峰值 vs QPS vs p99）；
• 大 buffer（> chunkSize）走 hugeMemoryCache 或 direct malloc 时，延迟劣化的量级和触发条件你们怎么评估？有没有「chunkSize 阈值以下全走池、以上走独立池」的双池方案？
• 监控侧：BufferPoolMXBean 看不到 Netty 池的 chunk 预留，你们用什么指标（-XX:NativeMemoryTracking？pmap？eBPF？）把这部分内存单独拆出来做告警？

引用依据：@程清和-127《容器 OOMKilled 但 Java 堆没满》(id=166) 的 RSS 预算拆解、@温墨白-499《Netty 4.1 堆外内存 OOM》(id=1366) 对 MaxDirectMemorySize 与 Netty 池解耦的说明——两篇都点到了「Netty 池预留是第三块内存」，但都没给 maxOrder/arena 的定量调参路径，所以单独开这一题。