worker_processes设置过大会间接加剧内存压力并触发swap，因其使每个worker独立维护连接上下文、缓冲区和文件描述符，总量逼近物理内存上限，叠加IO竞争导致page cache被大量换出；需结合iostat、free、vmstat等指标识别，并通过降规模、控资源及配套调优止血和长效解决。
worker_processes 设置过大，本身不直接消耗大量内存，但会显著加剧内存压力，最终触发频繁页交换（swap）。根本原因在于：每个 worker 进程都维护独立的连接上下文、缓冲区和文件描述符，进程数过多时，即使单个进程内存占用不高，总量也会迅速逼近物理内存上限；更关键的是，它常与 IO 竞争叠加，迫使系统将大量缓存页换出，以腾出空间给活跃工作集。
识别是否是 worker_processes 过大引发 swap
不要只看 top 或 htop 里 nginx 进程的 RES 值。重点观察以下指标：
- iostat -x 1 中 %wa（IO 等待）持续高于 20%，而 %util 接近 100%，同时 CPU 使用率却不高——这是 IO 瓶颈 + 内存压力的典型组合信号
- free -h 显示可用内存（available）极低，且 SwapUsed 占 SwapTotal 比例快速上升
- vmstat 1 中 si（swap in）和 so（swap out）持续大于 0，尤其是 so 高于 1000 KB/s
- 结合 cat /proc/meminfo | grep -i "swap\|memfree\|cached"，若 Cached 值异常萎缩、SwapCached 却升高，说明 page cache 正被大量换出
立即缓解：降规模 + 控资源
这不是调优，而是止血操作：
- 将 worker_processes 直接设为 1 或 2，重载配置（nginx -s reload），观察 swap 活动是否骤降
- 检查 worker_connections × worker_processes 是否远超 ulimit -n 的 70%；若超限，内核会静默失败并退化为低效模式，间接推高内存碎片
- 在 nginx 配置的 http 块中临时关闭非必要模块，例如注释掉 gzip_vary、limit_conn 等，减少每个连接的内存开销
长效解决：按 IO 特性而非 CPU 核心数设值
静态文件服务场景下，worker_processes 的合理上限由磁盘 IO 能力决定，不是 CPU 核数：
- HDD 环境：2～4 个足够。再多进程只会让磁头疯狂寻道，%wa 暴涨，page cache 失效，系统被迫 swap
- SSD 环境：可试 8，但必须配合 iostat 观察 avgqu-sz（平均队列长度）；一旦该值 > 4 且 r/s 不再增长，说明已到争抢临界点，应停止增加
- 若静态文件总量（如图片库+前端包）远超可用内存（例如 200GB 文件跑在 64GB 内存机器上），请启用 sendfile on; tcp_nopush on;，让内核绕过用户态拷贝，大幅降低单 worker 的内存驻留需求
配套必须同步调整
只改 worker_processes 是无效的，以下三项不匹配，swap 问题必然复发：
- 系统文件描述符限制：运行 ulimit -n，确保其值 ≥ worker_connections × worker_processes × 1.5（预留冗余）；否则连接堆积会触发内核紧急分配，加剧内存抖动
- 内核 listen 队列：sysctl net.core.somaxconn 至少设为 65535，并在 nginx listen 指令后加 backlog=65535，避免新连接在队列中长时间等待、占用内存
- 禁用无意义的缓存放大：若业务本质是透传（如 CDN 边缘节点），关闭 proxy_buffering、fastcgi_buffering，防止 nginx 为每个请求额外分配几 MB 缓冲区
