container_memory_rss才是反映应用真实内存消耗的准确指标，它表示进程实际锁定在物理内存中的页（如JVM堆、Go堆外内存），不含page cache和内核内存；而container_memory_working_set_bytes因包含active_file，常虚高、滞后，仅适用于观察OOM风险或调度压力。
不能精准评估。
container_memory_working_set_bytes 本质上不是为“反映应用实耗内存”设计的指标，而是 Kubernetes 调度与驱逐逻辑中一个带策略意图的中间值。它在多数监控场景下会高估、滞后甚至失真，直接用它判断“容器到底用了多少内存”，就像用体温计测血压——量具没错，但测的不是那个东西。
容器实耗内存该看什么？
真正贴近进程实际物理内存占用的指标是：
-
container_memory_rss：常驻内存集（Resident Set Size），即进程当前真实锁定在物理内存中的页，不含 page cache、不含 inactive_file、不含内核内存开销。JVM 堆、Golang runtime 分配的堆外内存、C 程序 malloc 的有效内存，基本都落在这里。 -
container_memory_rss + container_memory_kernel_usage（如可用）：部分新版 cAdvisor 或 eBPF 工具可分离内核内存，对网络连接多、io 频繁的容器更准。 -
node_memory_MemAvailable（节点级辅助参考）：从内核/proc/meminfo动态估算的真正可回收内存，比容器级指标更能反映系统是否濒临 OOM。
✅ 实操建议：
- 监控告警优先用
container_memory_rss，设阈值时参考容器 memory limit 的 70%~80%，而非 working_set；- 对 Java/Go 等语言服务，叠加
jvm_memory_used_bytes或go_memstats_alloc_bytes做交叉验证；- 若必须用 working_set，仅用于观察是否逼近
memory.limit_in_bytes——因为 Kubelet 的 OOM 判定确实会参考它，但它不等于“你写的代码占了多少”。
为什么 working_set 不适合评估实耗？
它计算公式是：working_set = memory.usage_in_bytes − inactive_file
= (rss + cache) − inactive_file
= rss + active_file
问题就出在 active_file 上：
- active_file 是文件缓存中“最近访问过、内核认为暂时不能回收”的部分，但它仍属于 page cache，不是应用主动申请的内存；
- 应用没读写文件时，这部分可能长期滞留；
- 内存压力来临时，它能被快速回收，却仍计入 working_set，造成“虚高”；
- 指标常出现平台期、释放滞后、与
kubectl top pod结果严重不符。
什么时候可以参考 working_set？
仅两类场景：
- 查看 Pod 是否处于被 Kubelet “盯上”的边缘：当
working_set / limit持续 > 95%，且container_memory_failcnt开始增长，说明已触发 cgroup 内存压力信号； - 排查调度异常：比如多个 Pod 的 working_set 总和远超节点
MemAvailable，提示存在大量不可回收缓存挤压，需检查是否有容器疯狂读大文件未释放句柄。
基本上就这些。
