1 概述
Nginx的配置段不一樣，同一指令的用法不一樣。關於nginx更詳細的配置，可以查看官方幫助文檔http://nginx.org/en/docs/，本文將介紹全局配置段常見的配置指令
2 全局配置段
Main 全局配置段常見的配置指令分類：
.正常運行必備的配置
.優化性能相關的配置
.用於調試及定位問題相關的配置
.事件驅動相關的配置
全局性的配置一般比較少改動，默認選項可以滿足一般的需求，可以根據實際情況進行調整
2.1 正常運行必備的配置
.1、user
Syntax:user user [group];
例子：
user nginx;
Default:user nobody nobody;
Context:main
指定worker進程的運行身份，如組不指定，默認和用戶名同名
.2、pid /PATH/TO/PID_FILE
指定存儲nginx主進程PID的文件路徑
pid /run/nginx.pid;
.3、includefile | mask
指明包含進來的其它配置文件片斷
例子：
include /usr/share/nginx/modules/*.conf;
.4、load_module file
模塊加載配置文件：/usr/share/nginx/modules/*.conf
指明要裝載的動態模塊路徑: /usr/lib64/nginx/modules
2.2 性能優化相關的配置
.1、worker_processes number | auto
auto和number的區別
auto 是nginx根據系統當前的情況開啓進程數，模式是1個主進程，4個worker進程
number是人爲指定開啓進程數量，比如設置8，那麼總共是1個主進程，7個worker進程
這裏number不建議加太多，worker進程的個數通常應該爲當前主機的cpu的物理核心數，可以略少，因爲nginx是一個進程響應多個請求，不是線程處理。
.2、worker_cpu_affinity cpumask ...
worker_cpu_affinity auto [cpumask] 提高緩存命中率，機器運行時，內核的數量只能增加不能減少，如果要減少內核數，需要停機才能設置
CPU MASK：
00000001：0號CPU
00000010：1號CPU
10000000：8號CPU
例子
假設有4個內核，那麼，內核的編號是0,1,2,3.設置如下，
worker_cpu_affinity 0001 0010 1000 0100;
表示
第一個進程工作在0號內核
第二個進程工作在1號內核
第三個進程工作在3號內核
第四個進程工作在2號內核
如果這裏設置爲0000，則表示對應的進程不指定內核，隨機工作在某個內核上。
正常情況下，主進程是隨機工作在任意進程下的
進程具體工作在哪個內核，可以通過如下的命令進行查看
ps axo pid,cmd,psr,ni |grep nginx
.3、worker_priority number
指定worker進程的nice值，設定worker進程優先級：[-20,20]，值越小，優先級越高
.4、worker_rlimit_nofile number
worker進程所能夠打開的文件數量上限,如65535
同時連接的數量受限於系統上可用的文件描述符的數量，因爲每個套接字將打開一個文件描述符。如果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;
2.3 事件驅動相關的配置
event
語法如下
.events {
...
}
events放在主配置文件裏
.1、worker_connections number
每個worker進程所能夠打開的最大併發連接數數量，如10240
這個參數建議調大點，如果請求太多，導致客戶連接不上而已，不至於浪費了資源
總最大併發數：worker_processes* worker_connections
.2、use method
指明併發連接請求的處理方法,默認自動選擇最優方法，爲epoll.
默認：useepoll;不需要配置
.3、accept_mutex on | off 互斥
處理新的連接請求的方法；on指由各個worker輪流處理新請求，off指每個新請求的到達都會通知(喚醒)所有的worker進程，但只有一個進程可獲得連接，造成“驚羣”，影響性能，默認on
2.4 調試和定位問題
.1、daemon on|off
是否以守護進程方式運行nignx，默認是守護進程方式.如果是off就是前端運行。默認是守護進程on，爲後臺執行
.2、master_process on|off
是否以master/worker模型運行nginx；默認爲on,如果設置爲off 將不啓動worker進程，主要是開發環境使用，關閉後沒有worker進程，只有master提供服務。需要重啓nginx服務後生效
.3、error_log file [level]
錯誤日誌文件及其級別；出於調試需要，可設定爲debug；但debug僅在編譯時使用了“--with-debug”選項時纔有效
方式：file /path/logfile;
stderr:發送到標準錯誤
syslog:server-address[,parameter=values]:發送到syslogmemory:size內存 level:debug|info|notice|warn|error|crit|alter|emerg
例子
error_log /var/log/nginx/error.log;