服务器出现大量listen状态进程,【网络编程】服务端产生大量的close_wait状态的进程分析...

最新推荐文章于 2022-12-23 14:17:53 发布

安尼迪

最新推荐文章于 2022-12-23 14:17:53 发布

阅读量463

点赞数

文章标签：服务器出现大量listen状态进程

首先要明白close_wait状态是在tcp通信四次握手时的一个中间状态：

即当被动关闭方发送完ACK后进入的状态。这个状态的结束，即要达到下一个状态LASK_ACK需要在发无端发送完剩余的数据后(send)、调用close函数之后。

下面我们模拟这种情况，即服务端发送完剩余的数据后，并没有调用close函数：

client端代码：

1 #include

2 #include

3 #include

4 #include

5 #include

6 #include

7 #include

10 #define MAXLINE 80

11 #define SERV_PORT 8000

14 int main(int argc, char *argv[])15 {16 structsockaddr_in servaddr;17 char str[MAXLINE] = "test";18 intsockfd, n;19

21 while(1)22 {23 sockfd = socket(AF_INET, SOCK_STREAM, 0);24

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

32 connect(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr));33 write(sockfd, str, strlen(str));34

36 close(sockfd);37 sleep(2);38 }39

41 return 0;42 }

server端代码：

1 #include

2 #include

3 #include

4 #include

7 #include

8 #include /*For mode constants*/

9 #include /*For O_* constants*/

12 #include

13 #include

16 using namespacestd;17

19 #define LENGTH 128

20 #include "netinet/in.h"

21 #define MAXLINE 80

22 #define SERV_PORT 8000

25 int main(int argc,char**argv)26 {27 structsockaddr_in servaddr, cliaddr;28 socklen_t cliaddr_len;29 intlistenfd;30 charbuf[MAXLINE];31 charstr[INET_ADDRSTRLEN];32 //int i, n;

33 intn;34

36 //创建socket

37 listenfd = socket(AF_INET, SOCK_STREAM, 0);38

40 //设置端口重用

41 int opt = 1;42 setsockopt(listenfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));43

45 //fcntl(sockfd, F_SETFL, fcntl(sockfd, F_GETFL, 0) | O_NONBLOCK);

48 bzero(&servaddr, sizeof(servaddr));49 servaddr.sin_family =AF_INET;50

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

57 bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr));58

60 listen(listenfd, 20);61

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

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);这句代码注释

86 //close(connfd);87 }88

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 是一个用户，如果是想所有用户生效的话换成 * ，设置的数值与硬件配置有关，别设置太大了。

* 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

等有时间需要做一下整理。

原文：https://www.cnblogs.com/xuelisheng/p/10611039.html

安尼迪

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
服务器出现大量listen状态进程,【网络编程】服务端产生大量的close_wait状态的进程分析...

首先要明白close_wait状态是在tcp通信四次握手时的一个中间状态：即当被动关闭方发送完ACK后进入的状态。这个状态的结束，即要达到下一个状态LASK_ACK需要在发无端发送完剩余的数据后(send)、调用close函数之后。下面我们模拟这种情况，即服务端发送完剩余的数据后，并没有调用close函数：client端代码：1 #include 2 #include 3 #include 4 #...
复制链接

扫一扫