worker_processes 应设为 CPU 物理核心数或使用 auto（Nginx 1.3.8+ 自动适配），必须置于 nginx.conf 全局块，配合 worker_cpu_affinity 绑定核心、调高 ulimit -n 和 worker_connections 才能发挥多核性能。

Nginx 中没有“工作线程”（thread）的概念，它采用的是多进程（multi-process）模型，每个 worker 进程是单线程、事件驱动的。所以你在 nginx.conf 里配置的不是“线程数”，而是 worker 进程数，由 worker_processes 指令控制。

这个值直接决定 Nginx 并发处理能力的底层规模，也是最常被优化的核心参数之一。

---

✅ 正确配置 worker_processes 的位置和写法

在 nginx.conf 文件顶部的全局块（main context）中设置：

worker_processes 4;

或更推荐的方式（自动适配 CPU 核心数）：

worker_processes auto;

⚠️ 注意：worker_processes 只能出现在全局块（即文件最外层），不能写在 events、http、server 或 location 块内。

---

? 如何确定该设多少？

• 查看服务器 CPU 核心数：

  

  Pandas 配置文件报告生成器

  使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。

  下载

  grep -c processor /proc/cpuinfo
  # 或
  nproc

• 推荐取值：

  • 一般设为 CPU 物理核心数（如 4 核 → worker_processes 4;）
  • 高负载、高 I/O 场景可尝试 核心数 × 2（但不建议超过 8，否则上下文切换开销反而降低性能）
  • auto 是安全且智能的选择，Nginx 启动时会读取系统信息自动设定

---

? 配合调整的关键参数（不能只改进程数）

worker_processes 升高后，必须同步检查并调整以下两项，否则可能因资源不足而报错或性能不升反降：

• 每个 worker 能打开的最大连接数（在 events 块中）：

  events {
      worker_connections 4096;
  }

  总并发连接 ≈ worker_processes × worker_connections
  若设 4 × 4096 = 16384，则需确保系统级文件描述符限制 ≥ 16384（见下条）

• 系统级文件描述符限制（Linux）：

  • 编辑 /etc/security/limits.conf，添加：

    nginx soft nofile 65535
    nginx hard nofile 65535

  • 并确认 systemd 服务未覆盖限制（如使用 systemctl edit nginx 加 LimitNOFILE=65535）

---

✅ 验证是否生效

重启后执行：

ps aux | grep 'nginx: worker'
# 应看到对应数量的 worker 进程（不含 master 进程）

nginx -t  # 先测试语法
systemctl restart nginx

---

Nginx 的并发模型简单高效，但容易误以为是“多线程”。只要记住：改 worker_processes，调 worker_connections，配系统 nofile 限制，三者协同，就踩准了性能优化的第一步。