nginx多进程优化核心是减少争抢、避免浪费、提升局部性，而非进程间共享内存；需使worker_processes与物理cpu核心数对齐并启用worker_cpu_affinity绑定核心，保持accept_mutex开启防惊群，统一配置ulimit与worker_rlimit_nofile，并利用内核机制实现文件缓存与共享内存区的高效访问。
Nginx 多进程架构本身不共享内存，每个 worker 进程独立运行，但资源使用效率取决于配置协同与系统配合。优化核心不是让进程“共享”，而是减少争抢、避免浪费、提升局部性。
worker_processes 与 CPU 核心数对齐
每个 worker 进程应绑定一个物理 CPU 核心，避免调度抖动和缓存失效。超线程（如 4核8线程）通常只按物理核心数设值，比如 worker_processes 4；设为 8 反而可能因 L1/L2 缓存争用降低性能。
- 使用
worker_processes auto;是安全起点，但容器或虚拟机中建议显式指定，防止误读 vCPU 数量 - 查看真实物理核心数：
lscpu | grep "Core(s) per socket"
启用 CPU 亲和性绑定
让每个 worker 固定运行在指定核心上，减少上下文切换开销：
- 四核服务器可写：
worker_cpu_affinity 0001 0010 0100 1000; - Nginx 1.9.10+ 支持
worker_cpu_affinity auto;，自动完成一对一绑定
避免进程间无效竞争
-
accept_mutex on（默认）必须保持开启，防止多个 worker 同时唤醒争抢新连接（惊群效应），现代 epoll 已优化，无需关闭 - 不要用
worker_processes 1 + thread_pool模拟并发——线程池仅缓解阻塞型磁盘读，对网络请求无加速，反而增加锁开销
统一系统级文件描述符限制
worker 进程各自需要打开大量连接，但系统 ulimit 是按进程生效的：
- 在
/etc/security/limits.conf中设置：nginx soft nofile 65536 nginx hard nofile 65536
- 同时在 nginx.conf 全局块中加
worker_rlimit_nofile 65536;，确保 worker 启动时主动申请足够句柄
共享资源靠内核机制，而非进程通信
- 文件句柄、缓存元数据等通过
open_file_cache在各 worker 内部独立缓存，不依赖进程同步 - 共享内存区（如
zone指令定义的 limit_conn 或 upstream 状态）由 master 进程初始化，worker 以只读或原子方式访问，避免锁竞争
不复杂但容易忽略
