Ulimit的故障怎么解決

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

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

最近遇到一個非常有趣的問題。其中有一組HAProxy，頻繁出現(xiàn)問題。登錄上服務(wù)器，cpu、內(nèi)存、網(wǎng)絡(luò)、io一頓猛查。最終發(fā)現(xiàn)，機器上處于TIME_WAIT狀態(tài)的連接，多達(dá)6萬多個。

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

網(wǎng)絡(luò)狀態(tài)的統(tǒng)計數(shù)量，可以使用下面的命令進(jìn)行統(tǒng)計。

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這個數(shù)字，實在是太過于敏感。應(yīng)該是觸發(fā)了某種上限。

使我們更加感到疑惑的是：為什么TIME_WAIT狀態(tài)的連接，僅僅達(dá)到了65535，服務(wù)就不可用了?

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

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

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

答案是無數(shù)個?？墒嵌丝谥挥?5535個啊。

為什么端口只有65535個?

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

因為歷史原因造成的不可改變的標(biāo)準(zhǔn)，就是那么根深蒂固。

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

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

認(rèn)為Linux只能接受65535條連接的想法，只能說是犯了非常淺顯的想當(dāng)然主義。

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

2. 如何支持百萬連接?

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

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

ulmit，展示了每個進(jìn)程所能占用的文件句柄數(shù)量。

ulimit -n 65535

file-max，展示了操作系統(tǒng)能夠占用的文件句柄數(shù)量總和，針對的是所有的進(jìn)程。

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

file-nr，展示了當(dāng)前已經(jīng)使用的句柄數(shù)量和總的句柄數(shù)量?？梢阅脕碜霰O(jiān)控。

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

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

3. 如何設(shè)置?

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

ulimit -n 1000000

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

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

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

es  -  nofile  65535

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

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

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

cat /proc/sys/fs/nr_open 1048576

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

fs.file-max = 6553560

當(dāng)文件數(shù)量超出的時候，就會報kernel: VFS: file-max limit 65535 reached的錯誤。

總結(jié)一下。

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

為了能夠?qū)?shù)修改持久化，我們傾向于將改動寫入到文件里。進(jìn)程的文件句柄限制，可以放在/etc/security/limits.conf中，它的上限受到fs.nr_open的制約;操作系統(tǒng)的文件句柄限制，可以放到/etc/sysctl.conf文件中。最后，別忘了在/proc/$id/limits文件中，確認(rèn)修改是否對進(jìn)程生效了。

到此，相信大家對“Ulimit的故障怎么解決”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

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

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供服務(wù)器托管、用戶體驗、App開發(fā)、靜態(tài)網(wǎng)站、響應(yīng)式網(wǎng)站、網(wǎng)站設(shè)計

廣告

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