Docker Compose通过deploy.resources.limits设置CPU和内存硬上限（如cpus: '0.5'、memory: 512M），防止容器抢占资源导致系统崩溃；reservations提供软预留保障最低资源，仅在Swarm模式生效。
直接用参数或配置文件设上限，核心是控制 CPU 和内存，避免一个容器拖垮整台机器。
CPU 限制：别让一个容器抢光所有算力
CPU 控制分两种逻辑：硬限制和相对权重。
-
--cpus 是硬性上限，比如
--cpus 1.5表示最多用 1.5 个逻辑核心，超了就 throttle，适合关键服务稳住性能 - --cpu-shares 是软性比例，默认 1024，值越高在资源争抢时分到的 CPU 时间越多；比如两个容器分别设 2048 和 1024，前者大概率获得双倍执行时间
- 单独用 --cpu-quota + --cpu-period 可精细调度（如每 100ms 最多运行 50ms），但日常用
--cpus更直观
内存限制：防 OOM 的关键防线
内存没限制最危险——容器吃满内存会触发系统 OOM Killer，随机杀进程，可能干掉数据库或监控。
-
-m / --memory 是硬上限，比如
-m 512m，超了容器直接被终止 -
--memory-swap 控制「内存 + swap」总和，
-m 512m --memory-swap 1g表示最多用 512MB 内存 + 512MB swap - --memory-reservation 是软保留，告诉调度器“我至少要这么多”，但不强制保障；实际只在资源紧张时起作用
- 生产环境建议
--memory设为宿主机物理内存的 1/4 到 1/2，留足系统和其他进程余量
Docker Compose 里怎么配
在 docker-compose.yml 的 deploy.resources 下写清楚 limits 和 reservations：
-
limits.cpus: '0.8'和limits.memory: 768M是硬性天花板 -
reservations.cpus: '0.3'和reservations.memory: 256M是最低保障（仅 Swarm 模式生效，单机 Compose 实际按 limits 执行） - 不写 reservations 也没关系，但写上能让资源规划更透明，尤其多人协作时
配完还得验证和观察
光设参数不够，得确认它真起作用：
- 启动后用
docker stats <容器名>看实时 CPU%、MEM USAGE / LIMIT - 进容器跑
cat /sys/fs/cgroup/memory/memory.limit_in_bytes查内存硬限是否生效 - 压测时故意制造高负载，观察是否被 throttle 或 OOM kill，再调参数
- 配合 cAdvisor 或 Prometheus+Node Exporter 做长期趋势分析，避免“设了等于没设”
