寫在前面
最近，在伺服器上搭建了一套壓測環境，不為別的，就為壓測下Nginx的效能，到底有沒有傳說中的那麼牛逼！具體環境為：11臺虛擬機器，全部安裝CentOS 6.8 64位作業系統，1檯安裝部署Nginx，其他10臺作為客戶端同時以壓滿CPU的執行緒向Nginx傳送請求，對Nginx進行壓測。沒想到，出現問題了！！
Nginx報錯
Nginx伺服器訪問量非常高，在Nginx的錯誤日誌中不停的輸出如下錯誤資訊。
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
2020-07-23 02:53:49 [alert] 13576#0: accept() failed (24: Too many open files)
根據錯誤日誌的輸出資訊，我們可以看出：是開啟的檔案控制程式碼數太多了，導致Nginx報錯了！那我們該如何解決這個問題呢？
問題分析
既然我們能夠從Nginx的錯誤日誌中基本能夠確定導致問題的原因，那這到底是不是Nginx本身的問題呢？答案為：是，也不全是！
為啥呢？原因很簡單：Nginx無法開啟那麼多的檔案控制程式碼，一方面是因為我沒有配置Nginx能夠開啟的最大檔案數；另一方面是因為CentOS 6.8作業系統本身對開啟的最大檔案控制程式碼數有限制，我同樣沒有配置作業系統的最大檔案控制程式碼數。所以說，不全是Nginx的鍋！在某種意義上說，我錯怪Nginx了！
在CentOS 6.8伺服器中，我們可以在命令列輸入如下命令來檢視伺服器預設配置的最大檔案控制程式碼數。
[root@binghe150 ~]# ulimit -n
1024
可以看到，在CentOS 6.8伺服器中，預設的最大檔案控制程式碼數為1024。
此時，當Nginx的連線數超過1024時，Nginx的錯誤日誌中就會輸出如下錯誤資訊。
[alert] 13576#0: accept() failed (24: Too many open files)
解決問題
那我們該如何解決這個問題呢？其實，也很簡單，繼續往下看！
使用如下命令可以把開啟檔案控制程式碼數設定的足夠大。
ulimit -n 655350
同時修改nginx.conf ， 新增如下配置項。
worker_rlimit_nofile 655350;
注意：上述配置需要與error_log同級別。
這樣就可以解決Nginx連線過多的問題，Nginx就可以支援高併發（這裡需要配置Nginx）。
另外， ulimit -n 還會影響到MySQL的併發連線數。把它提高，也可以提高MySQL的併發。
注意： 用 ulimit -n 655350 修改只對當前的shell有效，退出後失效。
永久解決問題
若要令修改ulimits的數值永久生效，則必須修改配置檔案，可以給ulimit修改命令放入/etc/profile裡面，這個方法實在是不方便。
還有一個方法是修改/etc/security/limits.conf配置檔案，如下所示。
vim /etc/security/limits.conf
在檔案最後新增如下配置項。
* soft nofile 655360
* hard nofile 655360
儲存並退出vim編輯器。
其中：星號代表全域性， soft為軟體，hard為硬體，nofile為這裡指可開啟的檔案控制程式碼數。
最後，需要注意的是：要使 limits.conf 檔案配置生效，必須要確保 pam_limits.so 檔案被加入到啟動檔案中。檢視 /etc/pam.d/login 檔案中是否存在如下配置。
session required /lib64/security/pam_limits.so
不存在，則需要新增上述配置項。
獲取福利
關注「 冰河技術 」微信公眾號，後臺回覆 “設計模式” 關鍵字領取《深入淺出Java 23種設計模式》PDF文件。回覆“Java8”關鍵字領取《Java8新特性教程》PDF文件。
好了，今天就聊到這兒吧！別忘了點個贊，給個在看和轉發，讓更多的人看到，一起學習，一起進步！！
寫在最後
如果你覺得冰河寫的還不錯，請微信搜尋並關注「 冰河技術 」微信公眾號，跟冰河學習高併發、分散式、微服務、大資料、網際網路和雲原生技術，「 冰河技術 」微信公眾號更新了大量技術專題，每一篇技術文章乾貨滿滿！不少讀者已經通過閱讀「 冰河技術 」微信公眾號文章，吊打面試官，成功跳槽到大廠；也有不少讀者實現了技術上的飛躍，成為公司的技術骨幹！如果你也想像他們一樣提升自己的能力，實現技術能力的飛躍，進大廠，升職加薪，那就關注「 冰河技術 」微信公眾號吧，每天更新超硬核技術乾貨，讓你對如何提升技術能力不再迷茫！
