容器里 ulimit -v 掐死虚拟地址空间：JVM/Go 明明有 8G 内存却 mmap 失败的排查与预算

结论先行：docker run --memory 限的是物理内存（RSS），而 ulimit -v / RLIMIT_AS 限的是虚拟地址空间（VA）——两者是两条完全独立的预算线。绝大多数「明明给了 8G 内存、进程却 Cannot allocate memory / OutOfMemoryError: unable to create native thread / Go runtime: out of memory」的诡异故障，根因不是物理内存不够，而是有人把 ulimit -v 设得太小，把进程预留（reserve）而非实际占用的虚拟地址空间给掐死了。这篇文章给一套从现象到治本、可复现的排查路径。

一、现象：内存监控全绿，进程却起不来 / 崩了

我们一个 4C8G 的容器（Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15），跑一个 Go 1.21 的高并发网关，resources.limits.memory=8Gi。某次把基础镜像从公司标准底座换成一个「加固版」底座后，进程启动到一半就 runtime: out of memory: cannot allocate 16777216-byte block，而 node_exporter 显示该节点空闲物理内存还有 20G+，Pod 的 memory.working_set 峰值只有 3.1Gi。

更迷惑的是：把同样的二进制裸机跑（同内核、同参数）完全正常，QPS 稳在 52k。差别只有容器这一层。

排查 crictl inspect / docker inspect 里 HostConfig.Ulimits，发现底座写死了：

"Ulimits": [ { "Name": "AS", "Hard": 4294967296, "Soft": 4294967296 } ]

AS 就是 RLIMIT_AS，单位是字节，4294967296 = 4GiB 虚拟地址空间上限。这就是凶手。

二、原理：为什么「预留」会撞墙，而 RSS 还很低

关键机制要讲清楚，否则排查会走偏：

1. RLIMIT_AS 限制的是 mm->total_vm，即进程已映射的虚拟地址空间总量（man 2 setrlimit：RLIMIT_AS … "the maximum size of the process's virtual memory (address space) in bytes"）。它统计的是 mmap/brk/mprotect 保留下来的地址区间之和，不区分这些页是否真的被 fault-in 占用物理内存。

2. Go 的 mheap 和 JVM 都习惯一次性预留一大块 VA。Go runtime 在启动时会 mmap 一大段 arena（在 64 位上默认按 64 个 heap arena 规划，每 arena 64MiB，且会预留远超实际用到的 VA）；JVM 用 -Xmx 时会 mmap 整个堆的 VA（即便堆只用到 20%）。这些预留都会计入 total_vm，但物理页按需 fault-in，所以 RSS 可以远低于 VA。

3. 于是出现「RSS 3G、VA 已 5G」的状态：--memory 8Gi 看着宽裕，但 RLIMIT_AS=4Gi 已经在 mmap 那一刻返回 ENOMEM。报错文案是 cannot allocate memory，极易被误判成「物理内存不足」——但 free -g 全绿。

4. 为什么裸机没事：裸机默认 ulimit -v 是 unlimited（RLIM_INFINITY），所以 Go/JVM 能自由预留 VA。容器里底座把 AS 硬限到 4Gi，就把这条「预留预算」掐断了。

一句话：--memory 管「你实际用了多少物理页」，ulimit -v 管「你能预留多大的地址空间」，预留不需要物理页，但照样受 ulimit -v 约束。

三、具体做法：定位 + 治本（可复现）

1) 确认是不是 RLIMIT_AS 撞墙

# 容器内看当前进程的软/硬上限（字节）
grep 'Max address space' /proc/self/limits
# 看进程当前已用虚拟地址空间（KB）
grep -E 'VmSize|VmRSS' /proc/<pid>/status
# 对比：VmSize(kB)*1024 是否逼近/超过 AS 上限

VmSize 逼近 Max address space 而 VmRSS 远小于 --memory limit，基本可锁定是 VA 预算而非物理内存。

2) 复现验证（在测试节点上，别直接改生产底座）

# 用一个最小 Go 程序触发大 VA 预留，撞 4Gi AS 上限
docker run --rm --ulimit as=4294967296 golang:1.21 \
  go run -exec '' /dev/stdin <<'EOF'
package main
import "fmt"
func main() {
  // 申请 5GiB（远超 4Gi AS 上限，会失败）
  b := make([]byte, 5<<30)
  b[0] = 1
  fmt.Println("ok", b[0])
}
EOF

--ulimit as=... 去掉后同一命令成功、加上后报 cannot allocate memory，即可坐实。

3) 治本（三选一，按场景）

• 首选：把 AS 上限去掉或调大。Dockerfile / 底座里删掉 Ulimits 的 AS 条目；K8s 侧没有直接字段，需在节点侧 containerd/dockerd 默认 ulimit 或基础镜像层放开。经验值：RLIMIT_AS 给到 --memory 的 4~8 倍（VA 预留通常远大于 RSS），例如 --memory=8Gi 配 as=32212254720（30Gi）或直接 unlimited。
• 次选：降低进程 VA 预留。JVM 用 -XX:MaxRAMPercentage=55.0 让堆按可用内存比例而非固定大堆预留；Go 设 GOMEMLIMIT（1.19+）约束堆增长，并避免一次性 make([]byte, 巨大值)。
• 兜底：CI 门禁加断言。镜像构建后自动 grep 'Max address space' 并断言 AS ≥ 8 × memory.request，把这类底座回归挡在发布前。

# K8s 侧没有 ulimit 字段；用 initContainer 打印自检（示意）
command: ["/bin/sh","-c","grep 'Max address space' /proc/self/limits; grep VmSize /proc/self/status"]

四、踩过的坑 / 反直觉之处

1. 报错文案骗人：cannot allocate memory / ENOMEM 既可能是 RSS 不够、也可能是 VA 不够，二者解法完全不同。只看 free 会漏掉后者。
2. 「加固底座」是高频肇事者：很多安全加固镜像会顺手加 RLIMIT_AS 防「内存滥用」，却不懂 VA ≠ RSS，直接把 Go/JVM 这类大预留运行时掐死。换底座这类「无 diff 的变更」最容易引入。
3. 裸机正常 ≠ 代码问题：同二进制裸机 52k QPS 稳跑、容器里起不来，先怀疑容器层限制（AS / nofile / pids），别先怀疑业务代码。
4. ulimit -n 和 ulimit -v 别混：-n 是文件描述符数（撞了报 Too many open files），-v 是虚拟地址空间（撞了报 cannot allocate memory），症状与解法都不同，排查时分开确认。
5. 预留是合法的：Go/JVM 一次性 mmap 大块 VA 不是 bug，是设计；不该靠「改代码少预留」去迁就一个过小的 RLIMIT_AS，而应把 AS 预算放开。

五、结论与可复用清单

• --memory(RSS) 与 ulimit -v(VA) 是两条独立预算线；VA 预留不占物理页，但受 RLIMIT_AS 约束。
• 排查顺序：/proc/<pid>/limits 看 AS 上限 → /proc/<pid>/status 看 VmSize 是否逼近上限而 VmRSS 远低于 --memory → 用 --ulimit as=... 最小复现 → 放开 AS 到 --memory 的 4~8 倍。
• 经验参数：--memory=8Gi 建议 RLIMIT_AS ≥ 30Gi（或直接 unlimited）；JVM 配 -XX:MaxRAMPercentage=55.0；Go 配 GOMEMLIMIT。
• 门禁：镜像构建后断言 AS ≥ 8 × memory.request，把底座 ulimit 回归挡在发布前。
• 区分记忆：-n→fd→Too many open files；-v→VA→cannot allocate memory；--memory→RSS→OOMKilled。三条线、三种症状、三种解法，排查时逐一排除。

与站内已覆盖的「RSS OOMKilled（heap/native 预算）」「/dev/shm 64MB」「Too many open files(fd)」等主题不同，本文专攻**虚拟地址空间（RLIMIT_AS）**这条独立预算线，避免与 RSS 排查混淆。