Ulimit的故障怎么解決

本篇內容主要講解“Ulimit的故障怎么解決”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Ulimit的故障怎么解決”吧!

10年積累的成都網站制作、做網站經驗，可以快速應對客戶對網站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網絡服務。我雖然不認識你，你也不認識我。但先做網站設計后付款的網站建設流程，更有長嶺免費網站建設讓你可以放心的選擇與我們合作。

最近遇到一個非常有趣的問題。其中有一組HAProxy，頻繁出現問題。登錄上服務器，cpu、內存、網絡、io一頓猛查。最終發現，機器上處于TIME_WAIT狀態的連接，多達6萬多個。

TIME_WAIT狀態，一般都會出現在HAProxy、Nginx這種代理機器上，主要是由于頻繁的主動關閉所造成的。通過修改reuse和回收參數，可以比較快速的解決問題。

網絡狀態的統計數量，可以使用下面的命令進行統計。

netstat -ant|awk '/^tcp/ {++S[$NF]} END {for(a in S) print (a,S[a])}' ESTABLISHED 70 FIN_WAIT2 30 CLOSING 33 TIME_WAIT 65520

這本來沒什么神奇的，但65535這個數字，實在是太過于敏感。應該是觸發了某種上限。

使我們更加感到疑惑的是：為什么TIME_WAIT狀態的連接，僅僅達到了65535，服務就不可用了?

到處號稱的單機百萬連接，是在吹牛皮么?怎么這么經不起折騰?

65535，表示等于2的16次方減一，是一個神奇的數字。先把這小數字扔在一邊，我們來看一下Linux到底能支持多少個連接。

1. Linux能夠支持多少連接?

答案是無數個。可是端口只有65535個啊。

為什么端口只有65535個?

這是一個歷史原因，因為在TCP、UDP協議的開頭，會分別有16位來存儲源端口號和目標端口號。很遺憾的是，這個值是short類型的，大小也是2^16-1。

因為歷史原因造成的不可改變的標準，就是那么根深蒂固。

那Linux到底能支持多少個連接呢?答案是無數個。

拿nginx來說，我們把它監聽在80端口上。這時候A機器去連接Nginx，可以發起多達6w多條長連接。如果B機器去連接Nginx，同樣也可以發起6w多條連接。這是由于確定一條連接，是由src和dst來共同決定的。

認為Linux只能接受65535條連接的想法，只能說是犯了非常淺顯的想當然主義。

65535個端口，作為壓測機可能對你來說太小了一些。但對于服務器來說，已經綽綽有余了。

2. 如何支持百萬連接?

從上面可以看到，連接數，是沒有限制的。但Linux還有一層防護，那就是文件句柄數。通過lsof命令查看到的那些東西，就是所謂的文件句柄。

先來看一下幾個命令的展示。

ulmit，展示了每個進程所能占用的文件句柄數量。

ulimit -n 65535

file-max，展示了操作系統能夠占用的文件句柄數量總和，針對的是所有的進程。

cat /proc/sys/fs/file-max 766722

file-nr，展示了當前已經使用的句柄數量和總的句柄數量。可以拿來做監控。

cat /proc/sys/fs/file-nr 1824  0 766722

要支持百萬連接，既要放開操作系統級別的句柄，也要放開進程級別的句柄。也就是說，ulimit和file-max的顯示，都要大于百萬才成。

3. 如何設置?

設置進程的句柄個數，常用的方式就有ulimit，但是非常非常不推薦。原因無他，只有在同一個shell中啟動的進程，ulimit的設置才會生效。你打開另外一個shell，或者重啟機器，ulimit的改動都會丟失。就是下面這種方式：

ulimit -n 1000000

正確的方式，是修改/etc/security/limits.conf文件。比如下面的內容。

root soft nofile 1000000 root hard nofile 1000000 * soft nofile 1000000 * hard nofile 1000000

可以看到，我們可以針對于特定的用戶，修改其句柄數量。這在安裝es等應用時，經常碰到。

es  -  nofile  65535

但即使是這種方式，也要求你需要打開一個新的shell進行操作。在當前修改的shell里或者修改之前的shell里，同樣不生效。xjjdog就曾遇到過多起這樣明明放開了限制，但還是發生問題的案例。

要看到這些改變是否已經對進程生效，可以查看進程的內存映射文件。比如cat /proc/180323/limits，其中會有詳細的展示。

這個數值，也并不是想要設多大就多大的。它的大小上限，是由nr_open決定的。想要更大，就要修改/ect/sysct.conf  中fs.nr_open的值。

cat /proc/sys/fs/nr_open 1048576

那file-max又該如何修改呢?建議修改/etc/sysctl.conf文件，加入下面內容。足足有6百多萬!

fs.file-max = 6553560

當文件數量超出的時候，就會報kernel: VFS: file-max limit 65535 reached的錯誤。

總結一下。

Linux即使放開一個端口，能夠接受的連接也是海量的。這些連接的上限，受到單進程文件句柄數量和操作系統文件句柄數量的限制，也就是ulimit和file-max。

為了能夠將參數修改持久化，我們傾向于將改動寫入到文件里。進程的文件句柄限制，可以放在/etc/security/limits.conf中，它的上限受到fs.nr_open的制約;操作系統的文件句柄限制，可以放到/etc/sysctl.conf文件中。最后，別忘了在/proc/$id/limits文件中，確認修改是否對進程生效了。

到此，相信大家對“Ulimit的故障怎么解決”有了更深的了解，不妨來實際操作一番吧！這里是創新互聯網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！

文章名稱：Ulimit的故障怎么解決
分享地址：http://m.kartarina.com/article16/pppjgg.html

成都網站建設公司_創新互聯，為您提供服務器托管、用戶體驗、App開發、靜態網站、響應式網站、網站設計

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯