cgroup v1 的 memory.limit_in_bytes 不生效的根本原因是容器或进程未真正运行在指定 cgroup 下，或内核未启用 memory 子系统；需检查挂载、进程归属、路径创建及 systemd/cgroup 版本兼容性。

为什么 cgroup v1 的 memory.limit_in_bytes 有时不生效

根本原因常是容器或进程没真正运行在指定 cgroup 路径下，或者内核未启用对应控制组子系统。检查时先确认 /sys/fs/cgroup/memory 是否可挂载且非空；再看目标进程的 cgroup.procs 文件是否包含其 PID。

• 用 cat /proc//cgroup 确认进程归属的 memory cgroup 路径
• 写入限制前必须确保该 cgroup 目录已创建，且 memory.limit_in_bytes 文件存在（不是只读）
• 若使用 systemd 启动服务，需通过 MemoryLimit= 设置，而非手动操作 /sys/fs/cgroup 下文件——systemd 会接管并覆盖手动配置
• 某些发行版（如 RHEL 8+/CentOS 8+）默认启用 cgroup v2，此时 memory.limit_in_bytes 不可用，应改用 memory.max

cgroup v2 中设置内存上限：用 memory.max 而非 memory.limit_in_bytes

cgroup v2 统一了接口，所有资源控制都通过单一层级实现。内存限制字段变为 memory.max，单位仍是字节，但支持特殊值：max 表示无限制，0 表示禁止分配新内存（等效于立即 OOM）。

• 创建 v2 cgroup：先挂载 mount -t cgroup2 none /sys/fs/cgroup，然后 mkdir /sys/fs/cgroup/myapp
• 设上限为 512MB：

  echo 536870912 > /sys/fs/cgroup/myapp/memory.max

• 将进程加入：

  echo  > /sys/fs/cgroup/myapp/cgroup.procs

• 注意：v2 下 memory.usage_in_bytes 已改为 memory.current，监控时别用错路径

OOM 发生时为何进程没被杀，而是卡住或响应迟缓

这是因 memory.oom_control（v1）或 memory.oom（v2）默认开启“OOM killer”，但实际触发取决于当前内存压力与页面回收效率。若进程持续申请不可回收内存（如匿名 mmap + 锁页），或 cgroup 内有多个子组竞争，OOM killer 可能延迟响应甚至无法及时选中目标进程。

• v1 中可关闭自动 kill：echo 1 > memory.oom_control，此时超限时直接阻塞内存分配（malloc 返回 NULL，mmap 失败）
• v2 中等效机制是写 memory.oom 为 0，但更推荐配合 memory.high 做软性限流——它会在接近阈值时主动回收内存，避免突兀 OOM
• 检查是否真触发 OOM：dmesg -T | grep -i "killed process"，若无输出，说明只是内存紧张而非被杀

和 Docker/Kubernetes 的内存限制冲突怎么办

Docker 默认使用 cgroup v2（1.21+），Kubernetes 则依赖 kubelet 配置的 cgroupDriver。若宿主机手动修改了某 cgroup 路径下的限制，而容器运行时又覆盖了同一路径，结果不可预测——通常以最后写入者为准，但可能引发状态不一致。

• 不要在 Docker 容器运行后手动改其 cgroup 目录（如 /sys/fs/cgroup/mycontainer/...），Docker 会定期同步配置
• Kubernetes 中应统一通过 Pod 的 resources.limits.memory 控制，底层由 kubelet 转为 memory.max 或 memory.limit_in_bytes
• 调试时可查容器真实 cgroup 路径：cat /proc//cgroup，再比对 memory.max 值是否匹配预期

最易被忽略的是 cgroup 版本混用：同一个系统里 v1 和 v2 可能共存，但不能对同一进程同时生效。确认清楚当前环境用的是哪套接口，再选对应字段操作，否则所有设置都是徒劳。