1、問題闡述：linux

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

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

二、產生的緣由：服務器

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

三、經典案例：學習

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

四、解決方案：日志

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

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

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

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

總結

以上是生活随笔為你收集整理的linux 端口数 句柄数,linux文件句柄数的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。