系統重啟后nginx 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; （默認）
