Too many open files錯誤與解決方法

致前輩：該問題的解決思路給了我很大的啓發，文章做者Lis, Linux資深技術專家。

　　問題現象：這是一個基於Java的web應用系統，在後臺添加數據時提示沒法添加，因而登錄服務器查看Tomcat 日誌，發現以下異常信息，java.io.IOException:too many open files

　經過這個報錯信息，基本判斷是系統可使用的文件描述符不夠了，因爲Tomcat服務系統www用戶啓動的，因而以www 用戶登錄系統，經過ulimit -n 命令查看系統能夠打開最大文件描述符的數量:

$ ulimit -n

65535

能夠看到這臺服務器設置的最大能夠打開的文件描述符已是65535了，這麼大的值應該夠用了，可是爲何提示這樣的錯誤呢？

解決思路，這個案例涉及ulimit 命令的使用

在使用ulimit 時，有如下幾種使用方法：

　　1.在用戶環境變量中加入

若是用戶使用的是bash，那麼能夠在用戶目錄的環境變量文件.bashrc或者.bash_profile中加入 ulimit -u 128 來限制用戶最多可使用128個進程

　　2.在應用程序的啓動腳本中加入

若是應用程序是Tomcat， 那麼能夠再Tomcat 的啓動腳本startup.sh 中加入 ulimit -n 65535 來閒置用戶最多可使用65535個文件描述符

　　3.直接在shell命令終端執行ulimit 命令

這種方法的資源限制僅僅在執行命令的終端生效，在退出或者和關閉終端後，設置失效，而且這個設置不影響其餘shell 終端

解決問題：

　　在瞭解ulimit 知識後，接着上面的案例，既然ulimit 設置沒有問題，那麼必定是設置沒有生效致使的，接下來檢查下啓動 Tomcat 的 www 用戶環境變量是否添加 ulimit 限制，檢查後發現，www 用戶並沒有ulimit限制。因而繼續檢查Tomcat 啓動腳本startup.sh 文件是否添加了 ulimit限制，檢查後發現也沒有添加。最後考慮是否將限制加到了limits.conf文件中，因而檢查limits.conf 文件，操做以下

#cat /etc/security/limits.conf | grep www

www soft nofile 65535

www hard nofile 65535

從輸出可知，ulimit限制加在limits.conf文件中，既然限制已經添加了，配置 也沒有什麼錯，爲什麼還會報錯，通過思考，判斷只有一種可能，那就是Tomcat 的啓動時間早於ulimit 資源限制的添加時間，因而首先查看下Tomcat 啓動時間，操做以下

#uptime

Up 283 days

#pgrep -f tomcat

4667

#ps -eo pid, lstart, etime | grep 4667

4667 Sat Jul 6 09;33:39 2013 77-05:26:02

從輸出能夠看出，這臺服務器已經有283天沒有重啓了，而Tomcat 是在2013年7月6號9點啓動的，啓動了將近77天，接着看看limits.conf文件的修改時間，

#stat /etc/security/limits.conf

經過stat 命令清楚的看到，limits.conf文件最後的修改時間是2013年7月12日，晚於Tomcat啓動時間，如此，重啓Tomcat以後問題解決。

 

　　感悟：排查問題的思路清晰，按部就班，最出彩的是排錯過程當中對各類細節的把握，服務的啓動時間與配置文件的修改時間，這個細節讓我非常受益，不虧是老運維出來的紮實功底。再敬 前輩。