系統重啟後ngix reload不生效原因分析

系統重啟後ngix reload不生效原因分析

系統重啟後ngix reload不生效原因分析

這是一種比較少見，困擾我很久的問題，雖然這個問題很簡單，但是找到根本原因還是費了不少時間，現在把分析過程分享如下。

前提：需要對Linux系統啟動過程、Nginx進程啟動過程及進程跟蹤有一定的理解。




一，Nginx reload過程分析：
經過查看官網文檔及結合Nginx源碼分析，大致得出reload過程進行了如下操作。


1，檢查配置是否正確
相當於nginx -t
2，打開日志文件
相當於nginx -s reopen
由於日志文件比較多，需要打開多個文件
3，重新監聽套接字
相當於nginx
這個步驟會初始化很多東西，重點關注哈希表
4，關閉舊worker進程
相當於nginx -s quit




二，nginx進程分析
1，首先了解nginx的兩種進程
master進程，root用戶打開，接收信號，管理worker進程
worker進程，nginx用戶打開，工作進程，負責處理http請求


2，starce跟蹤主進程號，期間執行nginx -s reload，發現卡在檢查日志文件這塊
主進程跟蹤，因為reload過程是系統發送HUP信號給nginx主進程
#starce -p 2298
......
open("/data/wwwlogs/access.xxx.xxx.xxx.log", O_WRONLY|O_CREAT|O_APPEND, 0644) = -1 EMFILE (Too many open files)
write(808, "2016/02/17 09:50:22 [emerg] 2298"..., 124) = 124
......


3，根據提示，查找進程的系統限制文件


master進程限制
# cat /proc/2398/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 10485760 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 127015 127015 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 127015 127015 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us


worker進程限制
# cat /proc/2300/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 10485760 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 127015 127015 processes
Max open files 409600 409600 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 127015 127015 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us




補充錯誤日志：
2016/02/17 10:48:05 [notice] 47386#0: signal process started
2016/02/17 10:48:05 [emerg] 2298#0: open() "/data/wwwlogs/access_xxx.xxx.xxx.log" failed (24: Too many open files)




三，解決方案
1，修改限制
一般從以下3方面調優：
第一：nginx.conf參數規劃與設置
worker_rlimit_nofile ：限制單個工作進程打開的最大文件數：
線上配置沒有問題
worker_rlimit_nofile 409600;


第二：系統級別的檢查與設置
就是 /etc/security/limits.conf的配置與修改，請參考Linux系統資源限制匯總
線上配置沒有問題
* soft nofile 655350
* hard nofile 655350


第三：內核級別的檢查與設置：
fs.file-max值的大小設置：
線上配置比較大
fs.file-max = 6553600
注意：file-max的默認值大概是系統內存的10%（系統內存以kb計算）




2，驗證生效
結果發現以上配置前期都有配置，但是重啟服務器發現主進程的限制並沒有修改過來，但是登陸服務器後無論在終端ulimit -n 查看還是關閉nginx主進程後重啟nginx都生效了，由此推理出
問題可能出在linux系統啟動過程中，也就是說nginx主進程啟動時，上面的限制配置沒有生效，後來查閱資料發現系統啟動後執行login時才會使limits.conf配置生效，所以需要調整順序。
根據實際情況，系統啟動過程如下：
1、讀取/etc/inittab來讀取默認級別 假設：讀取到的默認級別是 3
2、執行初始化系統腳本 /etc/rc.d/rc.sysinit 來初始化腳本
3、然後執行 /etc/rc.d/rc 腳本
4、執行/etc/rc.d/rc.local腳本，此腳本是啟動過程中最後啟動的一個腳本。
最後會執行 /bin/login 登錄用戶。至此系統啟動過程完成，login時才會執行/etc/profile，～/.bash_profile和～/.bashrc等，此時的ulimit -n查到的值不是nginx進程啟動時的值。
默認用戶登陸時會使limits.conf配置文件生效，這個比nginx進程啟動晚，要在這之前使配置生效，需要補充配置如下：
cat /etc/rc.local
ulimit -HSn 655350 （注意在nginx啟動前執行）
/usr/local/nginx/sbin/nginx






四，補充優化


主要是相關參數調大了一些。
1，內核優化
net.ipv4.tcp_max_tw_buckets 修改大一些，減少內核負擔，iptable本身對內核性能有影響
# ss -an |awk '{print $1}'|sort |uniq -c |sort -rn
15415 ESTAB
12979 TIME-WAIT
1961 FIN-WAIT-2
501 FIN-WAIT-1
234 LAST-ACK
32 SYN-RECV
11 LISTEN
3 CLOSING
1 SYN-SENT
1 State
1 CLOSE-WAIT


線上修改配置如下：
net.ipv4.tcp_max_tw_buckets = 18000


2，nginx優化
主要是哈希表，其他配置已經優化，哈希表有如下幾種
server_names_hash可以加
map_hash可以加
types_hash夠用
request header 不考慮
variables_hash 夠用


線上修改配置如下：
server_names_hash_max_size 512000;
server_names_hash_bucket_size 64; （默認）
map_hash_max_size 204800;
map_hash_bucket_size 64; （默認）