Ulimit的坑，讓我的故障一波又一波
本文轉(zhuǎn)載自微信公眾號(hào)「小姐姐味道」，作者小姐姐養(yǎng)的狗。轉(zhuǎn)載本文請(qǐng)聯(lián)系小姐姐味道公眾號(hào)。
最近遇到一個(gè)非常有趣的問(wèn)題。其中有一組HAProxy，頻繁出現(xiàn)問(wèn)題。登錄上服務(wù)器，cpu、內(nèi)存、網(wǎng)絡(luò)、io一頓猛查。最終發(fā)現(xiàn)，機(jī)器上處于TIME_WAIT狀態(tài)的連接，多達(dá)6萬(wàn)多個(gè)。
TIME_WAIT狀態(tài)，一般都會(huì)出現(xiàn)在HAProxy、Nginx這種代理機(jī)器上，主要是由于頻繁的主動(dòng)關(guān)閉所造成的。通過(guò)修改reuse和回收參數(shù)，可以比較快速的解決問(wèn)題。
網(wǎng)絡(luò)狀態(tài)的統(tǒng)計(jì)數(shù)量，可以使用下面的命令進(jìn)行統(tǒng)計(jì)。
- 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
這本來(lái)沒(méi)什么神奇的，但65535這個(gè)數(shù)字，實(shí)在是太過(guò)于敏感。應(yīng)該是觸發(fā)了某種上限。
使我們更加感到疑惑的是：為什么TIME_WAIT狀態(tài)的連接，僅僅達(dá)到了65535，服務(wù)就不可用了?
到處號(hào)稱(chēng)的單機(jī)百萬(wàn)連接，是在吹牛皮么?怎么這么經(jīng)不起折騰?
65535，表示等于2的16次方減一，是一個(gè)神奇的數(shù)字。先把這小數(shù)字扔在一邊，我們來(lái)看一下Linux到底能支持多少個(gè)連接。
1. Linux能夠支持多少連接?
答案是無(wú)數(shù)個(gè)。可是端口只有65535個(gè)啊。
為什么端口只有65535個(gè)?
這是一個(gè)歷史原因，因?yàn)樵赥CP、UDP協(xié)議的開(kāi)頭，會(huì)分別有16位來(lái)存儲(chǔ)源端口號(hào)和目標(biāo)端口號(hào)。很遺憾的是，這個(gè)值是short類(lèi)型的，大小也是2^16-1。
因?yàn)闅v史原因造成的不可改變的標(biāo)準(zhǔn)，就是那么根深蒂固。
那Linux到底能支持多少個(gè)連接呢?答案是無(wú)數(shù)個(gè)。
拿nginx來(lái)說(shuō)，我們把它監(jiān)聽(tīng)在80端口上。這時(shí)候A機(jī)器去連接Nginx，可以發(fā)起多達(dá)6w多條長(zhǎng)連接。如果B機(jī)器去連接Nginx，同樣也可以發(fā)起6w多條連接。這是由于確定一條連接，是由src和dst來(lái)共同決定的。
認(rèn)為L(zhǎng)inux只能接受65535條連接的想法，只能說(shuō)是犯了非常淺顯的想當(dāng)然主義。
65535個(gè)端口，作為壓測(cè)機(jī)可能對(duì)你來(lái)說(shuō)太小了一些。但對(duì)于服務(wù)器來(lái)說(shuō)，已經(jīng)綽綽有余了。
2. 如何支持百萬(wàn)連接?
從上面可以看到，連接數(shù)，是沒(méi)有限制的。但Linux還有一層防護(hù)，那就是文件句柄數(shù)。通過(guò)lsof命令查看到的那些東西，就是所謂的文件句柄。
先來(lái)看一下幾個(gè)命令的展示。
ulmit，展示了每個(gè)進(jìn)程所能占用的文件句柄數(shù)量。
- ulimit -n
- 65535
file-max，展示了操作系統(tǒng)能夠占用的文件句柄數(shù)量總和，針對(duì)的是所有的進(jìn)程。
- cat /proc/sys/fs/file-max
- 766722
file-nr，展示了當(dāng)前已經(jīng)使用的句柄數(shù)量和總的句柄數(shù)量?？梢阅脕?lái)做監(jiān)控。
- cat /proc/sys/fs/file-nr
- 1824 0 766722
要支持百萬(wàn)連接，既要放開(kāi)操作系統(tǒng)級(jí)別的句柄，也要放開(kāi)進(jìn)程級(jí)別的句柄。也就是說(shuō)，ulimit和file-max的顯示，都要大于百萬(wàn)才成。
3. 如何設(shè)置?
設(shè)置進(jìn)程的句柄個(gè)數(shù)，常用的方式就有ulimit，但是非常非常不推薦。原因無(wú)他，只有在同一個(gè)shell中啟動(dòng)的進(jìn)程，ulimit的設(shè)置才會(huì)生效。你打開(kāi)另外一個(gè)shell，或者重啟機(jī)器，ulimit的改動(dòng)都會(huì)丟失。就是下面這種方式：
- ulimit -n 1000000
正確的方式，是修改/etc/security/limits.conf文件。比如下面的內(nèi)容。
- root soft nofile 1000000
- root hard nofile 1000000
- * soft nofile 1000000
- * hard nofile 1000000
可以看到，我們可以針對(duì)于特定的用戶(hù)，修改其句柄數(shù)量。這在安裝es等應(yīng)用時(shí)，經(jīng)常碰到。
- es - nofile 65535
但即使是這種方式，也要求你需要打開(kāi)一個(gè)新的shell進(jìn)行操作。在當(dāng)前修改的shell里或者修改之前的shell里，同樣不生效。xjjdog就曾遇到過(guò)多起這樣明明放開(kāi)了限制，但還是發(fā)生問(wèn)題的案例。
要看到這些改變是否已經(jīng)對(duì)進(jìn)程生效，可以查看進(jìn)程的內(nèi)存映射文件。比如cat /proc/180323/limits，其中會(huì)有詳細(xì)的展示。
這個(gè)數(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百多萬(wàn)!
- fs.file-max = 6553560
當(dāng)文件數(shù)量超出的時(shí)候，就會(huì)報(bào)kernel: VFS: file-max limit 65535 reached的錯(cuò)誤。
總結(jié)一下。
Linux即使放開(kāi)一個(gè)端口，能夠接受的連接也是海量的。這些連接的上限，受到單進(jìn)程文件句柄數(shù)量和操作系統(tǒng)文件句柄數(shù)量的限制，也就是ulimit和file-max。
為了能夠?qū)?shù)修改持久化，我們傾向于將改動(dòng)寫(xiě)入到文件里。進(jìn)程的文件句柄限制，可以放在/etc/security/limits.conf中，它的上限受到fs.nr_open的制約;操作系統(tǒng)的文件句柄限制，可以放到/etc/sysctl.conf文件中。最后，別忘了在/proc/$id/limits文件中，確認(rèn)修改是否對(duì)進(jìn)程生效了。
如此，百萬(wàn)連接才名不虛傳。我比較奇怪的是，為什么Linux不默認(rèn)放開(kāi)這些配置呢?做成65535也認(rèn)啊，為什么搞個(gè)1024?
作者簡(jiǎn)介：小姐姐味道 (xjjdog)，一個(gè)不允許程序員走彎路的公眾號(hào)。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。我的個(gè)人微信xjjdog0，歡迎添加好友，進(jìn)一步交流。
