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

配置Nginx workers

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

worker_processes

worker_processes指令控制工作進程數：

1. worker_processes 1;

其默認值為1，這意味著NGINX只運行一個worker。 該值應根據可用內核數，磁盤，網絡子系統，服務器負載等更改為最佳值。
我們可以將值設置為可用的核心數。 使用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

同樣可以通過grep cpuinfo得到：

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

現在我們設置worker數為4:

1. # One worker per CPU-core.

2.    worker_processes 4;

或者，可以將其設置為auto。 這樣nginx會自動根據核心數為生成對應數量的worker進程。

accept_mutex

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

1. events {

2.      accept_mutex on;

3. }

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

accept_mutex_delay

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

1. events{

2.      accept_mutex_delay 500ms;

3.  }

worker_connections

下一個要查看的配置是worker_connections，默認值為512.該指令設置worker進程最大打開的連接數:

1. events{

2.       worker_connections 512;

3. }

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

worker_rlimit_nofile

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

1. $ ulimit -n

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

1. worker_rlimit_nofile 20960;

multi_accept

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

1. events{

2.       multi_accept on;

3. }