Nginx容器中worker_cpu_affinity必须严格匹配cgroup实际可用CPU集合（如cpuset.cpus.effective），否则因绑定宿主机编号而越界，导致setaffinity失败、负载不均；应优先用--cpuset-cpus显式限定，使auto模式安全生效。
当 Nginx 在容器中运行时，若同时配置了 worker_cpu_affinity（CPU 亲和力）和容器级 CPU 配额（如 --cpus=1.5 或 cpu.quota / cpu.period），容易出现 worker 进程被频繁调度、负载不均、甚至部分 worker 无法绑定到可用 CPU 的问题。根本原因是：Nginx 的 CPU 亲和力是基于宿主机的逻辑 CPU 编号（如 CPU0、CPU1…）静态绑定的，而容器的 CPU 配额限制通过 CFS（Completely Fair Scheduler）动态控制其可使用的 CPU 时间片，并不改变可见 CPU 列表 —— 但 Docker/Kubernetes 默认不会把容器“可见”的 CPU 集合（cpuset.cpus）同步暴露给进程，导致 Nginx 尝试绑定到实际被配额限制后不可稳定调度的 CPU 上。
确认容器实际可用的 CPU 资源视图
容器内看到的 /proc/cpuinfo 仍显示宿主机全部 CPU 核心数，这会误导 Nginx 做错误绑定。真正决定调度边界的，是 cgroup v1 的 /sys/fs/cgroup/cpuset/cpuset.cpus 或 cgroup v2 的 /sys/fs/cgroup/cpuset.cpus.effective。
- 进入容器执行：
cat /sys/fs/cgroup/cpuset/cpuset.cpus.effective 2>/dev/null || cat /sys/fs/cgroup/cpuset.cpus，查看实际被允许使用的 CPU ID 列表（如0-1或2,4） - 若输出为空或为
0-63（全量），说明未设置cpuset，此时 CPU 配额仅靠cpu.cfs_quota_us限时间，不隔离 CPU 实体 —— 这正是冲突高发场景 - 对比
lscpu | grep "CPU(s):"输出，确认容器“感知”的 CPU 数 ≠ 实际受控的可用 CPU 集合
检查 Nginx worker_cpu_affinity 是否越界或冗余
worker_cpu_affinity 的掩码必须严格对应容器 实际能稳定调度到的逻辑 CPU ID，而非宿主机编号或容器“看到”的总数。
- 假设
cpuset.cpus.effective返回2,4，即只有 CPU2 和 CPU4 可用，则合法的 affinity 配置只能是：worker_cpu_affinity 00000100 00010000;（分别对应 CPU2 和 CPU4，位序从右往左，CPU0 是最低位） - 若写成
auto，Nginx 会按/proc/cpuinfo的 core count 绑定前 N 个 CPU（如 8 核就绑 0–7），很可能包含不可用 CPU，造成 bind 失败（日志报setaffinity failed (22: Invalid argument)） - 使用
nginx -t不会校验 affinity 有效性，需运行时看 error log 或taskset -pc $(pgrep nginx)确认实际绑定结果
优先使用 cpuset 代替纯配额，让 Nginx “感知”真实 CPU 集
单纯用 --cpus=1.5（即 cfs_quota）无法缩小容器可见 CPU 列表，推荐显式指定 --cpuset-cpus，让容器内 /proc/cpuinfo 与调度域一致。
- 启动容器时明确限定物理核心：
docker run --cpuset-cpus="2,4" --cpus=2 nginx - Kubernetes 中通过
resources.limits.cpu+resources.limits."cpu.kubernetes.io/cores"（需 kubelet 支持）或使用TopologyManager配合static策略实现类似效果 - 此时容器内
lscpu显示 CPU 数 = cpuset 长度，worker_cpu_affinity auto才真正安全；也可手动写死为01、10等对应掩码
验证与调试关键命令
快速定位是否因 affinity 冲突导致异常：
- 查 Nginx 错误日志：
grep -i affinity /var/log/nginx/error.log，关注Invalid argument或Operation not permitted - 看 worker 实际绑定：
for p in $(pgrep nginx); do echo "PID $p:"; taskset -pc $p; done，若显示pid's current affinity list: empty，说明绑定失败 - 对比宿主机视角：在宿主机运行
ps -o pid,psr,comm -C nginx，观察 PSR（processor）列是否集中在某几个 CPU，且与容器 cpuset 设置匹配 - 临时关闭 affinity 测试：注释掉
worker_cpu_affinity，观察 CPU 使用率是否更均衡、%sys 是否下降（减少上下文切换开销）
