worker_processes直接决定nginx工作进程数，每个进程独占内存（约10–15mb基础开销），缓冲区、连接池、缓存等均按worker独立分配，导致内存线性增长；推荐设为auto或cpu核心数，避免超核引发调度与内存浪费。
worker_processes 直接决定 Nginx 启动多少个独立工作进程，而每个进程都有一份完整的内存副本——这不是共享的，而是各自加载配置、维护连接状态、分配缓冲区。所以内存占用基本是线性增长的：进程越多，基础开销越大。
每个 worker 进程自带固定内存开销
一个 worker 进程即使空闲，也会常驻约 10–15 MB 内存，包括代码段、配置解析结果、模块初始化数据、共享内存映射区等。比如设为 worker_processes 4，仅进程基础部分就占掉约 48 MB；设为 1，则这部分只有 12 MB 左右。这部分开销和连接数无关，纯属“启动成本”。
缓冲区和连接状态按 worker 独立分配
很多关键缓冲配置（如 client_header_buffer_size、proxy_buffers、ssl_session_cache）都是 per-worker 的。例如：
- 启用 open_file_cache 时，每个 worker 都会缓存自己的文件句柄和元数据，不是共用一套
- 使用 lua_shared_dict 但没声明为 shared，就会在每个 worker 里重复创建一份哈希表
- 反向代理场景下，upstream keepalive 连接池 也是每个 worker 单独维护，worker 数翻倍 → 空闲后端连接数可能翻倍 → 长期占用更多 socket 和内存
高 worker 数会放大低效行为的代价
当 worker 数超过 CPU 核心数，不仅调度开销上升，还会让原本可控的资源消耗被放大：
- 大量空闲连接保留在每个 worker 中，虽然单个只占几百字节，但乘以 worker 数和连接数，总量不可忽视
- 若配置了较大的 client_body_buffer_size 或启用了 gzip，每个活跃请求在每个 worker 里都可能分配临时 buffer，worker 越多，buffer 总量越容易突破预期
- 日志缓冲、access_log 文件句柄、limit_req 共享内存的管理结构，都会因 worker 增多而间接增加管理负担
合理设置能显著控住内存水位
在多数场景下，并不需要靠堆 worker 数来提升性能。更有效的做法是：
- 用 worker_processes auto（推荐），它等于系统逻辑 CPU 数，兼顾并发与效率
- 低内存环境（如 1GB VPS）直接设为 1，再配合调小 worker_connections、关闭 access_log、禁用 open_file_cache 和 ssl_session_cache
- 容器部署时，若限制了 CPU 核数（如 K8s 中
resources.limits.cpu: "2"），必须显式设为 worker_processes 2，否则 auto 会读宿主机核数，导致资源错配
