cgroup硬限制过严会触发oom killer、cpu节流或频繁换页，应改用mem_reservation+mem_limit组合，并按服务特性差异化配置，辅以宿主机cgroup v1回退、禁用swap及oom分数调优。
Compose 多服务场景下，Cgroup 硬限制（如 mem_limit、cpus、memory_reservation）设得过死，反而会触发内核 OOM Killer、CPU throttling 或频繁内存换页，导致服务响应变慢、吞吐下降——这不是资源没给够，而是限制方式不合理。
识别是否真由 Cgroup 限制引发负优化
先确认问题根源，避免误调：
- 进容器查
/sys/fs/cgroup/memory/memory.stat，看total_oom_kill或total_pgpgin/total_pgpgout是否异常高 - 运行
docker stats <container></container>，观察MEM USAGE / LIMIT长期接近 100% 且MEM %波动剧烈 - 查 CPU 节流：
cat /sys/fs/cgroup/cpu,cpuacct/<path>/cpu.stat | grep throttled</path>，若throttled_time持续增长，说明 cpus 限制过紧 - Java/Go 等语言服务出现 GC 频繁或调度延迟升高，也常与 memory.limit_in_bytes 强制截断有关
用 soft limit 替代硬限，保留弹性空间
硬限（mem_limit）是“一刀切”，而 mem_reservation + mem_limit 组合能兼顾保障与弹性：
-
mem_reservation: 512m：为容器预留最低可用内存，不抢占，但优先保障 -
mem_limit: 1.5g：设置绝对上限，仅在主机内存紧张时才强制回收 - 两者差值（如 1G）即为“缓冲带”，让 JVM G1GC、Redis LRU、PostgreSQL shared_buffers 等有喘息空间
- 对应 Compose v2.20+ 写法：
deploy:<br> resources:<br> limits:<br> memory: 1.5g<br> reservations:<br> memory: 512m
按服务特性差异化配置，不一刀切
同一 compose 文件里，不同服务对资源敏感度差异极大：
-
无状态 API 服务（如 Gin/FastAPI）：可设较紧
cpus: '0.8'+mem_limit: 384m，但保留mem_reservation: 256m -
数据库（PostgreSQL/MySQL）：禁用
mem_limit或设极高值（如4g），靠shared_buffers和 OS page cache 自主管理；必须配mem_reservation防被挤占 -
消息队列（RabbitMQ/Kafka）：内存主要用于缓存和连接，建议
mem_reservation: 1g+mem_limit: 2.5g，并关闭 cgroup v2 的memory.high自动干预（需宿主机调优） -
Java 应用：务必加 JVM 参数
-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0，避免 JVM 无视 cgroup 限额申请超量内存
宿主机级协同调优不可少
Compose 的资源配置最终落地到宿主机 cgroup，需配套调整：
- 检查是否启用 cgroup v2：
stat -fc %T /sys/fs/cgroup返回cgroup2fs即为 v2；v2 默认更激进，建议在/etc/default/grub中追加systemd.unified_cgroup_hierarchy=0切回 v1（Docker 默认兼容更好） - 关闭 swap 以杜绝因内存不足触发 swap-to-disk 带来的 I/O 雪崩：
sudo swapoff -a并注释/etc/fstab中 swap 行 - 调高内核 OOM 分数阈值，让关键服务（如 DB）更难被 kill：
echo -1000 > /proc/<pid>/oom_score_adj</pid>，或在 Compose 中用oom_score_adj: -500
