Nginx 高并发性能调优：worker 进程与连接数配置指南

Nginx 之所以能轻松支撑数万甚至数十万并发连接，核心在于其事件驱动的异步架构。但默认配置往往只适用于开发环境或低流量场景，直接用于生产环境的高并发业务，很容易出现连接排队、CPU 利用不均、请求超时等问题。本文从 worker 进程与连接数两个最关键的维度出发，给出一套可落地的调优思路。

一、先理解 Nginx 的并发模型

Nginx 启动后会有一个 master 进程和多个 worker 进程。master 负责读取配置、管理 worker，真正处理请求的是 worker。每个 worker 基于 epoll（Linux）事件模型，可以同时处理大量连接，而不需要为每个连接创建一个线程或进程。

因此，Nginx 的理论并发能力可以粗略表示为：

最大并发连接数 ≈ worker_processes × worker_connections

但这个公式有两个前提：一是系统文件描述符足够，二是 worker 进程能均匀分担负载。下面逐项展开。

二、worker_processes：设多少才合适

worker_processes 决定启动多少个 worker 进程。常见的配置建议是：

worker_processes auto;

auto 会让 Nginx 自动检测 CPU 核心数并设置为相同值。这是大多数场景下的最佳实践，原因是：

• 每个 worker 是单线程事件循环，绑定一个 CPU 核心可以最大化利用 CPU 缓存，减少上下文切换。
• 如果 worker 数远大于核心数，进程间切换开销会上升，反而降低吞吐。
• 如果 worker 数小于核心数，部分 CPU 会闲置。

不过也有例外情况：

• CPU 密集型场景（如大量 SSL 握手、gzip 压缩）：可以设置为核心数或核心数 +1，留出一点余量应对突发。
• I/O 密集型场景（如大量静态文件、反向代理）：通常等于核心数即可，磁盘或后端才是瓶颈。
• 容器环境：如果容器限制了 CPU 配额，auto 可能读到的是宿主机核心数，导致 worker 过多。此时应手动指定，例如 worker_processes 4;。

三、worker_connections：单进程连接上限

worker_connections 定义每个 worker 进程能同时打开的最大连接数。默认值通常是 512 或 1024，对于高并发场景明显偏低。

events {
    worker_connections 10240;
}

调整时需要注意几点：

1. 连接数不等于请求数。在反向代理场景中，Nginx 既作为客户端连接后端，又作为服务端连接前端，一个请求可能占用两个连接。因此实际可处理的并发请求数约为 worker_connections / 2。
2. 不能超过系统限制。worker_connections 受 worker_rlimit_nofile 和系统 ulimit -n 约束。建议同时设置：

worker_rlimit_nofile 65535;

events {
    worker_connections 32768;
    use epoll;
    multi_accept on;
}

3. multi_accept on 让 worker 一次尽可能多地接受新连接，在高并发短连接场景下能提升吞吐。但在长连接为主的场景中收益有限，可按需开启。
4. use epoll 在 Linux 上是默认且最高效的事件模型，显式写出可以避免在不同系统间迁移时出现意外。

四、系统层面的配套调优

仅改 Nginx 配置是不够的，操作系统层面的限制往往才是真正的瓶颈。

文件描述符限制：每个连接对应一个文件描述符。需要同时调整：

# /etc/security/limits.conf
* soft nofile 65535
* hard nofile 65535

并在 Nginx 配置中通过 worker_rlimit_nofile 显式声明。

内核参数：高并发下建议调整以下参数：

net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1

somaxconn 决定 accept 队列长度，如果太小，高并发时会出现连接被丢弃的情况。tcp_tw_reuse 允许复用 TIME_WAIT 状态的连接，对短连接密集的服务很有帮助。

五、如何验证配置是否生效

调整后不要凭感觉判断，应该用数据验证：

• nginx -t 检查配置语法。
• nginx -s reload 平滑重载，避免中断现有连接。
• 查看 worker 进程数：ps -ef | grep nginx。
• 查看连接状态：ss -s 或 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'。
• 压测工具如 wrk、ab、hey 可以模拟并发，观察 QPS、延迟和错误率。

如果压测中发现 TIME_WAIT 过多，说明短连接回收压力大；如果 SYN 队列溢出，说明 somaxconn 或 tcp_max_syn_backlog 偏小；如果某个 worker 的 CPU 明显高于其他，可能是负载均衡或连接分配不均。

六、常见误区

误区一：worker_connections 设得越大越好。 实际上每个连接都会占用内存，设置过大而系统文件描述符跟不上，反而会导致 worker 启动失败或运行异常。

误区二：忽略后端连接池。 在反向代理场景中，Nginx 到后端的连接同样消耗资源。配合 upstream 的 keepalive 指令复用长连接，可以显著降低后端压力。

误区三：只调 Nginx 不调系统。 很多“调优无效”的案例，根源都在 ulimit 或内核参数没有同步调整。

小结

Nginx 高并发调优的核心逻辑是：让 worker 数量匹配 CPU 核心，让连接上限匹配系统资源，让内核参数匹配业务特征。worker_processes auto 加合理的 worker_connections，再配合 worker_rlimit_nofile 和内核参数调整，通常就能覆盖大部分高并发场景。真正的调优不是照搬参数，而是结合压测数据持续迭代。

未经允许不得转载：任鹏个人博客 » Nginx 高并发性能调优：worker 进程与连接数配置指南