Nginx的配置
運行中Nginx進程間的關係
# 爲什麼產品環境下安裝master-worker方式配置同時啓動多個進程？
- master進程不會對用戶提供服務，只用於管理真正提供服務的worker進程，所以master進程可以是唯一的，爲管理員 提供命令行服務，如啓停、重載配置文件、平滑升級程序等。
master擁有的權限相對worker要大，當任意一個worker進程出現錯誤，master進程會立刻啓動新的worker進程繼續服務。
- 多個worker進程處理請求不但可以提供服務的健壯性，還可以充分利用常見的SMP多核架構，實現微觀上真正的多核併發處理。
用一個master處理請求肯定是不合適的，將worker進程數量設置與CPU核數一致，真是Nginx與Apache服務器不同之處。
在Apache上每個進程在一個時刻只處理一個請求，因此，如果希望web服務器擁有併發處理的請求數更多，就要把Apache進程或線程數設置得更多，這樣大量進程切換會無謂的消耗系統資源。
而Ngnix一個worker進程可以同時處理的請求數只受限於內存大小，而且在架構設計上，不同的worker進程之間處理併發請求時幾乎沒有同步鎖的限制。，worker進程通常不會進入睡眠狀態。因此，Nginx上的進程數與CPU核心數相等時，進程間切換的代價是最小的。
Nginx配置通用語法
# 塊配置項：由一個塊配置項名和一對大括號組成。
server {
...
}
# 配置項的語法格式
配置項名 配置項值1 配置項值2 ...;
access_log logs/access.log main buffer=32k;
說明：
1.行首是配置項名，配置項名必須是Nginx的某一個模塊想要處理的，否則視爲非法配置項名。
2.配置項名輸入後，將以空格作爲分隔符。
3.配置項值可以是數字，字符串或正則表達式。
4.一個配置項可以有一個或多個配置項值，一個配置項的配置項值有多少個取決於解析這個配置項的模塊。
5.配置項值之間也是使用空格作爲分隔符。
6.每行配置的結尾需要加上分號。
7.如果配置項值中包括語法符號，比如空格需要使用單引號或雙引號包裹，否則Nginx會報語法錯誤。
配置項註釋
# 使用#註釋某一行配置
#pid logs/nginx.pid;
配置項的單位
# 大部分模塊遵循一些通用規定，如指定空間大小不用每次都精確到字節；指定時間不用精確到毫秒。
- 當指定空間大小時，可使用單位：
- K或k千字節（KB）
- M或m兆字節（MB）
- 當指定時間時，可使用單位：
- ms（毫秒）
- s（秒）
- m（分鐘）
- h（小時）
- d（天）
- w（周，包含7天）
- M（月，包含30天）
- y（年，包含365天）
在配置中使用變量
log_format main '$remote_addr - $remote_user [$time_local] "$request"'
# 如remote_addr是一個變量，使用時需要加上$符合。這種變量只有少數模塊支持，並非通用。
Nginx服務的基本配置
Nginx運行時，至少必須加載幾個核心模塊和一個事件類模塊。
這些模塊運行時所支持的配置項稱爲基本配置——所有其他模塊執行時都依賴的配置項。
基本配置項分爲：
- 調試、定位問題配置項
- 正常運行的必備配置項
- 優化性能的配置項
- 事件類配置項（有些事件類配置項歸到優化性能配置項）
1.用於調試進程和定位問題的配置項
| 序號 | 分類 | 語法 | 默認 | 說明 |
|---|---|---|---|---|
| 序號 | 分類 | 語法 | 默認 | 說明 |
| 1 | 是否以守護進程方式運行Nginx | daemon on/off; | daemon on; | 守護進程（daemon）是脫離終端並在後臺運行的進程。脫離終端是爲了避免執行過程中信息在終端上顯示，同時也避免進程被終端輸入中斷。 |
| 2 | 是否以master/worker方式工作 | master_process on/off; | master_process on; | 提供該方式方便跟蹤調試Nginx。如果不使用該方式，在worker異常時無法fork出worker子進程來處理請求。 |
| 3 | error日誌的設置 | error_log /path/file level; | error_log logs/error.log error; | 錯誤日誌是定位Nginx問題的最佳工具。level是日誌級別，取值：debug,info,notice,warn,error,crit,alert,emerg。從左至右依次增大 |
| 4 | 是否處理幾個特殊的調試點 | debug_points [stop/abort] | / | 用於幫助用戶跟蹤調試Nginx。設置stop時,Nginx執行到這些調試點時就會發出SIGSTOP信息用以調試；設置abort時，會產生一個coredump文件，可使用gdp來查看。通常不使用該配置項。 |
| 5 | 僅對指定客戶端輸出debug級別日誌 | debug_connection [IP/CIDR | / | 該配置實際屬於事件類配置，因此需寫到events塊events{debug_connection 10.224.66.14; debug_connection 10.224.57.0/24;} |
| 6 | 限制coredump核心轉儲文件的大小 | worker_rlimit_core size; | / | 在Linux系統中，當進程發生錯誤或收到信號終止，系統會將進程執行時的內存內容（核心鏡像）寫入一個文件（core文件），用作調試，這就是所謂的核心轉儲（core dumps）。當Nginx進程出現一些非法操作（如內存越界）導致進程直接被操作系統結束時，會生成核心轉儲core文件，可從core文件獲取當時的堆棧、寄存器等信息，幫助定位問題。若不對文件大小進行限制可能達到幾GB，這樣隨便幾次coredumps就會把磁盤佔滿。 |
| 7 | 指定coredump文件生成目錄 | working_directory_ path; | / | worker進程的工作目錄，這個配置唯一用途就是coredump文件所放置的目錄，協助定位問題。需確保worker進程有權限向working_directory指定的目錄中寫入文件。 |
如果日誌設置debug級別或使用debug_connection，在configure時加入--with-debug