Nginx使用教程(二)：Nginx配置性能優(yōu)化之worker配置

配置Nginx workers

NGINX根據指定的配置運行固定數量的工作進(jìn)程。 這些工作進(jìn)程負責處理所有處理。 在下面的章節中，我們將調整NGINX worker參數。 這些參數是NGINX全局上下文的一部分。

worker_processes

worker_processes指令控制工作進(jìn)程數：

1. worker_processes 1;

其默認值為1，這意味著(zhù)NGINX只運行一個(gè)worker。 該值應根據可用內核數，磁盤(pán)，網(wǎng)絡(luò )子系統，服務(wù)器負載等更改為最佳值。
我們可以將值設置為可用的核心數。 使用lscpu確定可用的核心數：

1. $ lscpu

2. Architecture:  x86_64

3. CPU op-mode(s):  32-bit, 64-bit

4. Byte Order:  Little Endian

5. CPU(s):        4

同樣可以通過(guò)grep cpuinfo得到：

1. $ cat /proc/cpuinfo | grep 'processor' | wc -l

現在我們設置worker數為4:

1. # One worker per CPU-core.

2.    worker_processes 4;

或者，可以將其設置為auto。 這樣nginx會(huì )自動(dòng)根據核心數為生成對應數量的worker進(jìn)程。

accept_mutex

由于我們在NGINX中配置了多個(gè)workers，因此我們還應配置影響worker的相關(guān)指令。 events區域下accept_mutex參數將使每個(gè)可用的worker進(jìn)程逐個(gè)接受新連接。 默認情況下，該標志設置為on。 如：

1. events {

2.      accept_mutex on;

3. }

如果accept_mutex為off，所有可用的worker將從等待狀態(tài)喚醒，但只有一個(gè)worker處理連接。 這導致驚群現象，每秒重復多次。 這種現象導致服務(wù)器性能下降，因為所有被喚醒的worker都在占用CPU時(shí)間。 這導致增加了非生產(chǎn)性CPU周期和未使用的上下文切換。

accept_mutex_delay

當啟用accept_mutex時(shí)，只有一個(gè)具有互斥鎖的worker程序接受連接，而其他工作程序則輪流等待。 accept_mutex_delay對應于worker等待的時(shí)間幀，然后它嘗試獲取互斥鎖并開(kāi)始接受新的連接。 默認值為500毫秒

1. events{

2.      accept_mutex_delay 500ms;

3.  }

worker_connections

下一個(gè)要查看的配置是worker_connections，默認值為512.該指令設置worker進(jìn)程最大打開(kāi)的連接數:

1. events{

2.       worker_connections 512;

3. }

將worker_connections增加到1024或更高的值，以允許同時(shí)處理更多連接。

worker_rlimit_nofile

同時(shí)連接的數量受限于系統上可用的文件描述符的數量，因為每個(gè)套接字將打開(kāi)一個(gè)文件描述符。 如果NGINX嘗試打開(kāi)比可用文件描述符更多的套接字，會(huì )發(fā)現error.log中出現Too many opened files的信息。
使用ulimit檢查文件描述符的數量：

1. $ ulimit -n

現在，將此值增加到大于worker_processes * worker_connections的值。 應該是增加當前worker運行用戶(hù)的最大文件打開(kāi)數值。
NGINX提供了worker_rlimit_nofile指令，這是除了ulimit的一種設置可用的描述符的方式。 該指令與使用ulimit對用戶(hù)的設置是同樣的效果。此指令的值將覆蓋ulimit的值，如：

1. worker_rlimit_nofile 20960;

multi_accept

multi_accept指令使得NGINX worker能夠在獲得新連接的通知時(shí)盡可能多的接受連接。 此指令的作用是立即接受所有連接放到監聽(tīng)隊列中。 如果指令被禁用，worker進(jìn)程將逐個(gè)接受連接。

1. events{

2.       multi_accept on;

3. }