【網絡編程】服務端產生大量的close_wait狀態的進程分析
首先要明白close_wait狀態是在tcp通信四次握手時的一個中間狀態：
即當被動關閉方發送完ACK後進入的狀態。這個狀態的結束，即要達到下一個狀態LASK_ACK需要在發無端發送完剩余的數據後(send)、調用close函數之後。
下面我們模擬這種情況，即服務端發送完剩余的數據後，並沒有調用close函數：
client端代碼：
1 #include <stdio.h> 2 #include <stdlib.h> 3 #include <string.h> 4 #include <unistd.h> 5#include <sys/socket.h> 6 #include <netinet/in.h> 7 #include <arpa/inet.h> 8 9 10 #define MAXLINE 80 11 #define SERV_PORT 8000 12 13 14 int main(int argc, char *argv[]) 15 { 16 struct sockaddr_in servaddr; 17 char str[MAXLINE] = "test "; 18 int sockfd, n;19 20 21 while(1) 22 { 23 sockfd = socket(AF_INET, SOCK_STREAM, 0); 24 25 26 bzero(&servaddr, sizeof(servaddr)); 27 servaddr.sin_family = AF_INET; 28 inet_pton(AF_INET, "192.168.254.26", &servaddr.sin_addr); 29 servaddr.sin_port = htons(SERV_PORT);30 31 32 connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)); 33 write(sockfd, str, strlen(str)); 34 35 36 close(sockfd); 37 sleep(2); 38 } 39 40 41 return 0; 42 }
server端代碼：
1 #include <stdio.h> 2 #include <stdlib.h> 3 #include <string.h> 4 #include <iostream> 5 6 7 #include <sys/mman.h> 8 #include <sys/stat.h> /* For mode constants */ 9 #include <fcntl.h> /* For O_* constants */ 10 11 12 #include <unistd.h> 13 #include <arpa/inet.h> 14 15 16 using namespace std; 17 18 19 #define LENGTH 128 20 #include "netinet/in.h" 21 #define MAXLINE 80 22 #define SERV_PORT 8000 23 24 25 int main(int argc,char** argv) 26 { 27 struct sockaddr_in servaddr, cliaddr; 28 socklen_t cliaddr_len; 29 int listenfd; 30 char buf[MAXLINE]; 31 char str[INET_ADDRSTRLEN]; 32 //int i, n; 33 int n; 34 35 36 //創建socket 37 listenfd = socket(AF_INET, SOCK_STREAM, 0); 38 39 40 //設置端口重用 41 int opt = 1; 42 setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); 43 44 45 //fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL, 0) | O_NONBLOCK); 46 47 48 bzero(&servaddr, sizeof(servaddr)); 49 servaddr.sin_family = AF_INET; 50 51 52 inet_pton(AF_INET,"192.168.254.26",&(servaddr.sin_addr.s_addr)); 53 //servaddr.sin_addr.s_addr = htonl(INADDR_ANY); 54 servaddr.sin_port = htons(SERV_PORT); 55 56 57 bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr)); 58 59 60 listen(listenfd, 20); 61 62 63 printf("Accepting connections ...\n"); 64 while (1) 65 { 66 cliaddr_len = sizeof(cliaddr); 67 int connfd = accept(listenfd, 68 (struct sockaddr *)&cliaddr, &cliaddr_len); 69 70 71 //while(1) 72 { 73 n = recv(connfd, buf, MAXLINE,0); 74 if (n == 0) 75 { 76 //對端主動關閉 77 printf("the other side has been closed.\n"); 78 //break; 79 } 80 printf("received from %s at PORT %d len = %d\n", 81 inet_ntop(AF_INET, &cliaddr.sin_addr, str, sizeof(str)), 82 ntohs(cliaddr.sin_port),n); 83 } 84 //測試:模擬CLOSE_WAIT狀態時，將close(connfd);這句代碼註釋 85 86 //close(connfd); 87 } 88 89 90 return 0; 91 }
測試代碼中，當recv的返回值為0時（對端主動關閉連接），會跳出while(1)循環，此時正確做法是調用close關閉tcp連接
此處我們為了測試，故意將close(connfd)這句代碼註釋掉，註釋後服務器對於客戶端發送的FIN包不會做回應，一直保持close_wait狀態。
運行截圖：
如果將大量CLOSE_WAIT的解決辦法總結為一句話那就是：查代碼。因為問題出在服務器程序中。
------------------分割線----------------------
轉自：https://blog.51cto.com/jin771998569/1688253
一、“多半是程序的原因”？這個還是交給程序猿吧
二、linux 下 CLOSE_WAIT過多的解決方法
情景描述：系統產生大量“Too many open files”
原因分析：在服務器與客戶端通信過程中，因服務器發生了socket未關導致的closed_wait發生，致使監聽port打開的句柄數到了1024個，且均處於close_wait的狀態，最終造成配置的port被占滿出現“Too many open files”，無法再進行通信。
close_wait狀態出現的原因是被動關閉方未關閉socket造成。
解決辦法：有兩種措施可行
一、解決：
原因是因為調用ServerSocket類的accept()方法和Socket輸入流的read()方法時會引起線程阻塞，所以應該用setSoTimeout()方法設置超時（缺省的設置是0，即超時永遠不會發生）；超時的判斷是累計式的，一次設置後，每次調用引起的阻塞時間都從該值中扣除，直至另一次超時設置或有超時異常拋出。
比如，某種服務需要三次調用read()，超時設置為1分鐘，那麽如果某次服務三次read()調用的總時間超過1分鐘就會有異常拋出，如果要在同一個Socket上反復進行這種服務，就要在每次服務之前設置一次超時。
二、規避：
調整系統參數，包括句柄相關參數和TCP/IP的參數；
註意：
/proc/sys/fs/file-max 是整個系統可以打開的文件數的限制，由sysctl.conf控制；
ulimit修改的是當前shell和它的子進程可以打開的文件數的限制，由limits.conf控制；
lsof是列出系統所占用的資源,但是這些資源不一定會占用打開文件號的；比如：共享內存,信號量,消息隊列,內存映射等,雖然占用了這些資源,但不占用打開文件號；
因此，需要調整的是當前用戶的子進程打開的文件數的限制，即limits.conf文件的配置；
如果cat /proc/sys/fs/file-max值為65536或甚至更大，不需要修改該值；
若ulimit -a ；其open files參數的值小於4096（默認是1024), 則采用如下方法修改open files參數值為8192；方法如下：
1.使用root登陸，修改文件/etc/security/limits.conf
vim /etc/security/limits.conf添加
xxx - nofile 8192
xxx 是一個用戶，如果是想所有用戶生效的話換成 * ，設置的數值與硬件配置有關，別設置太大了。
#<domain> <type> <item> <value>
* soft nofile 8192
* hard nofile 8192#所有的用戶每個進程可以使用8192個文件描述符。
2.使這些限制生效
確定文件/etc/pam.d/login 和/etc/pam.d/sshd包含如下行：
session required pam_limits.so
然後用戶重新登陸一下即可生效。
3. 在bash下可以使用ulimit -a 參看是否已經修改：
一、 修改方法：（暫時生效,重新啟動服務器後,會還原成默認值）
sysctl -w net.ipv4.tcp_keepalive_time=600
sysctl -w net.ipv4.tcp_keepalive_probes=2
sysctl -w net.ipv4.tcp_keepalive_intvl=2註意：Linux的內核參數調整的是否合理要註意觀察，看業務高峰時候效果如何。
二、 若做如上修改後，可起作用；則做如下修改以便永久生效。
vi /etc/sysctl.conf
若配置文件中不存在如下信息，則添加：
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_keepalive_intvl = 15編輯完 /etc/sysctl.conf,要重啟network 才會生效
/etc/rc.d/init.d/network restart
然後，執行sysctl命令使修改生效，基本上就算完成了。
------------------------------------------------------------
修改原因：
當客戶端因為某種原因先於服務端發出了FIN信號，就會導致服務端被動關閉，若服務端不主動關閉socket發FIN給Client，此時服務端Socket會處於CLOSE_WAIT狀態（而不是LAST_ACK狀態）。通常來說，一個CLOSE_WAIT會維持至少2個小時的時間（系統默認超時時間的是7200秒，也就是2小時）。如果服務端程序因某個原因導致系統造成一堆CLOSE_WAIT消耗資源，那麽通常是等不到釋放那一刻，系統就已崩潰。因此，解決這個問題的方法還可以通過修改TCP/IP的參數來縮短這個時間，於是修改tcp_keepalive_*系列參數：
tcp_keepalive_time：
/proc/sys/net/ipv4/tcp_keepalive_time
INTEGER，默認值是7200(2小時)
當keepalive打開的情況下，TCP發送keepalive消息的頻率。建議修改值為1800秒。
tcp_keepalive_probes：INTEGER
/proc/sys/net/ipv4/tcp_keepalive_probes
INTEGER，默認值是9
TCP發送keepalive探測以確定該連接已經斷開的次數。(註意:保持連接僅在SO_KEEPALIVE套接字選項被打開是才發送.次數默認不需要修改,當然根據情形也可以適當地縮短此值.設置為5比較合適)
tcp_keepalive_intvl：INTEGER
/proc/sys/net/ipv4/tcp_keepalive_intvl
INTEGER，默認值為75
當探測沒有確認時，重新發送探測的頻度。探測消息發送的頻率（在認定連接失效之前，發送多少個TCP的keepalive探測包）。乘以tcp_keepalive_probes就得到對於從開始探測以來沒有響應的連接殺除的時間。默認值為75秒，也就是沒有活動的連接將在大約11分鐘以後將被丟棄。(對於普通應用來說,這個值有一些偏大,可以根據需要改小.特別是web類服務器需要改小該值,15是個比較合適的值)。
1. 系統不再出現“Too many open files”報錯現象。
2. 處於TIME_WAIT狀態的sockets不會激長。
在 Linux 上可用以下語句看了一下服務器的TCP狀態(連接狀態數量統計)：
netstat -n| awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}‘
關於TCP中的keepalive機制，參考博客：
https://www.cnblogs.com/lidabo/p/3804108.html
http://www.importnew.com/27624.html
等有時間需要做一下整理。
【網絡編程】服務端產生大量的close_wait狀態的進程分析