优化Nginx工作进程以实现最大性能：实用指南

Nginx可以用很小的进程足迹处理大量并发连接，但前提是其工作进程限制与底层机器相匹配。人们首先接触的两个设置是worker_processes和worker_connections。它们很有用，但也容易被过度调优。将两者都设置为巨大的数字并不能创造免费容量，而只是将瓶颈转移到文件描述符、内存、上游服务器或网络栈。

实际目标是给Nginx足够的工作进程来使用其拥有的CPU核心，足够的连接槽位来应对真实流量，以及足够的操作系统限制来避免在正常突发期间达到上限。

理解Nginx工作进程架构

Nginx采用主从模型运行。主进程负责读取和验证配置、绑定端口以及管理工作进程。它执行非关键任务，如监控系统资源和必要时重启工作进程。

工作进程是执行繁重任务的地方。这些进程是单线程的（在标准Nginx编译中），并使用非阻塞系统调用。每个工作进程通过事件循环高效处理数千个并发连接，使得一个进程可以管理多个请求而不阻塞，这是Nginx性能的关键。

适当的优化涉及平衡工作进程数量（将其与CPU资源绑定）和设置每个工作进程可以处理的最大连接数。

配置`worker_processes`：CPU核心因素

worker_processes指令决定Nginx应生成多少个工作进程。此设置直接影响Nginx如何利用服务器的CPU资源。

最佳实践：将工作进程与核心匹配

最常见且高度推荐的最佳实践是将工作进程数设置为服务器上可用的CPU核心数。这确保每个核心都被高效利用，而不会因上下文切换产生过多开销。

如果工作进程数超过核心数，操作系统必须频繁地在竞争Nginx进程之间切换CPU焦点（上下文切换），这会引入延迟并降低整体性能。

使用`auto`指令

对于现代版本的Nginx（1.3.8及更高版本），最简单且最有效的配置是使用auto参数。Nginx将自动检测可用的CPU核心数并相应设置工作进程。

# 大多数部署的推荐设置
worker_processes auto;

手动配置

如果您需要手动控制或使用较旧版本，可以指定确切的工作进程数。您可以使用系统工具查找核心数：

# 查找CPU核心数
grep processor /proc/cpuinfo | wc -l

如果系统有8个核心，配置将如下所示：

# 手动将工作进程设置为8
worker_processes 8;

提示： 匹配可用核心数是最安全的起点。在异常I/O密集型工作负载下，您可以测试不同的值，但在保留之前务必在真实流量下进行基准测试。对于典型的静态服务、代理和TLS终止，auto通常是最不令人意外的选择。

配置`worker_connections`：并发因素

worker_connections指令在events块内配置，定义了单个工作进程可以处理的最大同时连接数。这包括与客户端的连接、与上游代理服务器的连接以及内部健康检查连接。

计算最大客户端数

您的Nginx服务器可以处理的最大并发客户端连接数的理论计算公式如下：

$$\text{最大客户端数} = \text{worker_processes} \times \text{worker_connections}$$

如果您有4个工作进程，每个进程有10,000个工作连接，Nginx理论上可以处理40,000个同时连接。

这个数字只是一个粗略的上限。代理请求可能同时使用一个客户端连接和一个上游连接。WebSocket和长轮询流量可能比正常页面请求占用槽位更长时间。Keep-alive连接也可能在几乎不做任何工作的情况下保持打开。如果Nginx主要服务静态文件，计算更接近简单公式。如果它充当反向代理，请留出余量。

设置连接限制

在繁忙的服务器上，通常将worker_connections设置为几千或更多，前提是内存和文件描述符限制可以支持。不要盲目复制一个大值；选择一个与预期并发量加上突发余量相匹配的值。

# events块的示例配置

events {
    # 每个工作进程的最大并发连接数
    worker_connections 16384;

    # 在突发期间可能有帮助，但在负载下测试公平性。
    multi_accept on;
}

系统限制（`ulimit`）约束

关键的是，worker_connections设置受操作系统对每个进程允许的打开文件描述符（FD）数量的限制，通常由ulimit -n设置控制。

Nginx无法打开超过操作系统允许文件描述符的连接。由于每个连接（客户端套接字、日志文件、代理套接字）都需要一个文件描述符，因此系统限制必须设置得足够高。

检查和提高文件描述符限制

检查当前限制：
```
ulimit -n
```
临时提高限制（针对当前会话）：
```
ulimit -n 65536
```
永久提高限制（通过/etc/security/limits.conf）：

添加以下行，将nginx_user替换为Nginx运行的用户（通常是www-data或nginx）：
```
# /etc/security/limits.conf
nginx_user soft nofile 65536
nginx_user hard nofile 65536
```

警告： 确保Nginx工作进程用户的每个进程文件描述符限制高于worker_connections，并为日志、上游套接字、缓存文件和其他打开文件留出额外空间。系统范围限制也很重要，但每个进程限制是最常让人意外的地方。

如果Nginx由systemd管理，/etc/security/limits.conf可能不够。许多发行版从单元文件启动服务时带有限制。使用以下命令检查活动限制：

cat /proc/$(pgrep -o nginx)/limits | grep "open files"

对于systemd覆盖，使用：

sudo systemctl edit nginx

然后添加：

[Service]
LimitNOFILE=65536

在维护窗口期间重新加载systemd并重启Nginx：

sudo systemctl daemon-reload
sudo systemctl restart nginx

高级调优和监控

除了核心指令外，还有一些额外的考虑因素可以帮助微调性能：

1. 绑定工作进程

在高性能环境中，特别是在具有多个CPU插槽（NUMA架构）的系统上，您可能希望使用worker_cpu_affinity指令。这告诉操作系统将特定工作进程限制到特定CPU，这可以通过确保CPU缓存保持热状态并避免内存局部性问题来提高性能。

8核系统的示例：

worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

此设置很复杂，通常仅对极端高负载情况有益；对于大多数部署，worker_processes auto就足够了。

2. 监控性能指标

应用优化后，监控影响至关重要。使用Nginx Stub Status模块（或Prometheus/Grafana等工具）跟踪关键指标：

指标	描述	优化检查
活动连接	当前处理的连接总数。	应低于理论最大值。
读取/写入/等待	不同状态的连接。	高等待计数通常表示长寿命HTTP Keep-Alives（好）或处理资源不足（坏）。
请求速率	每秒请求数。	用于衡量配置更改后的实际性能改进。

如果您观察到所有核心的CPU利用率高且请求速率高，则您的worker_processes可能配置正确。如果在高峰流量期间有空闲的CPU核心，请考虑检查您的配置或检查Nginx外部的阻塞I/O操作。

3. 连接溢出策略

如果服务器达到最大连接限制（worker_processes * worker_connections），新连接可能会失败或排队直到超时。只有当Nginx是实际瓶颈时，增加worker_connections才有帮助。如果上游应用服务器饱和，提高限制可能会使故障感觉更糟，因为更多请求堆积在慢速后端后面。

使用错误日志作为信号。像worker_connections are not enough这样的消息直接指向Nginx限制。upstream timed out、connect() failed或502/504响应的增加更指向后端容量、网络问题或超时设置。

合理的起始配置

对于小型或中型反向代理，这是一个合理的基线：

worker_processes auto;
worker_rlimit_nofile 65536;

events {
    worker_connections 8192;
    multi_accept off;
}

为什么这里使用multi_accept off？这是许多系统上的保守默认值。启用它可以帮助工作进程快速排空待处理的accept队列，但在某些流量模式下，它可能让一个工作进程抓取大量批次而其他工作进程空闲。如果您有突发流量并且有测试理由启用它，请这样做。如果您正在调优通用Web服务器，保持基线简单并先测量。

如果服务器处理许多WebSocket连接、服务器发送事件或长寿命API流，请更积极地提高连接限制并密切关注内存。拥有20,000个大部分空闲WebSocket客户端的服务器与处理20,000个短静态文件请求的服务器具有不同的配置文件。

如何验证更改

在更改生产环境之前，捕获一个小基线：

nginx -T | grep -E 'worker_processes|worker_connections|worker_rlimit_nofile'
ss -s
ulimit -n

更改后，检查Nginx是否实际加载了它：

sudo nginx -t
sudo systemctl reload nginx
ps -o pid,comm,nlwp,pcpu,pmem -C nginx
cat /proc/$(pgrep -n nginx)/limits | grep "open files"

然后在真实流量期间观察行为。如果所有CPU核心都繁忙且延迟上升，Nginx可能正在做有用工作并达到CPU容量。如果CPU低但连接排队或超时，请查看文件描述符、上游饱和、DNS解析、磁盘I/O或防火墙限制。工作进程调优是一个杠杆，而不是整个性能故事。

在上下文中解读数字

一个常见错误是将“活动连接”视为与“活动用户”相同。事实并非如此。一个浏览器可以打开多个连接以获取资源。一个API客户端可以在请求之间保持连接存活。一个WebSocket客户端可以保持连接数小时而几乎不发送流量。当您调整worker_connections时，要考虑并发套接字，而不是用户。

对于反向代理，还要记住上游端。如果4,000个客户端在等待代理响应，Nginx可能也持有数千个上游套接字。这就是为什么服务器可能在简单的客户端计算表明应该足够之前就用完文件描述符。当上游应用程序变慢时，这一点尤其明显：请求保持打开时间更长，并发性上升，Nginx开始消耗更多套接字，即使传入请求速率没有变化。

Keep-alive设置也会影响这一点。长keep-alive超时减少连接波动，这有助于繁忙站点，但它们也会使空闲套接字保持更长时间。非常短的keep-alive超时更快释放套接字，但可能增加TLS握手和连接建立开销。没有完美的值；使用流量形状作为指导。具有许多短访问的公共网站可能需要与具有少量持久客户端的内部API不同的平衡。

如果您在容器内调优，请验证容器内以及主机或编排器级别的限制。Kubernetes Pod、Docker容器或systemd服务可能具有比您用于测试的主机shell更低的nofile限制。始终检查正在运行的Nginx进程，而不仅仅是您的登录会话。

最佳实践总结

指令	推荐值	理由
`worker_processes`	`auto`（或核心数）	确保最佳CPU利用率并最小化上下文切换开销。
`worker_connections`	从几千开始；根据测量的并发性提高	提供连接余量而不隐藏其他瓶颈。
操作系统限制（`ulimit -n`）	高于每个工作进程的连接需求，并留出额外空间	为客户端套接字、上游套接字、日志和缓存文件提供文件描述符。
`multi_accept`	在启用前测试	在突发期间可能有帮助，但并非对每个工作负载都自动更好。

最佳的Nginx工作进程配置通常是简单的：worker_processes auto，反映真实并发性的连接限制，以及足够高以应对工作负载的文件描述符限制。调优它，验证活动进程限制，并持续关注错误日志。如果症状指向上游，修复上游而不是让Nginx接受比应用程序能完成的更多工作。