Nginx基礎配置

nginx的配置中，至少需要載入幾個核心模組和乙個事件模組。這些模組執行所支援的配置項被稱為基本配置---其他模組執行時的依賴配置項。

本文主要記錄基本配置項的用法，這裡主要分四類來進行記錄：

1.用於除錯、定位問題的

2.正常執行的

3.優化效能的

4.事件類

在nginx中有一些配置項，不需要顯式配置，它們具有乙個預設的值，比如daemon、pid。

1.用於除錯、定位問題的

1）是否以守護程序方式執行nginx

語法：daemon on|off;

預設：deamon on;

注：守護程序是脫離終端並在後台執行的程序，它不會輸出資訊在任何終端上。

2）是否以master/worker方式工作

語法：master_process on|off;

預設：master_process on;

注：前文nginx程序間的關係有詳細介紹。

3）error日誌設定

語法：error_log pathfile level;

預設：error_log logs/error.log error;

注：error日誌是定位nginx問題的最佳日誌，我們可以根據自己的需要修改日誌的路徑與等級。pathfile是乙個具體檔案，如果需要關閉nginx的日誌輸出的話，可以將pathfile改成/dev/null，熟悉linux應該都知道，這就是乙個黑洞。level是日誌的輸出級別，可選項有debug、info、notice、warn、error、crit、alert、emerg，從左到右級別依次增大，nginx不會列印級別低於配置項的日誌。

4）是否處理幾個特殊的調試點

語法：debug_points stop|abort;

注：該配置項是用於跟蹤除錯nginx的，nginx在一些關鍵的錯誤邏輯中加入了調試點。如果配置debug_point為stop的話，nginx執行到調試點時將會發出sigstop訊號用於除錯。如果debug_point為abort的話，將會產生乙個coredump檔案，可以使用gdb來檢視當時的資訊。一般情況下都不會使用到這個配置項。

5）僅對指定客戶端輸出debug日誌

語法：debug_connection ip|cidr

events

注：該配置其實是乙個事件類的配置，它必須在events塊配置中才有效，值可以是ip位址或者cidr位址。這樣的話，只有來自於配置項的請求才會列印debug日誌，其他請求還是按照error_log的配置輸出。

6）限制coredump核心**檔案大小

語法：worker_rlimit_core size;

在linux系統中，當程序異常中斷時，系統將會把程序執行時的記憶體內容寫入到乙個core檔案，用於除錯，這就是所謂的核心**（core dumps）。當nginx程序出現異常被強制結束時，就會生成想要的core檔案，可以從core檔案中獲取當時的堆疊和暫存器等資訊，來保證我們定位問題。但是這個core中有大量的資訊不一定是我們想要的，而且不加限制的話，可能乙個core檔案就會達到數g的大小，會造成空間占用。通過這個配置可以限制nginx服務的core檔案大小。

7）指定coredump檔案生成目錄

語法：working_directory path;

work程序的工作目錄，這個配置的唯一用處就是設定coredump檔案的目錄。

2.正常執行的

1）定義環境變數

語法：env var|var=value;

該配置可以讓使用者直接設定作業系統的環境變數。如：

env testpath=/tmp/;

2)匯入其它配置檔案

語法：include pathfile;

include可以將其它配置檔案匯入到當前的nginx.conf檔案中，它的引數可以是相當路徑或者絕對路徑，也可以是含萬用字元的檔名。

include mime.type;

include vhost/*.conf

3)pid檔案的路徑

語法：pid path/file;

預設：pid logs/nginx.pid;

保持master程序id的pid檔案所在的路徑，預設是configure執行時指定的--pid-path路徑，可以隨時修改，但是需要確保nginx服務有權在指定的路徑下建立檔案。

4）nginx worker程序執行的使用者與使用者組

語法：user username[groupname];

預設： user nobody nobody;

user設定worker程序執行在哪個使用者和使用者組下，當只有乙個配置值時，使用者組名與使用者名稱一致。如果使用者在configure執行時使用--user=username和--group=groupname時，nginx將會使用引數中指定的使用者與使用者名稱。

5）最大控制代碼描述符數

語法：worker_rlimit_nofile limit;

設定乙個worker程序可以開啟的最大檔案控制代碼數。

6）限制訊號佇列

語法：worker_rlimit_sigpending limit;

設定每乙個使用者發給nginx的訊號佇列大小，當使用者傳送的訊號量沾滿了訊號佇列，後續的訊號nginx將會直接丟掉。

3.效能優化

1）worker程序個數

語法：worker_processes number;

預設：worker_processes 1;

設定在worker執行方式下，worker程序的個數，這裡在前文中有詳細介紹。

2）worker程序繫結cpu

語法：worker_cpu_affinity cpumask[cpumask...]

例：worker_processes 4;

worker_cpu_affinity 1000 0100 0010 0001;

將worker程序繫結到指定的cpu上，可以實現核心排程策略上的併發。

3）ssl硬體加速

語法：ssl_engine device;

如果伺服器上有ssl硬體加速裝置的話，我們可以使用ssl_engine配置來加快ssl協議的處理速度，下面附上檢視是否存在ssl硬體加速裝置的方法。

openssl engine -t

4) gettimeofday執行頻率

語法：timer_resolution t;

預設情況下，每一次核心時間呼叫返回時，都會執行一次gettimeofday，它是使用核心的時間來更新nginx的快取中的時間。在以前的linux核心中，需要進行核心態到使用者態的記憶體複製，大於系統的消耗不小，但是現在的核心中只需要訪問共享記憶體頁，代價不大，可以不進行配置。

5）worker程序優先順序

語法：worker_priority nice;

預設：worker_priority 0;

該配置使用者設定worker程序的nice優先順序，在linux系統中，當很多程序都處於可執行的姿態時，系統將會按照程序的優先順序來決定本次核心選擇先執行哪乙個程序。同時，如果程序的優先順序更高的話，可以分配到的時間片越大。nice值是程序的靜態優先順序，可取值-20-+19，數值越低優先順序越高。如果想要ngin占用更加多的系統資源的話，可以調小nice值，但是不建議小於-5，因為-5是系統核心程序的nice值。

4.事件類

1）是否開啟accept鎖

語法：accept_mutex [on|off]

預設：accept_mutex on;

accept_mutex是nginx的負載均衡鎖，該鎖可以使多個worker程序輪流的、序列化的與客戶端建立tcp連線。如果某乙個worker程序的連線數達到了worker_connections配置值的7/8時，它會減少與客戶端的tcp連線，盡量使得worker程序的請求數相近。

accept預設開啟，關閉的話，會減少tcp連線的時間，但是會造成worker程序之間的負載很不均衡。

2）lock檔案路徑

語法：locak_file path/file;

預設：lock_file logs/nginx.lock;

當accept鎖關閉時，lock_file配置完成不生效。只有在開啟了accept鎖，並且由於一些原因（編譯程式或者作業系統等因素）導致nginx不支援原子鎖的時候，才會使用檔案鎖來實現accept鎖。

3）連線建立延遲時間

語法：accept_mutex_delay nms;

預設：accept_mutex_delay 500ms;

該配置只有在accept鎖開啟的時候才有效，在開啟accept鎖的時候，同一時間只有乙個worker程序可以拿到鎖，該鎖不是堵塞鎖，拿不到會直接返回。如果乙個worker程序沒有拿到鎖的話，至少需要等配置的延遲時間之後才能再次獲取該鎖。

4）批量建立連線

語法：multi_accept [on|off];

預設：multi_accept off;

當事件模型通知有新的連線的時候，盡可能的對本次排程中客戶端的所有tcp都建立連線。

5）選擇事件模型

nginx會自動去使用最合適的事件模型，linux系統中可以選擇poll、select與epoll，其中epoll效能最好。

6）程序最大連線數

語法：worker_connections number;

該配置決定每乙個worker程序可以同時處理的最大連線數。

Nginx基礎配置

Nginx 基礎配置

Nginx 基礎配置

Nginx基礎 Nginx配置檔案

Nginx基礎配置

Nginx 基礎配置

Nginx 基礎配置

Nginx基礎 Nginx配置檔案

相關推薦