linux文件句柄數

一、問題闡述：

too many open files：顧名思義即打開過多文件數。

不過這裏的files不單是文件的意思，也包括打開的通信連接(好比socket)，正在監聽的端口等等，因此有時候也能夠叫作句柄(handle)，這個錯誤一般也能夠叫作句柄數超出系統限制。

二、產生的緣由：

常常在使用linux的時候出現，大多數狀況是因爲程序沒有正常關閉一些資源引發的，因此出現這種狀況，請檢查io讀寫，socket通信等是否正常關閉。

三、經典案例：

不少項目上線不久運行了一段時間後，服務忽然宕了，經檢查日誌，出現了too many open files 錯誤。

四、解決方案：

前奏：其實Linux是有文件句柄限制的，並且默認不是很高，通常都是1024，做爲一臺生產服務器，其實很容易就達到 這個數量，所以咱們須要把這個值改大一些。咱們能夠用ulimit -n 來查看當前用戶句柄數限制。那麼這個1024是系統的限制，仍是用戶的限制呢。其實，這個是用戶限制來的，完整的說法，應該是當前用戶準備要運行的程序的限制。

一、這個限制是針對單個程序的限制

二、這個限制不會改變以前已經運行了的程序的限制

三、對這個值的修改，退出了當前的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是消息推送產生的鏈接，那麼到這裏問題比較明確了，接下來就是要分析爲何消息推送會打開如此多的文件句柄，且一直連着也不斷開。這樣問題就定位了。另外還有一些進程打開文件句柄數也比較多，這時你能夠對比其餘服務器，看是否其餘服務器也是如此，以保證全面的解決問題。