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/确认进程归属的 memory cgroup 路径/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 可能共存，但不能对同一进程同时生效。确认清楚当前环境用的是哪套接口，再选对应字段操作，否则所有设置都是徒劳。
