nginx worker_processes 配置

搜索到原做者的话：
As a general rule you need the only worker with large number of
worker_connections, say 10,000 or 20,000.
However, if nginx does CPU-intensive work as SSL or gzipping and
you have 2 or more CPU, then you may set worker_processes to be equal
to CPU number.
Besides, if you serve many static files and the total size of the files
is bigger than memory, then you may increase worker_processes to
utilize a full disk bandwidth.
Igor Sysoev


通常一个进程足够了，你能够把链接数设得很大。
若是有SSL、gzip这些比较消耗CPU的工做，并且是多核CPU的话，能够设为和CPU的数量同样。
或者要处理不少不少的小文件，并且文件总大小比内存大不少的时候，也能够把进程数增长，
以充分利用IO带宽（主要彷佛是IO操做有block）。


根据我配置实践，
服务器是“多个CPU＋gzip+网站总文件大小大于内存”的环境，worker_processes设置为CPU个数的两倍比较好。


分享二：
最近PPC常常出现502错误，网页常常没法打开，因此本人决定对Nginx进行深刻折腾！
Nginx自己没有挂掉，不然不会出现502的错误信息，因此缘由必定在Nginx的设置上。


通过我查阅资料和测试，发现有多是worker_processes的参数设置不当引发的。


worker_processes默认状况下为1，通常状况下不用修改，但考虑到实际状况，能够修改这个数值，以提升性能;
官方的建议是修改为CPU的内核数，这里引用一段翻译过的文章： 
worker_processes指明了nginx要开启的进程数，
据官方说法，通常开一个就够了，多开几个，能够减小机器io带来的影响。


据实践代表，nginx的这个参数在通常状况下开4个或8个就能够了，再往上开的话优化不太大。
据另外一种说法是，nginx开启太多的进程，会影响主进程调度，因此占用的cpu会增高。
通过我测试发现，
这个数字是不能乱设置的，若是网站没有出现io性能问题，最好不要修改，采用默认的1便可，
若是非要设置，必需要和CPU的内核数匹配，不然要么就假死（主要是Windows），要么就出现502的错误（主要是Linux）。


个人电脑是双核的，按理说应该是2，可是实际上应该是4，由于是双线程的。测试结果以下： 
一、worker_processes为1，线程打开2个，有一个是主线程，运行很稳定。
二、worker_processes为2，线程打开3个，有一个是主线程，1分钟左右挂掉
  （假死，没法打开网页，浏览器一直处于载入中）。
三、worker_processes为4，线程打开5个，有一个是主线程，运行很稳定。
四、worker_processes为8，线程打开9个，有一个是主线程，和2同样，1分钟左右挂掉。


配置参考
配置1：
4 CPU (4 Core) + 4 worker_processes (每一个worker_processes 使用1个CPU)
[reistlin@reistlin.com ~]$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3


worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;


配置2：
​8 CPU (8 Core) + 8 worker_processes (每一个worker_processes 使用1个CPU)
[reistlin@reistlin.com ~]$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7


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


配置3：
​16 CPU (16 Core) + 16 worker_processes (每一个worker_processes 使用1个CPU)
[reistlin@reistlin.com ~]$ cat /proc/cpuinfo | grep processor
processor : 0
processor : 1
processor : 2
processor : 3
processor : 4
processor : 5
processor : 6
processor : 7
processor : 8
processor : 9
processor : 10
processor : 11
processor : 12
processor : 13
processor : 14
processor : 15


worker_processes 16;
worker_cpu_affinity 
0000000000000001 0000000000000010 0000000000000100 0000000000001000 0000000000010000 0000000000100000 0000000001000000 0000000010000000 0000000100000000 0000001000000000 0000010000000000 0000100000000000 0001000000000000 0010000000000000 0100000000000000 1000000000000000;


Nginx worker_cpu_affinity 设置
根据 Nginx Wiki 上的资料显示：
worker_cpu_affinity
Syntax: worker_cpu_affinity cpumask [cpumask...]
Default: none
Linux only.
With this option you can bind the worker process to a CPU, it calls sched_setaffinity().


For example,
worker_processes 4; worker_cpu_affinity 0001 0010 0100 1000;
Bind each worker process to one CPU only.
worker_processes 2; worker_cpu_affinity 0101 1010;
Bind the first worker to CPU0/CPU2, bind the second worker to CPU1/CPU3. This is suitable for HTT.


worker_cpu_affinity 默认是没有开启的，
根据例子咱们能够看得出，0001 0010 0100 1000 分别表明第一、二、三、4个逻辑CPU，
因此咱们能够设置0010 0100 1000来将3个进程分别绑定到第二、三、4个逻辑CPU上：
worker_processes 3;
worker_cpu_affinity 0010 0100 1000;
同时根据例子咱们也能够看出，
worker_cpu_affinity 能够将同1个进程绑定在2个逻辑CPU上：


worker_processes 2;
worker_cpu_affinity 0101 1010;
0101也就是第一、3个逻辑CPU上，1010就是第二、4个逻辑CPU上。 
 
 
分享三：
worker_processes指明了nginx要开启的进程数，
据官方说法，通常开一个就够了，多开几个，能够减小机器io带来的影响。


据实践代表，nginx的这个参数在通常状况下开4个或8个就能够了，再往上开的话优化不太大。
据另外一种说法是，nginx开启太多的进程，会影响主进程调度，因此占用的cpu会增高，
这个说法我我的没有证明，估计他们是开了一两百个进程来对比的吧。


worker_processes配置的一些注意事项：


一、worker_cpu_affinity配置最好是能写上
我这里服务器多数是双核超线程，至关于4cpu，我通常开8进程，因此这个配置就是这样：
worker_cpu_affinity 0001 0100 1000 0010 0001 0100 1000 0010;


另，worker_cpu_affinity不是何时都能用的，
我没有认真研究并罗列全部状况，只知道2.4内核的机器用不了，
若是用不了的话，那么最好是加大worker_processes进程数，这样分配cpu就会平均一点啦，
若是不平均只好多重启几下。


二、worker_rlimit_nofile配置要和系统的单进程打开文件数一致，千万不要再多此一举地除以worker_processes。
我如今在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。


这是由于nginx调度时分配请求到进程并非那么的均衡，因此假如填写10240，
总并发量达到3-4万时就有进程可能超过10240了，这时会返回502错误。