容器内应用进程数需适配cgroup cpu配额，而非数量相等：i/o密集型应限制线程池大小，cpu密集型可设线程数接近等效核数，java需用activeprocessorcount和forkjoinpool调优，node.js/python应通过多进程匹配配额，并用cpu.stat和pidstat验证避免限频。
容器内应用的进程数与 cgroups cpu 配额要对齐，关键不是“数量相等”，而是让应用的实际并发行为适配你通过 cgroup 设定的 cpu 时间上限。否则容易出现两种典型问题：一种是应用开了几十个线程却只分到 0.5 核配额，大量线程争抢时间片、上下文切换飙升；另一种是配了 4 核但应用只用单线程，资源白白浪费。
CPU 配额本质是时间 slice，不是核心数
cgroups 的 cpu.cfs_quota_us / cpu.cfs_period_us 控制的是单位周期内允许使用的总 CPU 时间（微秒），和物理核心数没有直接换算关系。比如：
- 配额 = 100000，周期 = 100000 → 等效于 100% 单核，但这个“单核”可以是任意一个逻辑 CPU，也可以被调度到多个核心上轮转；
- 配额 = 200000，周期 = 100000 → 允许每 100ms 用掉 200ms CPU 时间，即平均 2 核等效能力（但不保证同时占用 2 个物理核）。
所以对齐的第一步，是明确你设的配额对应多少“平均可用 CPU 时间”，而不是去数容器里开了几个进程或线程。
根据应用类型反推合理进程/线程数
不同架构的应用对并发模型依赖不同，应据此调整内部并发规模：
- I/O 密集型（如 Web API、代理服务）：常依赖多线程/协程处理并发请求。若 cgroup 配额仅 0.5 核（quota=50000），建议线程池 size ≤ 2～4，避免过度创建线程导致调度开销反超收益；
- CPU 密集型（如数据计算、编码转码）：适合接近配额所代表的“等效核数”。例如配额为 300000（3 核等效），可设最大工作线程数为 3 或略高（如 4），留出调度余量；
- Java 应用：需同时考虑 JVM 的 GC 线程、JIT 编译线程及业务线程。可通过 -XX:ActiveProcessorCount=N 强制 JVM 感知 cgroup 限制，并配合 java.util.concurrent.ForkJoinPool.common.parallelism 控制并行度；
- Node.js / Python（GIL）：单进程天然受限于单线程 CPU 利用率，若需更高吞吐，应部署多个进程（如 PM2 cluster 模式或 Gunicorn worker 数），总进程数 × 单进程预期 CPU 使用率 ≈ 配额占比。
验证与动态调优方法
配完不能只靠估算，要用工具观察真实行为：
- 进容器执行 cat /sys/fs/cgroup/cpu.stat，重点关注 nr_throttled（被限频次数）和 throttled_time（总限频时长）。如果这两项持续增长，说明配额太紧，应用在频繁等待 CPU；
- 用 pidstat -t -u 1 查看各线程实际 CPU 使用率，确认是否大量线程长期处于 %CPU ≈ 0 或 wait 状态；
- 对 Java 应用，加 JVM 参数 -XX:+PrintGCDetails -Xlog:safepoint，观察 GC 是否因 CPU 不足而延迟触发或卡顿；
- 调整后压测，对比响应时间 P99 和系统负载（uptime 中的 load average），目标是 load 值稳定在配额数值附近（如配 2 核，load≈2.0），而非越低越好。
避免常见错配陷阱
几个高频误操作：
- 把 --cpus=2 当成“固定分配 2 个物理核”，其实它底层仍是 cfs quota，只是 docker 封装后的表达。若宿主机繁忙，仍可能被调度到不同核上；
- 在 cgroups v1 下混用 cpu.shares 和 cpu.quota，前者是相对权重，后者是绝对上限，两者逻辑冲突，优先级也难预测；
- 未关闭容器内应用的自动伸缩机制（如 Spring Boot 的 Tomcat max-threads 默认 200），导致即使配额只有 0.2 核，也照常起上百线程，徒增内核调度压力；
- 忽略容器 init 进程（PID 1）的资源归属——它及其子进程默认继承整个 cgroup 配额，所有业务进程共享同一份 quota，不是各自独占。
