worker_processes 应设为物理核心数，禁用超线程；推荐手动指定而非auto，配合worker_cpu_affinity绑定核心、accept_mutex off、multi_accept on及rlimit调优，以提升计算密集型场景的cpu利用率与稳定性。
worker_processes 本身不直接管理任务队列，Nginx 原生也不提供“计算任务队列”机制——它本质是事件驱动的 I/O 处理器，不是通用任务调度器。所谓“计算密集型请求”，比如 HTTPS 加解密、实时图片缩放、WASM 模块执行或集成 OpenClaw 类推理网关，实际消耗的是 CPU 时间片。优化的关键不是加队列，而是让每个 worker 进程专注、稳定、低干扰地跑满可用 CPU 资源。
按物理核心数设 worker_processes，禁用超线程冗余
计算密集型场景下，上下文切换和跨核缓存失效比 I/O 等待更伤性能。此时应优先匹配物理核心数，而非逻辑核数（含超线程）：
- 查真实物理核数：
lscpu | grep "Core(s) per socket" && lscpu | grep "Socket(s)"，相乘得总数 - 例如：2 路 × 6 核 = 12 物理核 → 设
worker_processes 12; - 避免用
auto—— 它默认读逻辑核，可能在 12 物理核 + 超线程环境下启 24 个进程，反而引发争抢 - 不建议设为物理核数+1 或 ×1.5，压测显示超过物理核后 QPS 可能下降 10%～30%
绑定 CPU 核心，锁住缓存局部性
每个 worker 必须固定运行在专属物理核上，防止迁移导致 L1/L2 缓存反复失效：
- 启用
worker_cpu_affinity auto;（Nginx ≥1.9.10），自动一对一绑定 - 或手动指定（如 8 核）：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; - 搭配
worker_priority -5;提升调度权重，减少被抢占概率
关闭干扰机制，减少内核调度开销
计算密集型请求通常持续占用 CPU，传统“公平抢连接”策略反而引入无谓竞争：
- 在
events块中设accept_mutex off;—— 允许多个 worker 同时尝试 accept，但因计算耗时长，新连接实际仍由空闲 worker 接收，整体吞吐更稳 - 设
multi_accept on;，让单次唤醒尽可能处理多个就绪连接，降低 epoll_wait 频次 - 禁用
epoll ET 模式以外的模式（如 select/poll），确保高负载下事件分发效率
配套资源必须刚性对齐
worker 进程数调优只是起点，内存与文件描述符必须同步释放瓶颈：
-
worker_rlimit_nofile 65535;写在 main 块，确保每个 worker 可打开足够句柄 -
events { worker_connections 2048; }—— 计算型服务单 worker 并发连接数不宜过高，2k～4k 更利于 CPU 专注运算 - 系统级限制同步调高：
ulimit -n 65535，并写入/etc/security/limits.conf - 若用 OpenSSL 3.x 或 BoringSSL，开启
ssl_buffer_size 4k;减少加解密缓冲区抖动
