8核16G服务器运行多个Docker容器时，如何优化CPU和内存分配？

在 8 核 16GB 服务器上运行多个 Docker 容器时，合理的资源分配能显著提升性能与稳定性。以下是系统化的优化策略：

一、明确工作负载特征

先评估各容器的实际资源需求（通过 docker stats 或 Prometheus + cAdvisor）：

• CPU 密集型（如视频转码、计算任务）→ 需高 CPU 配额
• 内存密集型（如 Java 应用、数据库缓存）→ 需充足 RAM
• I/O 密集型（如日志写入、文件处理）→ 关注磁盘/网络 I/O
• 混合负载 → 动态调度更优

✅ 建议：部署前进行压测，获取真实使用曲线（峰值 vs 平均值）。

二、CPU 资源分配优化

1. 限制 CPU 核心绑定与配额

# 启动容器时指定 CPU 亲和性与上限
docker run -d 
  --cpus="4.0"           # 最多占用 4 个逻辑核
  --cpu-shares=512       # 相对权重（默认 1024），用于竞争场景
  --cpuset-cpus="0-3"    # 绑定到物理核 0–3（避免跨 NUMA 节点延迟）
  my-app

• --cpus：防止单个容器占满所有核
• --cpuset-cpus：提升缓存局部性，减少上下文切换
• --cpu-shares：在无硬限制时公平调度（非硬性隔离）

2. 启用 CFS 调度器参数调优

编辑 /etc/sysctl.conf：

kernel.sched_migration_cost_ns = 5000000  # 降低迁移成本（毫秒级）
kernel.sched_min_granularity_ns = 6000000

重启生效：sysctl -p

⚠️ 注意：过度调优可能影响实时性；生产环境建议保留默认值并监控 schedstat。

3. 使用 cgroups v2（推荐）

确保系统已启用 cgroups v2：

cat /sys/fs/cgroup/cgroup.controllers
# 应包含 cpu, memory, io 等

Docker 默认支持 cgroups v2（v20.10+），可启用更细粒度控制。

三、内存资源分配优化

1. 设置合理内存限制与 Swap

docker run -d 
  --memory="8g"            # 总内存上限（避免 OOM）
  --memory-swap="8g"       # 设为等于 memory 禁用 swap（防抖动）
  --memory-reservation="4g" # 软限制，触发警告但不强制终止
  my-app

• --memory-swap 设为 -1 表示无限制（不推荐），建议设为 memory + 0 禁用 swap
• 对 Java 应用额外加 -XX:MaxRAMPercentage=75.0 避免 JVM 占用全部 host 内存

2. 启用内存压缩与透明大页（THP）管理

# 检查 THP 状态
cat /sys/kernel/mm/transparent_hugepage/enabled

# 若频繁 OOM，可临时禁用（部分场景下反而提升性能）
echo never > /sys/kernel/mm/transparent_hugepage/enabled

📌 多数现代应用（尤其 Go/Rust）无需 THP，禁用可减少内存碎片。

3. 监控与告警

# 实时监控
watch -n 5 'docker stats --no-stream'

# 结合 Prometheus + Node Exporter 采集 metrics
prometheus.yml 中配置 node_exporter 和 cAdvisor

设置告警阈值：

• container_memory_usage_bytes / container_spec_memory_limit_bytes > 0.9
• rate(container_cpu_usage_seconds_total[5m]) > 0.8 * 8

四、整体架构与调度策略

五、典型配置示例（8C16G 服务器）

假设运行 4 类服务：

# docker-compose.yml 片段
services:
  api:
    cpus: 2.0
    mem_limit: 4g
    mem_reservation: 3g
    cpuset_cpus: "2-5"
    deploy:
      resources:
        limits:
          cpus: '2.0'
          memory: 4G

六、验证与调优闭环

1. 基准测试：用 stress-ng 模拟负载，观察 iostat, vmstat, pidstat
2. 分析瓶颈：
   • CPU 高但 wait 低 → 计算密集 → 增加 CPU 配额
   • CPU wait 高 → I/O 瓶颈 → 检查磁盘/网络
   • 频繁 OOM Kill → 提高 mem_limit 或优化应用缓存
3. 迭代调整：每轮变更后持续监控 24–48 小时

需要我针对您的具体应用场景（如微服务架构、AI 推理、大数据处理等）提供定制化方案吗？