关于线上环境CLOSE_WAIT和TIME_WAIT过高
来源:互联网 发布:苹果怎么装windows系统 编辑:程序博客网 时间:2024/06/10 03:42
转自:http://www.cnblogs.com/Bozh/p/3752476.html
运维的同学和Team里面的一个同学分别遇到过Nginx在线上环境使用中会遇到TIME_WAIT过高或者CLOSE_WAIT过高的状态
先从原因分析一下为什么,问题就迎刃而解了。
首先是TIME_WAIT:
理解一下TIME_WAIT状态产生的原因,这个问题已经被很多很多的书说烂了,但是为什么很多人还是不能解决,究其原因还是因为
大多数都是学术派,并没有真正的遇到过这样的问题,因为TIME_WAIT大量产生很多都发生在实际应用环境中。
TIME_WAIT产生的原因还是因为在通讯过程中服务端主动关闭造成的,在服务端发送了最后一个FIN包后,系统会等待 Double时间
的MSL(Max Segment Lifetime)用于等待接受客户端发送过来的FIN_ACK和FIN,这段时间服务端的对应的socket的fd是不能够重新
利用的,这样在大量的短连接服务中,会出现TIME_WAIT过多的现象。
解决方案:
调整TIME_WAIT超时时间
vi /etc/sysctl.conf
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 = 20
其次是CLOSE_WAIT:
CLOSE_WAIT产生的原因是客户端主动关闭,收到FIN包,应用层却没有做出关闭操作引起的。
CLOSE_WAIT在Nginx上面的产生原因还是因为Nagle's算法加Nginx本身EPOLL的ET触发模式导致。
ET出发模式在数据就绪的时候会触发一次回调操作,Nagle's算法会累积TCP包,如果最后的数据包和
FIN包被Nagle's算法合并,会导致EPOLL的ET模式只出发一次,然而在应用层的SOCKET是读取返回
0才代表链接关闭,而读取这次合并的数据包时是不返回0的,然后SOCKET以后都不会触发事件,所以
导致应用层没有关闭SOCKET,从而产生大量的CLOSE_WAIT状态链接。
关闭TCP_NODELAY,在Nginx配置中加上
tcp_nodelay on;
- 关于线上环境CLOSE_WAIT和TIME_WAIT过高
- 应用环境下的TIME_WAIT和CLOSE_WAIT
- 应用环境下的TIME_WAIT和CLOSE_WAIT
- 应用环境下的TIME_WAIT和CLOSE_WAIT
- 应用环境下的TIME_WAIT和CLOSE_WAIT
- CLOSE_WAIT和TIME_WAIT
- CLOSE_WAIT和TIME_WAIT
- CLOSE_WAIT和TIME_WAIT处理
- time_wait和close_wait
- TIME_WAIT和CLOSE_WAIT(转)
- time_wait和close_wait
- time_wait和close_wait状态
- 服务器 TIME_WAIT和CLOSE_WAIT
- TIME_WAIT和CLOSE_WAIT
- TIME_WAIT和CLOSE_WAIT
- TIME_WAIT和CLOSE_WAIT
- TIME_WAIT和CLOSE_WAIT
- 再谈应用环境下的TIME_WAIT和CLOSE_WAIT
- struts2中action的配置
- 采集 天创恒达高清采集卡TC-5A0N7
- 双向链表
- Clang
- HDU 5266 pog loves szh III (线段树+LCA)
- 关于线上环境CLOSE_WAIT和TIME_WAIT过高
- 学习JPA——Hibernate Annotation使用实例
- 关于Go语言共享内存操作的小实例
- 开源中国代码分享系列--启动界面
- [java设计模式]之单例模式
- 动态设置布局LayoutInflater
- ClassLoader加载指定的类需注意六个细节或报ClassNotFundEception异常总结
- 文件操作:洗牌/统计文本文件单词/复制mp3文件/多个文件合并成一个文件
- 了解JSONP