应设为 cpu 物理核心数，如2路×6核=12物理核；容器内需查cgroup限制；worker_processes与worker_cpu_affinity数量须一致且精准绑定，并同步调高文件描述符、启用epoll等配套参数。
直接设为 CPU 物理核心数，是最稳妥的起点。别盲目用 auto，也别照搬逻辑核数量——关键在匹配真实硬件资源和业务类型。
先确认你真正能用的 CPU 核心数
尤其在容器或云环境里，宿主机信息不可靠：
- 查物理拓扑：
lscpu | grep -E "(Core\(s\) per socket|Socket\(s\))"，算出物理核心总数（比如 2 路 × 6 核 = 12 物理核） - 查逻辑核总数：
lscpu | grep "CPU(s):"，若显示 24，说明超线程已开；但通常仍只设worker_processes 12 - 容器内运行？看 cgroup 限制：
cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us和/sys/fs/cgroup/cpu/cpu.cfs_period_us，相除得实际分配 vCPU 数
设置 worker_processes 和 worker_cpu_affinity
两者必须数量一致，且绑定要精准：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 推荐起步写法：
worker_processes 12;+worker_cpu_affinity auto;（Nginx ≥ 1.9.10 支持，自动跳过超线程对称核，适配 NUMA） - 手动掩码更可控：4 核写成
0001 0010 0100 1000；8 核可简写为01 02 04 08 10 20 40 80（十六进制，不易数错位） - 错误示例：8 核却只给 4 组掩码，或掩码位数超过系统逻辑 CPU 总数，会导致部分 worker 失去绑定
必须同步调整的配套参数
光调进程数和亲和性，效果会打折甚至失效：
-
worker_rlimit_nofile 65535;—— 在 main 块中提升单进程文件描述符上限 - events 块内：
use epoll;、multi_accept on;、worker_connections 4096;（按需调高，如 10240） - 系统级 ulimit 要跟上：
* soft nofile 65535和* hard nofile 65535写入/etc/security/limits.conf - 关闭干扰项：
accept_mutex off;（配合reuseport on;更优），避免“惊群”反而拖慢调度
验证是否真生效
改完不验证等于没改：
- 重载后执行：
ps -eo pid,psr,comm | grep nginx，检查各 worker 的psr（CPU 编号）是否分散且不重复 - 挑一个 worker PID，运行：
taskset -cp <pid></pid>，确认输出的 allowed CPUs 是预期的那个核 - 观察
htop：所有 worker 的 %CPU 应大致均衡，总和接近 N×100%（N 为 worker 数）
