netstat监控大量ESTABLISHED连接与Time_Wait连接问题

问题描述:

在不考虑系统负载、CPU、内存等情况下,netstat监控大量ESTABLISHED连接与Time_Wait连接。

# netstat -n | awk ‘/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}‘
CLOSE_WAIT         348
ESTABLISHED        1240
TIME_WAIT          5621

监控Apache与tomcat之间的链接端口

#netstat -n | grep 8009 | wc -l

7198 

问题1:怎么解决大量Time_Wait

通过调整内核参数:

vim /etc/sysctl.conf
#编辑文件,加入以下内容:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
#然后执行 /sbin/sysctl -p 让参数生效。

配置说明:

net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;

net.ipv4.tcp_tw_reuse = 1    表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;

net.ipv4.tcp_tw_recycle = 1  表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭;

net.ipv4.tcp_fin_timeout=30修改系統默认的 TIMEOUT 时间。

如果以上配置调优后性能还不理想,可继续修改一下配置:

vi /etc/sysctl.conf
net.ipv4.tcp_keepalive_time = 1200
#表示当keepalive起用的时候,TCP发送keepalive消息的频度。缺省是2小时,改为20分钟。
net.ipv4.ip_local_port_range = 1024 65000
#表示用于向外连接的端口范围。缺省情况下很小:32768到61000,改为1024到65000。
net.ipv4.tcp_max_syn_backlog = 8192
#表示SYN队列的长度,默认为1024,加大队列长度为8192,可以容纳更多等待连接的网络连接数。
net.ipv4.tcp_max_tw_buckets = 5000
#表示系统同时保持TIME_WAIT套接字的最大数量,如果超过这个数字,TIME_WAIT套接字将立刻被清除并打印警告信息。
默认为180000,改为5000。对于Apache、Nginx等服务器,上几行的参数可以很好地减少TIME_WAIT套接字数量,但是对于 Squid,效果却不大。此项参数可以控制TIME_WAIT套接字的最大数量,避免Squid服务器被大量的TIME_WAIT套接字拖死。

调优完毕,再压一下看看效果吧。

# netstat -n | awk ‘/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}‘

ESTABLISHED        968

问题1:怎么解决请求结束后依然存在大量ESTABLISHED没有被释放

初步推断是tomcat服务器回收session时出了问题,这个一般都跟服务器的Timeout设置有联系。

查看tomcat的配置文件 server.xml

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8" />*****

检查配置得出20000毫秒的时候acceptCount=”100” ,明显不合理,最大连接数也太小了吧。

所以进一步优化:

connectionTimeout="20000" 改为 connectionTimeout="100"

acceptCount="100"改为acceptCount="5000"

优化完毕,继续压测...

系统响应能力节节攀升,之前LoadRunner报错问题直到压倒***并发也再也没有出现。

Action.c(380): 错误 -26608: 对于“http://www.cnlogs.com/javame”,HTTP 状态代码=504 (Gateway Time-out)

总结:

待定,以后再写!

时间: 2024-11-17 23:15:56

netstat监控大量ESTABLISHED连接与Time_Wait连接问题的相关文章

netstat监控大量ESTABLISHED连接数和TIME_WAIT连接数题解决

查看网络连接数: netstat -an |wc -l netstat -an |grep xx |wc -l        查看某个/特定ip的连接数 netstat -an |grep TIME_WAIT|wc -l    查看连接数等待time_wait状态连接数 netstat -an |grep ESTABLISHED |wc -l    查看建立稳定连接数量 查看不同状态的连接数数量 [[email protected] ~]# netstat -an | awk '/^tcp/ {

服务器性能调优(netstat监控大量ESTABLISHED连接与Time_Wait连接问题)

netstat监控大量ESTABLISHED连接与Time_Wait连接问题 问题描述: 在不考虑系统负载.CPU.内存等情况下,netstat监控大量ESTABLISHED连接与Time_Wait连接. # netstat -n | awk '/^tcp/ {++y[$NF]} END {for(w in y) print w, y[w]}' CLOSE_WAIT 348 ESTABLISHED 1240 TIME_WAIT 5621 监控Apache与tomcat之间的链接端口 #netst

【我的Linux,我做主!】实战--使用netstat监控网络连接信息

目录:(一)netstat简介(二)netstat语法指南(三)实战演练(四)netstat小结 (一)netstat简介(1.1)在Internet的RFC标准中,netstat的定义是:netstat是在内核中访问网络连接状态及相关信息的程序,它能提供TCP连接.在TCP和UDP监听.进程内存管理的相关报告.netstat是控制台命令,是一个监控TCP/IP网络的非常有用的工具,它可以显示路由表.实际的网络连接以及每一个网络接口设备的状态信息.netstat用于显示IP.TCP.UDP和IC

TIME_WAIT连接过多解决办法

问题起因: 自己开发了一个服务器和客户端,通过短连接的方式来进行通讯,由于过于频繁的创建连接,导致系统连接数量被占用,不能及时释放.看了一下18888,当时吓到了. 现象: 1.外部机器不能正常连接SSH 2.内向外不能够正常的ping通过,域名也不能正常解析. 问题排查: 通过 netstat  -anp | grep TIME_WAIT | wc -l 命令查看数量,发现TIME_WAIT的连接数量超过了18000太夸张了. 1.初步怀疑是程序没有关闭连接,codereview了两遍,发现,

TCP连接的TIME_WAIT过多导致 Tomcat 假死

最近发现使用的Tomcat 7会经常假死.前端点击页面无任何反应,打开firebug,很多链接一直在等待服务器的反应.查看服务器的状态,CPU占用很少,最多不超过10%,一般只有2%,3%左右,内存占用倒是接近80, 90%.一开始怀疑是tomcat内存配置不够,但是打开 jvisualvm.exe 分析,发现Tomcat 占用的堆内存没有什么问题.因为是假死,所以最后怀疑到 tomcat的 链接数和 数据库的链接数的配置估计太小了.netstat -na 结果页显示很多time_wait. 查

减少TIME_WAIT连接状态

减少TIME_WAIT连接状态.网络上已经有不少相关的介绍,大多是建议: shell> sysctl net.ipv4.tcp_tw_reuse=1 shell> sysctl net.ipv4.tcp_tw_recycle=1 注:通过sysctl命令修改内核参数,重启后会还原,要想持久化可以参考前面的方法. 这两个选项在降低TIME_WAIT数量方面可以说是立竿见影,不过如果你觉得问题已经完美搞定那就错了,实际上这样可能会引入一个更复杂的网络故障. 关于内核参数的详细介绍,可以参考官方文档

nginx+php产生大量TIME_WAIT连接解决办法

问题:当启动nginx和php-fpm时,使用netstat -tunap查看到大量TIME_WAIT连接 由于不知道原因,害怕是受到攻击,马上killall nginx 和php-fpm 会不会是80端口被攻击造成的?尝试修改nginx的80端口为8081,但结果同样是产生大量TIME_WAIT连接 无法知道问题,百度寻找办法 参考链接:http://www.heminjie.com/wordpress/3322.html 还没有解决 到晚上回到家自己重新测试才有所改善,并发现了某些问题 ne

[总结]数据库连接池设置不当导致大量的本地连接出现time_wait状态。

最近在做性能测试时,在使用netstat命令查看本地网络连接状态时发现有大量的连接处于time_wait状态. 于是认为是我们的dbcp的配置文件写的有问题,开始查应如何配置dbcp.但是改了几个参数后,发现还是出现大量的time_wait. 于是又开始查看官方的配置说明,还是我们老大认真犀利,发现了这段: If maxIdle is set too low on heavily loaded systems it is possible you will see connections bei

TCP/IP详解--TCP连接中TIME_WAIT状态过多

转载自http://blog.csdn.net/yusiguyuan/article/details/21445883 TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的.仅仅是主动关闭的一方,在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候会出现这个TIMEWAIT.服务器在处理客户端请求的时候,如果你的程序设计为服务器主动关闭,那么你才有可能需要关注这个TIMEWAIT状态过多的问题.如果你的服务器设计为被动关闭,那么你首先要关注的是CLOSE_WAIT. 原则