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錯誤。