李钟意讲前端

外观

咨询/接单/付费bug修复/学习交流群

nginx events ​

nginx events 是什么 ​

在 Nginx 配置中，“events”块是一个用来指定与连接处理相关的配置指令的区域。

这个部分主要用来设置与工作进程和连接有关的各种行为，以下是对 Nginx events 块中一些关键指令的详细介绍：

  • worker_connections：定义每个工作进程可以打开的最大连接数。这个设置决定了单个工作进程能够同时处理的客户端连接的数量，是优化服务器性能的重要配置项。

  • use：此指令用于指定 Nginx 使用哪种事件驱动模型来处理连接请求。常见的模型包括 epoll、kqueue、select 等，具体使用哪种模型取决于你的操作系统平台。例如，epoll 在 Linux 系统上表现较好。

  • accept_mutex：启用或禁用接受互斥锁。当启用时，工作进程会尝试通过互斥锁来均匀地分摊连接请求，可能会稍微增加处理请求的延迟，但可以更公平地分配连接到各个工作进程。

  • accept_mutex_delay：当启用 accept_mutex 时，此指令设置工作进程在尝试获取互斥锁失败后，再次尝试获取锁之前的等待时间。这个延迟可以减少工作进程争夺锁的频率，从而可能降低响应时间的波动。

  • debug_connection：允许对来自特定 IP 地址的连接进行调试，使得可以更详细地记录这些连接的处理过程。这对于开发或排查特定的网络问题非常有用。

  • multi_accept：决定工作进程是否在一个监听循环中接受尽可能多的连接。开启此指令可以使工作进程在每次获得互斥锁时尽可能多地处理入站连接，从而增加吞吐量。

  • worker_aio_requests：设置每个工作进程可以同时发起的异步 I/O 操作的最大数量。这对于使用异步文件 I/O 提高 Nginx 处理请求效率时非常重要，特别是在高负载时。

这个 "events" 块位于 Nginx 配置文件的顶级（main context），这意味着它不属于任何其他块（如 http、server 或 location）的一部分。

正确配置 "events" 块对于优化 Nginx 的性能和处理能力非常关键。

nginx events 官方文档上介绍 ​

https://nginx.org/en/docs/ngx_core_module.html#events

官方文档

Syntax:	events { ... }
Default:	—
Context:	main

Provides the configuration file context in which the directives that affect connection processing are specified.

翻译后的

语法：	events { ... }
默认值：	—
上下文：	main

提供配置文件的上下文，用于指定影响连接处理的指令。

nginx events 配置的指令 ​

1. worker_connections ​

https://nginx.org/en/docs/ngx_core_module.html#worker_connections

nginx
语法：worker_connections number;
默认：
worker_connections 512;
上下文：events

设置一个工作进程可以同时打开的最大连接数。

需要记住的是，这个数字包括所有连接（例如，与代理服务器的连接等），不仅仅是与客户端的连接。
另一个考虑因素是，实际的同时连接数不能超过当前打开文件的最大数量限制，这个限制可以通过 worker_rlimit_nofile 进行更改。

英文

Details
nginx
Syntax:	worker_connections number;
Default:
worker_connections 512;
Context:	events

Sets the maximum number of simultaneous connections that can be opened by a worker process.

It should be kept in mind that this number includes all connections (e.g. connections with proxied servers, among others), not only connections with clients. Another consideration is that the actual number of simultaneous connections cannot exceed the current limit on the maximum number of open files, which can be changed by worker_rlimit_nofile.

2. accept_mutex ​

https://nginx.org/en/docs/ngx_core_module.html#accept_mutex

语法：accept_mutex on | off;
默认：
accept_mutex off;
上下文：events

如果启用 accept_mutex，工作进程将轮流接受新连接。否则，所有工作进程将被通知新连接，如果新连接的数量较低，一些工作进程可能会浪费系统资源。

在支持 EPOLLEXCLUSIVE 标志（1.11.3）或使用 reuseport 的系统上无需启用 accept_mutex。
在版本 1.11.3 之前，默认值是 on。

英文

Details
Syntax:	accept_mutex on | off;
Default:
accept_mutex off;
Context:	events

If accept_mutex is enabled, worker processes will accept new connections by turn. Otherwise, all worker processes will be notified about new connections, and if volume of new connections is low, some of the worker processes may just waste system resources.

There is no need to enable accept_mutex on systems that support the EPOLLEXCLUSIVE flag (1.11.3) or when using reuseport.
Prior to version 1.11.3, the default value was on.

3. accept_mutex_delay ​

https://nginx.org/en/docs/ngx_core_module.html#accept_mutex_delay


语法：accept_mutex_delay time;
默认：
accept_mutex_delay 500ms;
上下文：events

如果启用了 accept_mutex，指定工作进程在另一个工作进程当前接受新连接时尝试重新开始接受新连接的最长时间。
Details
Syntax:	accept_mutex_delay time;
Default:
accept_mutex_delay 500ms;
Context:	events

If accept_mutex is enabled, specifies the maximum time during which a worker process will try to restart accepting new connections if another worker process is currently accepting new connections.

4. debug_connection ​

https://nginx.org/en/docs/ngx_core_module.html#debug_connection


语法：debug_connection address | CIDR | unix:;
默认：—
上下文：events

为选定的客户端连接启用调试日志。其他连接将使用 error_log 指令设置的日志级别。调试的连接可以是 IPv4 或 IPv6（1.3.0, 1.2.1）地址或网络。也可以使用主机名指定连接。对于使用 UNIX 域套接字（1.3.0, 1.2.1）的连接，调试日志通过“unix:”参数启用。

events {
debug_connection 127.0.0.1;
debug_connection localhost;
debug_connection 192.0.2.0/24;
debug_connection ::1;
debug_connection 2001:0db8::/32;
debug_connection unix:;
...
}
Details
Syntax:	debug_connection address | CIDR | unix:;
Default:	—
Context:	events

Enables debugging log for selected client connections. Other connections will use logging level set by the error_log directive. Debugged connections are specified by IPv4 or IPv6 (1.3.0, 1.2.1) address or network. A connection may also be specified using a hostname. For connections using UNIX-domain sockets (1.3.0, 1.2.1), debugging log is enabled by the “unix:” parameter.

events {
    debug_connection 127.0.0.1;
    debug_connection localhost;
    debug_connection 192.0.2.0/24;
    debug_connection ::1;
    debug_connection 2001:0db8::/32;
    debug_connection unix:;
    ...
}

5. multi_accept ​

https://nginx.org/en/docs/ngx_core_module.html#multi_accept

语法：multi_accept on | off;
默认：
multi_accept off;
上下文：events

如果禁用 multi_accept，一个工作进程将一次接受一个新连接。否则，一个工作进程将一次接受所有新连接。

如果使用 kqueue 连接处理方法，此指令将被忽略，因为它会报告等待接受的新连接的数量。
Details
Syntax:	multi_accept on | off;
Default:
multi_accept off;
Context:	events

If multi_accept is disabled, a worker process will accept one new connection at a time. Otherwise, a worker process will accept all new connections at a time.

The directive is ignored if kqueue connection processing method is used, because it reports the number of new connections waiting to be accepted.

6. use ​

https://nginx.org/en/docs/ngx_core_module.html#use

语法：use method;
默认：—
上下文：events

指定要使用的连接处理方法。通常不需要显式指定，因为 nginx 默认会使用最有效的方法。
Details
Syntax:	use method;
Default:	—
Context:	events

Specifies the connection processing method to use. There is normally no need to specify it explicitly, because nginx will by default use the most efficient method.

7. worker_aio_requests ​

https://nginx.org/en/docs/ngx_core_module.html#worker_aio_requests

语法：worker_aio_requests number;
默认：
worker_aio_requests 32;
上下文：events
此指令出现在版本 1.1.4 和 1.0.7 中。

在使用 aio 与 epoll 连接处理方法时，设置单个工作进程的最大异步 I/O 操作数量。
Syntax:	worker_aio_requests number;
Default:
worker_aio_requests 32;
Context:	events
This directive appeared in versions 1.1.4 and 1.0.7.

When using aio with the epoll connection processing method, sets the maximum number of outstanding asynchronous I/O operations for a single worker process.

最大的连接数量 max_clients = worker processes * worker connections ​

https://stackoverflow.com/questions/23386986/what-is-worker-processes-and-worker-connections-in-nginx

Worker processes:

Nginx worker process that handles the incoming request.
Set this to worker_process auto; to automatically adjust the number of Nginx worker processes based on available cores.
This can go beyond the available cores if you have IO access.
Worker connections:

Each worker process can open by default 512 connections.
You can change this limit by worker_connections <no>.
You can set this to max limit ulimit -n.
hence,
max_clients = worker processes * worker connections

翻译后


工作进程：

Nginx 工作进程负责处理传入的请求。
将此设置为 worker_process auto; 可以根据可用的核心自动调整 Nginx 工作进程的数量。
如果您有 IO 访问，这个数量可以超过可用的核心。
工作连接：

每个工作进程默认可以打开 512 个连接。
您可以通过 worker_connections <no> 更改此限制。
您可以将此设置为最大限制 ulimit -n。
因此，
max_clients = 工作进程数 * 工作连接数

假如我的 ulimit -n 如下，那么我的服务器最大的连接数量是 max_clients 是多少？ ​

bash
[root@VM-20-6-centos ~]# ulimit -n
100001

要计算服务器的最大连接数量 max_clients，我们可以使用以下公式：

max_clients=工作进程数×每个工作进程的连接数

假设你设置了 worker_processes auto;，这将根据你服务器的 CPU 核心数自动调整工作进程的数量。然后你可以设置每个工作进程的最大连接数为 ulimit -n 的值，即 100001。

如果你的服务器有 ( N ) 个 CPU 核心，那么最大连接数将是：

max_clients=N×100001

你需要确认服务器的 CPU 核心数 ( N ) 来计算最终的 max_clients。你可以通过运行 nproc 命令在你的服务器上查看 CPU 核心数。

nproc 结果如下

bash
[root@VM-20-6-centos ~]# nproc
4

根据你的服务器配置，你有 4 个 CPU 核心。如果你将每个工作进程的连接数设置为 ulimit -n 的值，即 100001，那么你的服务器最大连接数量 max_clients 将是：

max_clients=4×100001=400004

所以，你的服务器的最大连接数量是 400004。这意味着在理论上，你的服务器能够同时处理最多 400004 个网络连接。这个计算假设了所有的资源（如网络和 I/O）都不会成为限制因素。