進一步分析報錯原因，具體步驟如下：
l 查看這兩台系統最大的允許文件打開數
[root@nginx01 logs]# cat /proc/sys/fs/file-max
343927
l 通過ulimit -n命令可以查看目前該linux系統里打開文件描述符的最大值
[root@nginx01 logs]# ulimit -n
20480
檢查到這里，目前系統最大的打開文件數，我們配置了20480，可以說，這其實是一個比較“大”的連接數，應該能夠滿足要求了。接下來，我們去查看nginx這個服務中，其自身的連接數是否配置合理？
l 一般來說，nginx的連接數，有以下兩個參數決定，分別是：worker_rlimit_nofile 和worker_connections。
n worker_rlimit_nofile，這個參數表示當一個nginx進程打開的最多文件數目，它的理論值應該是打開文件描述符的最大值（ulimit –n）與nginx進程數相除，但是ngixn分配請求並不是那么均勻，所以一般與 ulimint –n的值保持一致。
根據上述ulimit –n結果，我們對該值可以配置20480。事實上，我們也的確給它配了20480
n worker_connections，這個參數表示每個進程允許的最多連接數，理論上每台nginx服務器的最大連接數為 worker_processes * worker_connections， 其中，因為這兩台ngixn系統均是4cpu，所以worker_processes參數=4。 而查看worker_connections，我們發現，配置的是默認的1024， 也就是說，這兩台nginx服務器最大的連接數不能超過4096（含報錯連接數、已結束未回收的連接數），而之前的報錯“[alert] 12339#0: 1024 worker_connections are not enough”，大致意思是：12339（個數）並發連接已經超過了打開文件的資源限制:1024！
此外， 你修改worker_connections值時，是不能超過worker_rlimit_nofile的這個值。
鑒於上述兩點，我們只需配置worker_connections=5000， 那么nginx的最大連接數=worker_connections（5000）* worker_processes（4）=20000，該值大於12339
修改兩台nginx.conf配置文件中的worker_connections = 5000 （原來為1024），並重啟nginx