Nginx以高性能負載均衡、緩存和web服務器出名，支撐著世界上繁忙網(wǎng)站中的40%。大多數(shù)使用場景下，Nginx和Linux系統(tǒng)的默認配置表現(xiàn)較好，但是仍有必要做一些調優(yōu)以期達到***性能。

這篇文章討論當調優(yōu)系統(tǒng)時需要考慮的一些Nginx和Linux配置。這些配置有很多，但是在本文里我們只涉及適合大多數(shù)用戶的配置。那些沒有涉及到的配置，只有那些對Nginx和Linux有深入理解的人，或者Nginx專家服務團隊推薦，才會考慮到。

Nginx專家服務，已經(jīng)和世界上一些繁忙網(wǎng)站合作來調優(yōu)Nginx以達到***限度的性能，并且可以對任何需要充分發(fā)揮系統(tǒng)能力的客戶提供支持。

[[265760]]

簡介

這里假定讀者對Nginx架構和配置概念有個基本了解。本文不會重復Nginx文檔的內容，而是概述各種配置選項并提供相關文檔鏈接。

調優(yōu)時，有一條較好的準則是，一次只改一個配置項，如果改后沒有性能上的提升，就退回為原先的值。

我們先討論Linux調優(yōu)，因為有些值會影響在Nginx配置中可以用的值。

Linux配置

現(xiàn)代Linux內核(2.6+)能夠很好的調節(jié)各種配置，有些配置您可能想更改。如果操作系統(tǒng)配置太低，那么會在內核日志中看到錯誤信息，因此需要調節(jié)這些配置。Linux配置項很多，本文只提及那些在普通工作負載下最可能需要調優(yōu)的配置項。如果需要這些配置的詳細信息，請參考Linux文檔。

Backlog隊列

以下設置與連接及其如何排隊直接相關。如果傳入的連接率很高而性能水平參差不齊，比如一些連接似乎被暫停了，那么更改這些配置可能會有用。

• net.core.somaxconn 該項設置等待被Nginx接受的連接的排隊大小。由于Nginx接受連接速度非常快，這個值通常不需要非常大，但是默認值是非常低的，所以如果你有一個高流量網(wǎng)站，增加這個值是個好主意。如果設置過低，那么你能在內核日志中看到錯誤信息，這時你應該增加這個值直到?jīng)]有錯誤信息。注意：如果你將其設置為大于512的值，你應該同時用listen指令的backlog參數(shù)匹配這個值來更改Nginx的配置。
• net.core.netdev_max_backlog 該項設置在交由CPU處理之前網(wǎng)卡緩沖數(shù)據(jù)包的速率。對于擁有高帶寬的機器，這個值可能需要增加。查看網(wǎng)卡文檔尋求相關建議，或者檢查內核日志相關錯誤信息。

文件描述符

文件描述符是一種操作系統(tǒng)資源，用來處理諸如連接和打開文件的事情。對每一個連接，Nginx可以用上多達兩個文件描述符。例如，如果Nginx用作代理，則其中一個用于客戶端連接，另一個用于連接到被代理的服務器。如果使用了HTTP keepalive，則連接描述符的使用會少得多。對于有大量連接的系統(tǒng)，如下設置可能需要進行調整：

• sys.fs.file_max 這是系統(tǒng)范圍內的文件描述符限制。
• nofile 這是用戶級別的文件描述符限制，在/etc/security/limits.conf文件中配置

臨時端口

當Nginx被當作代理使用時，每一個到upstream服務器的連接都使用一個臨時端口。

• net.ipv4.ip_local_port_range 這個用來指定可以使用的起止端口號。如果你看到端口耗盡，你可以增加這個范圍。常見的設置為1024到65000。
• net.ipv4.tcp_fin_timeout 這個用于指定一個不再被使用的端口多久之后可以被另一連接再次使用。通常，這個值默認為60秒，但是可以安全地減少到30甚至15秒。

Nginx配置

下面是一些可能影響性能的Nginx指令。如前所述，我們僅討論那些推薦大多數(shù)用戶調整的指令。這里未提及到的任何指令，如果沒有Nginx團隊的指導，不推薦更改。

工作進程

Nginx可以運行多個工作進程，每個都能處理大量連接。你可以用如下指令控制工作進程個數(shù)以及連接如何被處理：

• worker_processes 這個控制Nginx運行的工作進程個數(shù)。大多數(shù)情況下，一個CPU核心跑一個工作進程能夠工作得很好。可以將該指令設為auto來達到與CPU核心數(shù)匹配的工作進程數(shù)。有時候，可以增加這個值，比如工作進程需要處理大量磁盤IO操作的時候。這個值默認為1。
• worker_connections 這個表示每個工作進程同時能夠處理的***連接數(shù)。默認值是512，但是大多數(shù)系統(tǒng)能處理更大的值。這個值該設為多少取決于服務器硬件配置以及流量的特性，可以通過測試來發(fā)現(xiàn)。

Keepalives

持久連接可以減少打開和關閉連接所需要的CPU和網(wǎng)絡開銷，因而對性能有重大影響。Nginx終止所有客戶端連接，并具有到upstream服務器的單獨連接。Nginx支持客戶端和upstream服務器的持久連接。如下指令涉及客戶端持久連接：

• keepalive_requests 這表示客戶端能在單個持久連接上發(fā)送多少請求。默認值是100，可以設置成更高的值，這在負載生成器從單個客戶端發(fā)送大量請求的測試場景中非常有用。
• keepalive_timeout 表示一個空閑持久連接保持打開狀態(tài)多長時間。

如下指令涉及upstream持久連接：

• keepalive 這個指定每個工作進程連接到upstream服務器的空閑持久連接數(shù)量。這個指令沒有默認值。

為了啟用到upstream的持久連接，需要增加如下指令：

proxy_http_version 1.1;  
proxy_set_header Connection ""; 

Access日志

記錄每個請求需要花費CPU和IO周期，減少這種影響的一種方法是啟用access日志緩沖。這將導致Nginx緩沖一系列日志條目，然后一次性寫入文件而不是單個單個寫入。

通過指定access_log指令的"buffer=size"選項可以打開access日志緩沖，該設置指定要使用的緩沖區(qū)的大小。你還可以使用"flush=time"選項告訴Nginx多長時間后把緩沖區(qū)中的條目寫入文件。

定義了這兩個選項后，當緩沖區(qū)放不下下一條日志，或者緩沖區(qū)中的條目超過了flush參數(shù)指定的時間，Nginx會將緩沖區(qū)中的條目寫入日志文件。當工作進程重新打開日志文件或者關閉時，緩沖區(qū)中的條目也會被寫入文件。也可以完全禁用access日志記錄。

Sendfile

Sendfile是一個操作系統(tǒng)特性，可以在Nginx上啟用。它通過在內核中從一個文件描述符向另一個文件描述符復制數(shù)據(jù)，往往能達到零拷貝，因而可以提供更快的TCP數(shù)據(jù)傳輸。Nginx可以使用該機制將緩存或者磁盤上的內容寫到socket，無需從內核空間到用戶空間的上下文切換，因而非常快并且使用較少的CPU開銷。由于數(shù)據(jù)永遠不會觸及用戶空間，所以不可能把需要訪問數(shù)據(jù)的過濾器插入到處理鏈中，不能使用任何需要改變內容的Nginx過濾器，比如gzip過濾器。Nginx默認沒有啟用該機制。

限制

Nginx和Nginx Plus允許設置各種限制，用來控制客戶端資源消耗，以防影響系統(tǒng)性能以及用戶體驗和安全。以下是一些相關指令：

• limit_conn / limit_conn_zone 這些指令可以用來限制Nginx允許的連接數(shù)，比如來自單個客戶端IP地址的連接數(shù)。這可以防止單個客戶端打開太多連接而消耗太多資源。
• limit_rate 這個用來限制客戶端在單個連接上允許使用的帶寬。這可以防止某些客戶端導致系統(tǒng)超載，因而有利于為所有客戶端提供QoS保證。
• limit_req / limit_req_zone 這些指令可以用來限制Nginx的請求處理速率。與limit_rate一起，可以防止某些客戶端導致系統(tǒng)超載，因而有利于為所有客戶端提供QoS保證。這些指令也可以用來增強安全性，尤其是對登錄頁面，通過限制請求速率，使得其對人類用戶是合適的，而會減慢試圖訪問你的應用的程序。
• max_conns 這個用來限制同時連接到upstream組中單個服務器的***連接數(shù)。這可以防止upstream服務器超載。默認值是0，表示沒有限制。
• queue 如果設置了max_conns，那么queue指令用來決定當一個請求由于upstream組中沒有可用服務器或者這些服務器達到max_conns限制而不能得到處理時會發(fā)生什么。這個指令用來設定有多少請求將會排隊以及排多久。如果沒有設置這個指令，就不會有排隊行為。

其它考慮

Nginx還有一些特性可以用來提高web應用的性能。這些特性不常出現(xiàn)在調優(yōu)討論中，但是有必要一提，因為它們的影響也可能比較可觀。我們將討論這些特性中的兩個。

緩存

對于一個為一組web服務器或者應用服務器作負載均衡的Nginx實例來說，啟用緩存可以顯著地降低響應時間，同時能顯著減輕后端服務器的負載。緩存本身就是一個主題，這里不會討論。

壓縮

壓縮響應可以大大減小響應的大小，減少帶寬占用。不過，這需要CPU資源來處理壓縮，所以***在值得減少帶寬占用的情況下使用。需要注意的是，不能對已經(jīng)壓縮的東西(比如jpeg圖片)再次啟用壓縮。Nginx壓縮配置的更多信息請參考：Nginx管理指南 - 壓縮和解壓縮