Ulimit的坑，讓我的故障一波又一波
本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗。轉載本文請聯系小姐姐味道公眾號。
最近遇到一個非常有趣的問題。其中有一組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文件中，確認修改是否對進程生效了。
如此，百萬連接才名不虛傳。我比較奇怪的是，為什么Linux不默認放開這些配置呢?做成65535也認啊，為什么搞個1024?
作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。
