nginx配置優化

worker_processes指令控制工作程序數：

worker_processes 1;

其預設值為1，這意味著nginx只執行乙個worker。該值應根據可用核心數，磁碟，網路子系統，伺服器負載等更改為最佳值。

我們可以將值設定為可用的核心數。使用lscpu確定可用的核心數：

$ lscpu

architecture: x86_64

cpu op-mode(s): 32-bit, 64-bit

byte order: little endian

cpu(s): 4

同樣可以通過grep cpuinfo得到：

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

現在我們設定worker數為4:

# one worker per cpu-core.

worker_processes 4;

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

由於我們在nginx中配置了多個workers，因此我們還應配置影響worker的相關指令。 events區域下accept_mutex引數將使每個可用的worker程序逐個接受新連線。預設情況下，該標誌設定為on。如：

events

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

當啟用accept_mutex時，只有乙個具有互斥鎖的worker程式接受連線，而其他工作程式則輪流等待。 accept_mutex_delay對應於worker等待的時間幀，然後它嘗試獲取互斥鎖並開始接受新的連線。預設值為500毫秒

events

下乙個要檢視的配置是worker_connections，預設值為512.該指令設定worker程序最大開啟的連線數:

events

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

同時連線的數量受限於系統上可用的檔案描述符的數量，因為每個套接字將開啟乙個檔案描述符。如果nginx嘗試開啟比可用檔案描述符更多的套接字，會發現error.log中出現too many opened files的資訊。

使用ulimit檢查檔案描述符的數量：

$ ulimit -n

現在，將此值增加到大於worker_processes * worker_connections的值。應該是增加當前worker執行使用者的最大檔案開啟數值。

nginx提供了worker_rlimit_nofile指令，這是除了ulimit的一種設定可用的描述符的方式。該指令與使用ulimit對使用者的設定是同樣的效果。此指令的值將覆蓋ulimit的值，如：

worker_rlimit_nofile 20960;

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

events