本质是cpu时间片未被操作系统公平分配，需从进程绑定、内核调度、流量特征三方面排查：检查worker_cpu_affinity配置、软中断分布及ip hash等业务特征是否导致伪不均。
多核调度不均导致单个 Nginx worker 进程负载过高，本质是 CPU 时间片未被操作系统公平分配，而非 Nginx 自身逻辑错误。这类问题在 8 核及以上服务器上较常见，表现为部分 worker 进程 CPU 占用长期超 80%，而其他进程 idle；连接数、fd 数、请求处理量也明显失衡。排查需从进程绑定、内核调度、流量特征三方面切入。
确认是否为真实不均：先看进程级指标
不要只依赖 top 的平均 CPU，要定位到具体 worker 进程：
- 查所有 worker PID：
ps -eo pid,comm,psr,pcpu --sort=-pcpu | grep 'nginx: worker'（psr列显示实际运行的 CPU 核号） - 对比各 worker 的连接数：
sudo ls /proc/<pid>/fd/ 2>/dev/null | wc -l</pid> - 检查每个 worker 绑定的 CPU：
taskset -p <pid></pid>，若输出如current affinity list: 0,2,4,6，说明未严格绑核；若为0，则固定在 core 0 —— 这正是不均的根源之一
检查 Nginx 是否启用 CPU 亲和性（worker_cpu_affinity）
这是最常被忽略的配置项。默认情况下，Nginx 不强制绑定 CPU，由内核调度器决定，容易出现“热点核心”：
- 在
nginx.conf的events块外（即 main 上下文）检查是否存在：worker_cpu_affinity auto;或显式配置如worker_cpu_affinity 00000001 00000010 00000100 ...; -
auto模式要求 Nginx ≥ 1.9.10，且仅在worker_processes auto时生效；若手动设为数字（如worker_processes 8），必须配对应数量的掩码 - 配置后务必
nginx -t && nginx -s reload，否则不生效
验证内核调度与中断分布是否干扰
即使 Nginx 绑核正确，网卡软中断（softirq）或定时器中断若集中在某几个 core，也会“挤占” worker 进程的 CPU 时间：
- 查看软中断分布：
cat /proc/softirqs | grep -E "(NET_RX|TIMER)"，观察各列数值是否严重倾斜 - 检查网卡队列绑定：
ethtool -l eth0看是否开启多队列，再用cat /proc/irq/*/smp_affinity_list | grep eth0确认中断是否分散到所有 CPU - 若发现中断全落在 core 0–3，可用
echo "0-7" > /proc/irq/<irq_num>/smp_affinity_list</irq_num>手动均衡（需 root）
排除流量模式导致的伪不均
某些场景下，看似“不均”，实则是业务特征所致：
- 使用 IP Hash 或一致性哈希时，固定客户端会始终落到同一 worker，该 worker 连接数天然偏高 —— 查 access.log 中
$remote_addr分布即可验证 - 长连接（如 WebSocket、MQTT over HTTP）维持时间远超普通请求，一个 worker 可能堆积数百个空闲连接，但实际处理压力不大；此时应结合
$request_time和$upstream_response_time判断是否真有计算瓶颈 - 若日志中大量请求的
$request_time远大于$upstream_response_time，说明阻塞发生在 Nginx 本体（如 rewrite、Lua 脚本、SSL 握手），需单独优化
