TCP連接TIME-WAIT解決方案
阿新 • • 發佈:2018-11-27
*** 數據 file 追加 等待 文件中 重用 參數設置 zabb 問題根源:
為什麽會產生time-wait? 當客戶端與服務器之間進行四次斷開時,當客戶端接收 到服務器端發送過來的斷開確認報文後,會發送最後一次 ACK報文,發送之後客戶端會進入time-wait狀態,這個過 成會持續一分鐘,用來完成接收剩余所有從服務器端發送 過來的數據[由於網絡延遲等原因導致數據延遲達到], 同時也可以確自己發送的最後一個ACK斷開確認報文能被 服務器端收到! time-wait狀態的危害: 1 time-wait狀態會占據一定量的內存資源,雖然很少但 是如果這種連接在一個繁忙的服務器中過於多的話,會額外消耗內存資源 2 time-wait狀態會占據文件描述符,因為要通過網絡和 web程序通信,需要監聽套接字文件,這樣不僅會占用端 口還會占用文件描述符,在高並發短連接的場景中,額外 致命,往往一個連接請求一個資源需要幾秒中,但是time -wait連接卻要等待1分鐘,這往往會迅速消耗端口和描述符資源 當達到設置的閥值時,新的TCP連接的建立將會受到影響 如何檢測這種狀態: 方法1: netstat -tnl | awk ‘/^tcp/{print $6}‘ | uniq -c 可以設置周期性任務計劃將這類數據追加至一個文件中 進行查看! 方法2: 使用zabbix自定義key time-wait connection 在agent端使用UserParameter= 來創建一個收集這個值 的命令定期傳遞給服務器端,在服務器端設置觸發器來 監控這個值的正常範圍 解決方案思路: 1 linux系統自身參數設置過小: 調整如下參數: 所有用戶一共可以打開的文件數: [root@zabbix-server13:35:11~]#sysctl -a|grep file-max fs.file-max = 44348 單用戶可打開的文件數: [root@zabbix-server13:35:11~]#sysctl -a|grep file-max fs.file-max = 44348 web服務器自身是否開放進程數過小: 可以調整最大並發訪問值等參數 linux系統端口範圍: [root@zabbix-server13:44:32~]#sysctl -a | grep ipv4.ip_local_port_range net.ipv4.ip_local_port_range = 32768 60999 可以選擇開放1024端口之上的所有端口! 1024 ~ 65535 2 如果是因為軟件開發原因導致可暫時設置如下參數: net.ipv4.tcp_tw_recycle = 1 表示開啟TCP連接中TIME-WAIT sockets的快速回收,默認為0,表示關閉 net.ipv4.tcp_tw_reuse = 1 表示開啟重用。允許將TIME-WAIT sockets重新用於新的TCP連接,默認為0,表示關閉; net.ipv4.tcp_fin_timeout = 60 縮短系統設定的time-wait時間 net.ipv4.tcp_syncookies = 1 表示開啟SYN Cookies。當出現SYN等待隊列溢出時,啟用cookies來處理,可防範少量SYN***,默認為0,表示關閉; 先有效控制time-wait的數量然後在排查問題所在!
TCP連接TIME-WAIT解決方案