TCP鏈接數過多問題

    在一次生產上線後,發現使用的 8086 端口相關的 TCP 鏈接數居然多大 6K+ ,有時候甚至會逼近 1w ,這個數量對於一個只是在內部使用的監控系統來講, 不管如何都是沒法接受的, 因而開始一系列的排查過程. 本文記錄了這個問題的主要解決過程,算是對這一次殺 bug 過程的一個總結.

問題描述

   使用命令

netstat -apn | grep 8086linux

    能夠看到大量處於 TIME_WAIT狀態的 tcp 鏈接tcp

   使用命令測試

netstat -apn | grep 8086 | grep TIME_WAIT | wc -l優化

  進行計數, 會發現鏈接數會不斷增長, 通過屢次測試, 在公司環境中鏈接數至少都會達到 6k+. 這個問題必需要解決, 一方面是由於每條 tcp 鏈接都會佔用內存, 另外一方面系統的動態端口數也是有限的.code

很明顯這些鏈接幾乎都處在 TIME_WAIT 狀態,因此在繼續往下走以前, 須要瞭解下 TIME_WAIT 這個關鍵字blog

TIME_WAIT

咱們知道 一條 tcp 鏈接從開始到結束會經歷多個狀態, 換句話說, 能夠把 一條 tcp 鏈接當作是一個 狀態機. 這個狀態圖以下:ip

 

能夠看到, 凡是主動進行關閉 tcp 鏈接的一方, 都會通過 TIME_WAIT 這個狀態.接下來再通過 2MSL 的時間後內核再徹底釋放相應的文件描述符和端口. (順便提一下, MSL 是最大分段壽命, 是一個 TCP 分段能夠存在於互聯網系統中的最大時間, 在 Linux 下能夠用命令查看 MSL的數值:內存

cat /proc/sys/net/ipv4/tcp_fin_timeoutclass

到這個地方能夠推斷出, 是 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
相關文章
相關標籤/搜索