nginx 并发数问题思考:worker_connections,worker_processes与

原文http://liuqunying.blog.51cto.com/3984207/1420556

我相信,很多人都跟我一样,看书都不会太细致也不太认真思考,感觉书中讲的东西都应该是对的,最近读书时我发现以前认为理所当然的东西事实上压根都没有弄明白,最终的结果是,书是别人的,书中的知识也是别人的。

无论是看过的nginx有关书还是网上看到的有关nginx 配置说明的文章(http://wiki.nginx.org/EventsModule#worker_connections),无一例外,在讲到 worker_connections 和 max_clients这两个概念的关系时都一致的一笔带过,尤其是在讲到nginx作为反向代理时max_clients的计算时,都是想当然的贴出max_clients = worker_processes * worker_connections/4这个理论计算公式来。既然是理论公式,那么为什么要除以4呢?肯定是有原因的吧。我相信有些人是知道如何计算的,但是很多人都如我一样一眼扫过,真正等到别人或者自己问自己的时候就真的感觉是云里雾里,不知所以然了。

我认为,要搞清楚这个公式是否正确,以及如何计算的,那首先要对nginx的各个配置说明有清晰的认识:

nginx作为http服务器的时候:

max_clients = worker_processes * worker_connections

nginx作为反向代理服务器的时候:

max_clients = worker_processes * worker_connections/4

我们暂且不来判定这两个公式是否正确,我曾经认为nginx作为反向代理,要同时维持客户端和后端被代理server两个链接应该是除以2而不是除以4,后来想到连接请求都是双向的,也就认为除以4应该是正确的。当然,我想的极有可能是不正确的,我的判断是否正确最终还是需要我们根据每一个参数的实际含义来判断(当然,可以很明确的告诉你,我的想法是错误的。至于原因呢,后面告诉你。)。还是让我们一起来看下max_clients,worker_processes和worker_connections的官方说明,对其所包含的含义搞清楚明白,再来确定之间的关系。

worker_processes:

官方英文版wiki配置说明中的描述如下,个人理解为worker角色的进程个数(nginx启动后有多少个worker处理http请求。master不处理请求,而是根据相应配置文件信息管理worker进程.   master进程主要负责对外揽活(即接收客户端的请求),并将活儿合理的分配给多个worker,每个worker进程主要负责干活(处理请求))。

syntax:worker_processes number | auto;default:
worker_processes 1;
context:main
Defines the number of worker processes.

/usr/local/nginx/sbin/nginx -c /usr/local/nginx/conf/nginx.conf

root     3153     1  0 12:11 ?        00:00:00 nginx: master process

nobody   3154 3153 0 12:11  ?        00:00:00 nginx: worker process               nobody   3155 3153  0 12:11 ?        00:00:00 nginx: worker process

nobody   3156 3153  0 12:11 ?        00:00:00 nginx: worker process

nobody   3157 3153  0 12:11  ?        00:00:00 nginx: worker process

The optimal value depends on many factors including (but not limited to) the number of CPU cores, the number of hard disk drives that store data, and load pattern. When one is in doubt, setting it to the number of available CPU cores would be a good start (the value “auto” will try to autodetect it).

The auto parameter is supported starting from versions 1.3.8 and 1.2.5.

最理想的worker_processes值取决于很多因素,包含但不限于CPU的核数,存储数据的硬盘驱动器个数(跟这个有什么关系?难道和cpu一样,存在跨区域读取数据问题),以及负载模式(?这个是什么?)当其中任何一个因素不确定的时候,将其设置为cpu核数或许是一个比较好的初始值,“自动”也基本是如此确认一个参数值的。

“自动”这个参数值是从nginx 1.3.8和nginx 1.2.5 开始进行支持的,自动参数可以自动检测 cpu cores 并设置 worker_processes 参数 。

在网上也看到以下建议:

nginx doesn‘t benefit from more than one worker per CPU.

一个cpu配置多于一个worker数,对nginx而言没有任何益处。

If Nginx is doing CPU-intensive work such as SSL or gzipping and you have 2 or more CPUs/cores, then you may set worker_processes to be equal to the number of CPUs or cores.

如果nginx处理的是cpu密集型(比较耗费cpu的)的操作,建议将此值设置为cpu个数或cpu的核数。

worker_connections:

官方解释如下,个人认为是每一个worker进程能并发处理(发起)的最大连接数(包含所有连接数)。

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 (可以在worker_rlimit_nofile中改变的参数).

worker_rlimit_nofile   xxxxx;

context:events

####Specifies(指定) the value for maximum file  descriptors(可被一个工作进程打开的最大文件描述符数量) that can be opened by this process.

注意:设置了这个后,修改worker_connections值时,是不能超过worker_rlimit_nofile的这个值。

max_clients:

这个参数没有出现在nginx的配置文件中,我也没在官方的文档中找到这个参数,但是很多的文章和书籍都提到了这个参数。有很多人将这个翻译为最大访问客户数,个人认为没有什么不妥的,因此我们就当这个是nginx在理论情况下能处理的最大访问客户数,当然这个客户数不是具体的用户。

当nginx作为http 静态内容的web服务器时,只需要处理来自客户端的连接请求即可(请求是双向的,连接是没有方向的,所以我上面说的反向代理是连接双向,除以4的说法是不正确的)。

由HTTP客户端发起一个请求,创建一个到服务器指定端口(默认是80端口)的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请求,服务器会向客户端返回一个状态,比如"HTTP/1.1 200 OK",以及返回的内容,如请求的文件、错误消息、或者其它信息。同一时刻nginx在处理客户端发送的http请求应该只是一个connection,由此可知理论上作为http web服务器角色的nginx能够处理的最大连接数就是最大客户端连接数。

因此理论上的最大客户端连接数计算公式为:

max_clients = worker_processes * worker_connections;

那一直让我犯迷糊的问题,nginx作为反向代理时可以处理的最大客户连接数是如何计算的呢?

如果只是简单的按照http server服务器的计算模式,加上nginx将用户请求转向被代理服务器时建立的连接,最大的客户连接数也应该还是我之前理解的,在nginx作为http服务器的最大客户端连接数的基础上除以2了。当然,事实上极可能和我想象的不一样了。

官方wiki(页面标记已经过时,但是网上很多文章都在引用)看到一个关于为什么除以4的解释:

如果作为反向代理,因为浏览器默认会开启2个连接到server,而且Nginx还会使用fds(file descriptor)从同一个连接池建立连接到upstream后端。则最大连接数的计算公式如下:

max_clients = worker_processes * worker_connections / 4;

Since(因为) a browser opens 2 connections by default to a server and nginx uses the fds (file descriptors) from the same pool to connect to the upstream backend。

我有两个疑问:

  1. 浏览器怎么知道nginx是作为反向代理的?nginx 响应中会有说明?
  2. 如果浏览器知道nginx是作为反向代理的,那为什么需要开启2个连接到server,而且这根使用文件描述符从同一个连接池(这又是什么东东),与后端upstream建立连接有什么关系?

这两个问题解决了,nginx作为反向代理的最大客户连接数的计算也就很明确了。

2014.06.01 0:30分更新:

nginx使用的epoll模型,

作为web server时,在处理http请求时,如果作为web服务器,一个worker进程就可以用来响应一个用户请求。

作为反向代理时,用户发送请求到nginx,nginx发送请求到后端被代理服务器,后端服务器相应给nginx,nginx将内容返回给用户。

由于epoll模型是不等待的,每一步都有可能是由新建连接处理的,但是这也不能说明nginx作为反向代理最大客户连接数是需要除以4的。

2014.06.01 01:10更新:

http://wiki.nginx.org/EventsModule#worker_connections

2011年大家对此问题的讨论:

http://mailman.nginx.org/pipermail/nginx/2011-February/024979.html

Antoine BONAVITA antoine_bonavita at yahoo.com

Thu Feb 3 11:43:22 MSK 2011

Previous message: Calculating the max. clients by worker_connections

Next message: Calculating the max. clients by worker_connections

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I would say "and nginx uses the fds (file descriptors) from the same pool to

connect to the upstream backen" (wiki quote). But that should be 2, not 4: I

agree with you on this.

If any of the gurus out there could shed light on this, I‘m sure a lot of us

would appreciate.

Antoine.

Ryan Chan ryanchan404 at gmail.com

Thu Feb 3 19:38:49 MSK 2011

Previous message: Calculating the max. clients by worker_connections

Next message: Calculating the max. clients by worker_connections

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

In fact,

As normal web server, the maths would also be

max_clients = worker_processes * worker_connections / 2

since every browser opens 2 connections by default,

since browser uses 2 connections in HTTP 1.1.

好吧,如上讨论内容,总有一个计算方式是有问题的,或者说大家对max_clients的理解不太一样。

如果说max_clients指的是最大客户端连接数,那nginx作为一般web server的计算公式是正确的。如果max_clients指的是建立连接最大客户数,由于每一个浏览器看了两个并发连接,那么nginx作为反向代理的计算公式就是正确的。

个人认为,max_clients 指nginx可以处理的客户端数(默认一个客户端发送一个请求,如果客户端并发两个请求,那就只能再除以2了)。

最终的结论:

http 1.1协议下,由于浏览器默认使用两个并发连接,因此计算方法:

nginx作为http服务器的时候:

max_clients = worker_processes * worker_connections/2

nginx作为反向代理服务器的时候:

max_clients = worker_processes * worker_connections/4

clients与用户数:

同一时间的clients(客户端数)和用户数还是有区别的,当一个用户请求发送一个连接时这两个是相等的,但是当一个用户默认发送多个连接请求的时候,clients数就是用户数*默认发送的连接并发数了。

Calculating the max client in Nginx

Answer:

If you use Nginx as a web server, the max. number of client can be served at the same time by Nginx should be calculated by the following formula:

max_clients = worker_processes * worker_connections

But this does not equal to the number of users can be served at the same time by Nginx, since a lot of browsers open 2 connections to the web server at the same time.

有关高流量负载情况下,nginx并发问题优化的一个文章:

http://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-traffic-loads/

感谢:

互联网运维圈子群中的“Elean follow me”小伙伴.

互联网上各种抄袭和被抄袭的文章,虽然你们一再地误导我,各种坑我,但是我还是最终跳过各种坑,一步一步把问题搞明白了。

时间: 2024-10-13 05:25:35

nginx 并发数问题思考:worker_connections,worker_processes与的相关文章

nginx 并发数问题思考:worker_connections,worker_processes与 max clients

我相信,很多人都跟我一样,看书都不会太细致也不太认真思考,感觉书中讲的东西都应该是对的,最近读书时我发现以前认为理所当然的东西事实上压根都没有弄明白,最终的结果是,书是别人的,书中的知识也是别人的. 无论是看过的nginx有关书还是网上看到的有关nginx 配置说明的文章(http://wiki.nginx.org/EventsModule#worker_connections),无一例外,在讲 到 worker_connections 和 max_clients这两个概念的关系时都一致的一笔带

nginx 并发数

#通过web界面查看时Nginx需要开启status模块,也就是安装Nginx时加上        --with-http_stub_status_module   然后配置Nginx.conf,在server点里面加入如下内容 location /status {stub_status on;access_log /usr/local/nginx/logs/status.log;auth_basic "NginxStatus"; } 配置完后重新启动Nginx后我们可以通过浏览器访问

Nginx并发访问优化

Nginx反向代理并发能力的强弱,直接影响到系统的稳定性.安装Nginx过程,默认配置并不涉及到过多的并发参数,作为产品运行,不得不考虑这些因素.Nginx作为产品运行,官方建议部署到Linux64位系统,基于该建议,本文中从系统线之上考虑Nginx的并发优化. 1.打开Linux系统epoll支持 epoll支持,能够大大提高系统网络IO的并发数. 2.Linux文件句柄数限制 Nginx代理过程,将业务服务器请求数据缓存到本地文件,再将文件数据转发给请求客户端.高并发的客户端请求,必然要求服

Nginx并发訪问优化

Nginx反向代理并发能力的强弱,直接影响到系统的稳定性.安装Nginx过程,默认配置并不涉及到过多的并发參数,作为产品执行,不得不考虑这些因素.Nginx作为产品执行,官方建议部署到Linux64位系统,基于该建议,本文中从系统线之上考虑Nginx的并发优化. 1.打开Linux系统epoll支持 epoll支持,可以大大提高系统网络IO的并发数. 2.Linux文件句柄数限制 Nginx代理过程,将业务server请求数据缓存到本地文件,再将文件数据转发给请求client.高并发的clien

nginx限制ip并发数

nginx限制ip并发数,也是说限制同一个ip同时连接服务器的数量 1.添加limit_zone 这个变量只能在http使用 vi /usr/local/nginx/conf/nginx.conf limit_zone one $remote_addr 10m; 2.添加limit_conn 这个变量可以在http, server, location使用 我只限制一个站点,所以添加到server里面 vi /usr/local/nginx/conf/host/gaojinbo.com.conf 

Nginx限制ip链接数,Nginx如何限制并发数,同1个IP,nginx怎么限制流量/限制带宽?

nginx 限制ip并发数,也是说限制同一个ip同时连接服务器的数量.如何Nginx限制同一个ip的连接数,限制并发数目,限制流量/限制带宽? 通过下面nginx模块的使用,我们可以设置一旦并发链接数超过我们的设置,将返回503错误给对方.这样可以非常有效的防止CC攻击.在配合 iptables防火墙,基本上CC攻击就可以无视了.Nginx限制ip链接数,Nginx如何限制并发数,同1个IP,nginx怎么限制流量/限制带宽?请看下文: nginx 限制ip并发数,nginx限制IP链接数的范例

Nginx限制访问次数和并发数

Nginx限制访问速率和最大并发连接数模块--limit (防止DDOS攻击) http: ##zone=one或allips 表示设置名为"one"或"allips"的存储区,大小为10兆字节 ##rate=2r/s 允许1秒钟不超过2个请求 limit_conn_log_level error; limit_conn_status 503; limit_conn_zone $binary_remote_addr zone=one:10m; limit_conn_

nginx 并发设置

一.一般来说nginx 配置文件中对优化比较有作用的为以下几项: 1.  worker_processes 8; nginx 进程数,建议按照cpu 数目来指定,一般为它的倍数 (如,2个四核的cpu计为8). 2.  worker_cpu_affinity 00000001 0000001000000100 00001000 00010000 00100000 01000000 10000000; 为每个进程分配cpu,上例中将8 个进程分配到8 个cpu,当然可以写多个,或者将一个进程分配到

nginx [alert] 12339#0: 1024 worker_connections are not enough

问题主要几种在nginx连接数超过限制,导致的报错. 进一步分析报错原因,具体步骤如下: l  查看系统最大的允许文件打开数 [[email protected] logs]# cat /proc/sys/fs/file-max 343927 2  通过ulimit -n命令可以查看目前该linux系统里打开文件描述符的最大值 [[email protected] logs]# ulimit -n 20480 检查到这里,目前系统最大的打开文件数,我们配置了20480,可以说,这其实是一个比较"