1、問題闡述：
too many open files：顧名思義即打開過多文件數。
不過這里的files不單是文件的意思，也包括打開的通訊鏈接(比如socket)，正在監聽的端口等等，所以有時候也可以叫做句柄(handle)，這個錯誤通常也可以叫做句柄數超出系統限制。
2、產生的原因：
經常在使用linux的時候出現，大多數情況是由於程序沒有正常關閉一些資源引起的，所以出現這種情況，請檢查io讀寫，socket通訊等是否正常關閉。
3、經典案例：
很多項目上線不久運行了一段時間后，服務突然宕了，經檢查日志，出現了too many open files 錯誤。
4、解決方案：
前奏：其實Linux是有文件句柄限制的，而且默認不是很高，一般都是1024，作為一台生產服務器，其實很容易就達到 這個數量，因此我們需要把這個值改大一些。我們可以用ulimit -n 來查看當前用戶句柄數限制。那么這個1024是系統的限制，還是用戶的限制呢。其實，這個是用戶限制來的，完整的說法，應該是當前用戶准備要運行的程序的限制。
1、這個限制是針對單個程序的限制
2、這個限制不會改變之前已經運行了的程序的限制
3、對這個值的修改，退出了當前的shell就會消失
因此出現這種問題有兩種解決方式：
第一：增大文件句柄數。這種方式能及時解決問題，但是不能夠徹底的解決問題，可以為徹底解決問題提供一定的時間保證。那么如何增大文件句柄數數呢？
如修改文件句柄數為65535，ulimit -n 65535.此時系統的文件句柄數為65535.
2）將ulimit 值添加到/etc/profile文件中（適用於有root權限登錄的系統）
為了每次系統重新啟動時，都可以獲取更大的ulimit值，將ulimit 加入到/etc/profile 文件底部。
echo ulimit -n 65535 >>/etc/profile
source /etc/profile #加載修改后的profile
ulimit -n #顯示65535，修改完畢！
到此為止，你以為大功告成了么，其實不然，突然發現自己再次登錄進來的時候，ulimit的值還是1024，這是為什么呢？ 用戶登錄的時候執行sh腳本的順序：
/etc/profile.d/file
/etc/profile
/etc/bashrc
/mingjie/.bashrc
/mingjie/.bash_profile
由於ulimit -n的腳本命令加載在第二部分，用戶登錄時由於權限原因在第二步還不能完成ulimit的修改，所以ulimit的值還是系統默認的1024。所以想徹底改變這種問題，就必須做如下操作：修改/etc/security/limits.conf
里面有很詳細的注釋，比如
* soft nofile 2048
* hard nofile 32768
就可以將文件句柄限制統一改成軟2048，硬32768
那么什么是軟限制，什么是硬限制
硬限制是實際的限制，而軟限制，是warnning限制，只會做出warning
這樣就實實際際的增大了文件句柄數。
第二：分析句柄數，查找原因，這是解決問題最根本的辦法。那么如何分析那，就需要用到lsof這個命令了（關於這個命令大家可以在網上學習學習）。
（1）統計各進程打開句柄數：lsof -n|awk '{print $2}'|sort|uniq -c|sort -nr
（2）統計各用戶打開句柄數：lsof -n|awk '{print $3}'|sort|uniq -c|sort -nr
（3）統計各命令打開句柄數：lsof -n|awk '{print $1}'|sort|uniq -c|sort -nr
就掌商通來說，通過命令分析發現是一個叫xmpp的東西打開的連接數居多，占到了單個進程總打開連接數的百分之八十以上，再仔細分析，xmpp是消息推送產生的連接，那么到這里問題比較明確了，接下來就是要分析為什么消息推送會打開如此多的文件句柄，且一直連着也不斷開。這樣問題就定位了。另外還有一些進程打開文件句柄數也比較多，這時你可以對比其他服務器，看是否其他服務器也是如此，以保證全面的解決問題。