OOM

概述 凌晨三点，告警群炸了。 5 个 Pod 在 10 分钟内陆续 OOMKilled 重启。值班同学打开 Grafana 看内存曲线，事发前所有 Pod 的 working_set 离 limit 还有 200MB，使用率 80%。监控显示一切正常，Pod 照样死了。 这不是个例。在某新能源物流平台做 K8s 迁移时，这类"监控绿着 Pod 就死了"的事故我处理过不下 10 次。根因每次都一样：运维团队只盯了一个指标，而且盯的那个指标会骗人。 容器内存不是单一数值。cAdvisor 暴露了四个维度的内存指标，大部分团队只用 container_memory_working_set_bytes 做告警基线。问题在于，当 page cache 已经很小时，working_set 显示 80% 可能意味着实际只剩 5% 的可分配额度——你看到的 20% 余量根本不存在。 本文拆解容器内存监控的四层指标迷雾，给出 5 个生产级预警决策，包含完整的 PromQL recording rules、告警规则和 Grafana 查询。这套配置在某新能源物流平台 120+ 微服务集群上跑了 6 个月，OOM 预警准确率从 60% 提升到 95%，误报率从 40% 降到 5%（相关文章：告警策略设计：从噪声到信号）。 容器内存的四层指标迷雾 cAdvisor 暴露了什么 cAdvisor（Container Advisor）是 K8s 节点上 kubelet 内置的容器监控组件，通过 /metrics 端点暴露 Prometheus 格式的指标。在内存维度，它暴露了四个关键指标，每个都对应不同的 cgroup 底层字段：...

概述 内存是 Linux 系统中最宝贵的资源之一。理解内核如何管理内存，不仅能帮助你定位 OOM、内存泄漏等线上故障，还能在容量规划和性能调优时做出更准确的决策。从虚拟内存模型出发，覆盖 Page Cache、Swap 策略、OOM Killer 原理、cgroup v2 内存限制、slab/shmem 调优等核心主题，并附带多个生产环境实战案例。 虚拟内存模型 地址空间分层 Linux 采用虚拟内存机制，每个进程拥有独立的虚拟地址空间： 层级 说明 用户态可见 用户空间 0x000000000000 ~ 0x00007FFFFFFFFFFF 是 非规范区 0x0000800000000000 ~ 0xFFFF7FFFFFFFFFFF 否（空洞） 内核空间 0xFFFF800000000000 ~ 0xFFFFFFFFFFFFFFFF 否 64 位系统下，用户空间理论上有 128TB（47 位地址），内核空间同样 128TB。实际可用受 TASK_SIZE 和 mm_struct 限制。 内存_zone 划分 内核将物理内存划分为多个 zone，不同 zone 有不同用途： $ cat /proc/zoneinfo | grep -E "^Node|pages free|high|normal|DMA" Zone 用途 典型场景 DMA 16MB 以下，旧 ISA 设备 DMA 几乎不用 DMA32 4GB 以下，32 位 DMA 设备 老硬件 Normal 4GB 以上，大多数内存分配 主要使用 Movable 可迁移页面，支持内存热插拔 虚拟化/大页 当 Normal zone 内存耗尽时，内核会从 DMA32 zone 借用页面（watermark 机制），但频繁借用会导致性能下降。...