netstat -n | awk '/^tcp/ end '
last_ack 1
syn_recv 15
close_wait 7729
established 471
fin_wait1 3
fin_wait2 52
syn_sent 1
time_wait 725
從結果可以看到有大量的連線處於close_wait狀態。
要解決這個問題的可以修改系統的引數，系統預設超時時間的是7200秒，也就是2小時。
預設如下：
tcp_keepalive_time = 7200 seconds (2 hours)
tcp_keepalive_probes = 9
tcp_keepalive_intvl = 75 seconds
意思是如果某個tcp連線在idle 2個小時後,核心才發起probe.如果probe 9次(每次75秒)不成功,核心才徹底放棄,認為該連線已失效
修改後
sysctl -w net.ipv4.tcp_keepalive_time=30
sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_keepalive_intvl=2
經過這個修改後，伺服器會在短時間裡**沒有關閉的tcp連線。
TCP連線大量CLOSE WAIT狀態問題排查
close wait產生原因 close wait是被動關閉連線是形成的，根據tcp狀態機，伺服器端收到客戶端傳送的fin，tcp協議棧會自動傳送ack，鏈結進入close wait狀態。但如果伺服器端不執行socket的close 操作，狀態就不能由close wait遷移到last ack，則系...
https請求，大量TCP請求time out
對傳送https請求進行效能測試，大量tcp連線處於time wait狀態。修改linux核心引數，發現只是對http起作用，對https未起到作用。https tcp time wait屬於系統環境的問題。在頻寬為1000兆的網路環境中，造成網路傳輸的處理高於伺服器對https的處理能力。從而出現...
大量資料的tcp的recv
最近在調程式的時候，發現傳送端傳送乙個119136個char的記憶體的時候，在接收端不能全部接收，於是，通過除錯發現，必須在接收端多次的recv以後，進行拼接 如下 char lenbuf 4 int ilen 接收資料 int bytes 先接受前面的四位訊息體長度 if bytes recv c...