容器里 free 看到的内存是宿主机的？一次 /proc/meminfo 视角修正实战

问题：面板上的内存数字不对劲

前几天在一台 systemd-nspawn 容器里部署监控 agent，面板上显示内存用了 6.7G / 7.7G，吓我一跳。但进容器里一查，所有进程的 RSS 加起来才三四百 MB——这 6.7G 显然不是容器用的。

排查：/proc/meminfo 出卖了宿主机

容器里执行 free -h，看到的 Total 7.7G、used 6.7G，和宿主机整机一模一样。原因很直接：容器没有自己的 memory cgroup 计数，/sys/fs/cgroup 下找不到 memory.current 这类文件，cat /proc/meminfo 读到的就是宿主机的整机数据。而监控 agent 恰恰是读 /proc/meminfo 上报的，面板数字自然就错了。

验证方法很简单：把容器里所有进程的 RSS 加总（/proc/[pid]/status 里的 VmRSS），和 free 显示的 used 对比一下，差一个数量级，实锤。

方案：自己造一份容器视角的 meminfo

既然 cgroup 指望不上，那就自己生成一份 meminfo，每 10 秒刷新一次，然后 bind mount 覆盖掉 /proc/meminfo：

• MemTotal：保留宿主机总量（7.7G），让"总量"这个数字继续有意义
• MemAvailable / MemFree：按 Total - 进程RSS总和 推导
• Used = 全部进程 RSS 之和：这才是容器真正吃掉的内存

核心逻辑就是一行思路：遍历 /proc/[0-9]*/status，累加 VmRSS，按 meminfo 格式输出。脚本本身几十行，跑一个 systemd service 常驻即可。

落地与验证

服务跑起来后，容器里 free 显示已用约 250MB，和进程 RSS 合计吻合；监控 agent 上报的数字也恢复正常，面板终于不再"虚胖"了。

小结

容器里想看准内存，两条路：要么配好 cgroup 内存配额让运行时限流、要么像这样自己造数据源。bind mount 覆盖 /proc/meminfo 简单粗暴，但在 cgroup 不可用的环境里是真管用。不过要注意，这只是"视角修正"，并不限制容器实际能用多少内存，资源隔离还得靠 cgroup 配额来做。