## 核心參數 * user * pid * worker_rlimit_nofile * worker_rlimit_core * worker_processess * worker_cpu_affinity * worker_priority * worker_shutdown_timeout * timer_resolution * daemon * lock_file ## user ``` user USERNAME [GROUP] ``` 指定運行的nginx的worker子進程的屬主和屬組,其中屬組可以不指定; 示例 : ``` user nginx nginx; ``` ## pid ``` pid DIR ``` 指定運行nginx的master的主進程的pid文件存放路徑 示例: ``` pid /opt/nginx/logs/nginx.pid; ``` ## worker_rlimit_nofile ``` worker_rlimit_nofile number ``` 指定每個worker子進程可以打開的最大文件句柄數,Linux最大的限制是65535; 示例: ``` worker_rlimit_nofile 20480; ``` ## worker_rlimit_core ``` worker_rlimit_core size ``` 指定worker子進程異常終止后的core文件,用于記錄分析問題;配置的目錄必須要有寫的權限; 示例: ``` worker_rlimit_core 50M; worker_directory /opt/nginx/tmp; ``` ## worker_processess ``` worker_processess number | auto ``` 指定nginx啟動的worker子進程數量;auto會自動啟動和物理核心個數一致的數量; 示例: ``` worker_processess 4; worker_processess auto; ``` ## worker_cpu_affinity ``` worker_cpu_affinity cpumask1 cpumask2... ``` 將每個worker子進程與我們的CPU物理核心綁定;這里的綁定不是指worker子進程完全占用了一個核心的計算資源;而是說只獲取獲得此核心的時間片;不會使用其他的核心的時間片;  示例: ``` worker_cpu_affinity 0001 0010 0100 1000 #4個物理核心,4個worker進程 worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 010000010 10000000 #8個物理核心,8個worker進程 worker_cpu_affinity 01 10 01 10 #2個物理核心,4個子進程 ``` 備注:將每個worker子進程與特定的CPU物理核心綁定,優勢在于:避免同一個worker子進程在不同的CPU核心上切換,緩存失效,降低性能;其并不能真正的避免進程切換; ## worker_priority ``` worker_priority number ``` 指定worker子進程的nice值,以調整運行nginx的優先級,通常設定為負數,以優先調用nginx; 示例: ``` worker_priority -10; ``` 備注:Linux默認進程的優先值是120,值越小越優先,nice設定范圍為-20到+19; ## worker_shutdown_timeout ``` worker_shutdown_timeout time ``` 指定worker子進程優雅退出時的超時時間;熱部署的時候會給子進程發送一個優雅退出的指令;worker不會直接關閉進程,而是將客戶端的請求處理完畢才會退出;有很多客戶端異常了,和nginx建立TCP連接后,就是不發送請求,或是不返回回應.那么worker不能一直等待,當超過優雅退出的超時時后,worker自動退出; 示例: ``` worker_shutdown_timeout 5s ``` ## timer_resolution ``` timer_resolution interval ```  worker子進程內部使用的計時器精度,調整時間間隔越大,系統調用越少,有利于性能提升;反之,系統調用越多,性能下降; **計時器解析度：降低此值，可減少gettimeofday()系統調用的次數；** ??? 這種無謂的系統調用次數或者是我們用不到那么高的時候，降低這個值減少這個次數會在一定意義上提升Nginx性能的或者提升我們整個系統性能的。對于一個非常繁忙的服務器這點是不容忽略的。 ??? 可用來減少降低worker線程中的計時器的解析度，降低解析度以后帶來的結果是，說白了就是減少發起gettimeofday()這么一個系統調用，任何一個進程運行過程當中，如果系統調用很多，任何一次系統調用的發生必然會產生軟中斷，產生軟中斷的直接結果就是模式轉換，每一次的模式轉換必然會消耗時間。因為我們說過很多次，一個生產力非常強的進程應該把大量時間用在用戶空間，那因此timer\_resolution這個時間解析度為什么要用到這個東西呢？ ??? 我們簡單舉個例子：比如任何一個請求到達Nginx的時候Nginx就得響應它，響應完以后就得記錄日志了，但是到日志中會記錄時間。那因此一旦有用戶請求到達，我們這邊處理響應而要記錄日志的話那么它必須要獲取系統當前時間并記錄在日志文件中。怎么獲取系統時間呢？通過gettimeofdate來獲取時間而后把這個結果再保存到日志文件中。而如果我們的時間解析度過大的話，就可能帶來的結果是他一秒鐘就解析一千次，一秒鐘就發起一千次系統調用，如果我把這個降低一點，比如100ms解析一次，那就意味著一秒鐘只解析10次了。如果指定1s一次那就意味著1s鐘只解析1次，但是我們知道時間解析度越低它的精準度就越小，時間解析度越高精度就越高，正如我們的顯示器一樣，分辨率越高，顯示的就越逼真越清晰但是它所需要消耗的資源一定也是越大的。 ??? 那因此為了提高性能，這個時間解析度應該是降低的。只要我們對于它的時間解析度要求不是特別高的話。 示例: ``` timer_resolution 100ms; ``` ## daemon ``` daemon on | off ``` 設定nginx的運行方式,前臺還是后臺,前臺用戶調試,后臺用于生產; 示例: ``` daemon off ``` ## lock_file 需要將accept_mutex設為on有意義; ``` lock_file file ``` 負載均衡互斥鎖文件存放路徑; 默認配置: ``` lock_file /logs/nginx.lock; ``` 推薦配置: ``` lock_file /logs/nginx.lock; ```