在一次生產上線后,發現使用的 8086 端口相關的 TCP 連接數竟然多大 6K+ ,有時候甚至會逼近 1w ,這個數量對於一個只是在內部使用的監控系統來說, 無論如何都是無法接受的, 於是開始一系列的排查過程. 本文記錄了這個問題的主要解決過程,算是對這一次殺 bug 過程的一個總結.
問題描述
使用命令
netstat -apn | grep 8086
可以看到大量處於 TIME_WAIT狀態的 tcp 連接
使用命令
netstat -apn | grep 8086 | grep TIME_WAIT | wc -l
進行計數, 會發現連接數會不斷增加, 經過多次測試, 在公司環境中連接數至少都會達到 6k+. 這個問題必須要解決, 一方面是因為每條 tcp 連接都會占用內存, 另一方面系統的動態端口數也是有限的.
很明顯這些連接幾乎都處在 TIME_WAIT 狀態,所以在繼續往下走之前, 需要了解下 TIME_WAIT 這個關鍵字
TIME_WAIT
我們知道 一條 tcp 連接從開始到結束會經歷多個狀態, 換句話說, 可以把 一條 tcp 連接看成是一個 狀態機. 這個狀態圖如下:
可以看到, 凡是主動進行關閉 tcp 連接的一方, 都會經過 TIME_WAIT 這個狀態.接下來再經過 2MSL 的時間后內核再完全釋放相應的文件描述符和端口. (順便提一下, MSL 是最大分段壽命, 是一個 TCP 分段可以存在於互聯網系統中的最大時間, 在 Linux 下可以用命令查看 MSL的數值：
cat /proc/sys/net/ipv4/tcp_fin_timeout
到這個地方可以推斷出, 是 8086 端口主動關閉了 tcp 連接, 導致擠壓了大量的處於 TIME_WAIT 狀態下的連接在等待內核釋放
問題處理
為了解決大量TCP連接處於TIME_WAIT狀態，需要對linux內核參數進行優化。編輯/etc/sysctl.conf文件，添加如下參數：
net.ipv4.conf.all.accept_redirects = 0 net.ipv4.tcp_fin_timeout = 30 net.ipv4.tcp_keepalive_time = 1200 net.ipv4.ip_local_port_range = 1024 65000 net.ipv4.tcp_max_syn_backlog = 8192 net.ipv4.tcp_max_tw_buckets = 2000
利用root口令執行sysctl -p