笔者一直以为在Linux下TIME_WAIT状态的Socket持续状态是60s左右。线上实际却存在TIME_WAIT超过100s的Socket。由于这牵涉到最近出现的一个复杂Bug的分析。所以,笔者就去Linux源码里面,一探究竟。
1. 抓取perf信息并结合代码分析热点主要在处理timewait socket上:
转载自: http://blog.sina.com.cn/s/blog_781b0c850100znjd.html
图中可以看到:主动关闭方将进入TIME_WAIT状态;被动关闭方将进入CLOSE_WAIT状态。
使用wrk模拟http压力打nginx时,发现压测过程中持续出现重传现象,而且在高压下和低压下都会出现不同程度的重传。
早上毕玄转给我一个问题,vsearch在上海机房部署的应用,在应用关闭后,端口释放的时间要比杭州机房的时间长。
在TCP断开连接四次挥手时, 主动发起关闭方会产生 TIME_WAIT, TIME_WAIT 是 TCP 协议可靠性设计的重要一个环节, 虽说增强了可靠性, 但是对于高并发场景下, 会产生大量的 TIME_WAIT, 导致高峰时段无端口可以使用.
本文为翻译英文BLOG《Coping with the TCP TIME-WAIT state on busy Linux servers》,但并非完整的翻译,译者CFC4N对原文理解后,进行了调整,增加了相关论点论据,跟原文稍有不同。翻译的目的,是为了加深自己知识点的记忆,以及分享给其他朋友,或许对他们也有帮助。文章比较长,没耐心请点关闭。
数据库是基于操作系统的,目前大多数MySQL都是安装在linux系统之上,所以对于操作系统的一些参数配置也会影响到MySQL的性能,下面就列出一些常用的系统配置。
今天简单的谈一下tcp连接中timewait的作用,如果没有timewait会发生什么呢?
Socket 在英文中的含义为“(连接两个物品的)凹槽”,像the eye socket,意为“眼窝”,此外还有“插座”的意思。在计算机科学中,socket 通常是指一个连接的两个端点,这里的连接可以是同一机器上的,像unix domain socket,也可以是不同机器上的,像network socket。
笔者最近解决了一个非常曲折的问题,从抓包开始一路排查到不同内核版本间的细微差异,最后才完美解释了所有的现象。在这里将整个过程写成博文记录下来,希望能够对读者有所帮助。(篇幅可能会有点长,耐心看完,绝对物有所值~)
传输控制协议(TCP,Transmission Control Protocol)是一种面向连接的、可靠的、基于字节流的传输层通信协议。
执行主动关闭的那端经历了这个状态,并停留MSL(最长分节生命期)的2倍,即2MSL。
这篇文章的主题是记录一次程序的性能优化,在优化的过程中遇到的问题,以及如何去解决的。
这篇文章的主题是记录一次Python程序的性能优化,在优化的过程中遇到的问题,以及如何去解决的。为大家提供一个优化的思路,首先要声明的一点是,我的方式不是唯一的,大家在性能优化之路上遇到的问题都绝对不止一个解决方案。
这篇文章的主题是记录一次 Python 程序的性能优化,在优化的过程中遇到的问题,以及如何去解决的。为大家提供一个优化的思路,首先要声明的一点是,我的方式不是唯一的,大家在性能优化之路上遇到的问题都绝对不止一个解决方案。
你想通过执行ping google.com来判断网络连通性么?我想你这是在侮辱方教授。本篇是《荒岛余生》系列第五篇,网络篇,但不会教你fq。其余参见:
上图这个服务器“优化”是不是似曾相识,网上有太多太多这样的文章,核心调优方案就是开启 tcp_timestamps 和 tcp_tw_recycle。诚然这个“调优“,确实如毒品一般让业务瞬间得到虚幻一般的高潮,但是他的危害也如毒品一般让业务一步步陷入深渊。
建议直接看参考的原版报告,这篇为我大致记录的一些配置,部分还为理解,后续进行修改补充。
timewait在tcp结束后主动关闭一方的等待时候的行为。图片中的服务和客户端描述不是非常准确,这里客户端是主动关闭一方。(在web服务器模型下,web服务器也可主动关闭客户端,这个时候web服务器就变成了四次握手的客户端)。
TIME_WAIT状态存在的理由: 1)可靠地实现TCP全双工连接的终止 在进行关闭连接四次挥手协议时,最后的ACK是由主动关闭端发出的,如果这个最终的ACK丢失,服务器将重发最终的FIN, 因此客户端必须维护状态信息允许它重发最终的ACK。如果不维持这个状态信息,那么客户端将响应RST分节,服务器将此分节解释成一个错误(在java中会抛出connection reset的SocketException)。 因而,要实现TCP全双工连接的正常终止,必须处理终止序列四个分节中任何一个分节的丢失情况,主动关闭的客户端必须维持状态信息进入TIME_WAIT状态。
提高Linux应对短连接的负载能力 在存在大量短连接的情况下,Linux的TCP栈一般都会生成大量的 TIME_WAIT 状态的socket。你可以用下面的命令看到: netstat -ant| grep -i time_wait 有时候,这个数目是惊人的: netstat -ant|grep -i time_wait |wc -l 可能会超过三四万。这个时候,我们需要修改 linux kernel 的 tcp time wait的时间,缩短之,有个 sysctl 参数貌似可以使用,它是 /proc/sy
笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码,是一件Exciting的事情。上篇博客讲了socket的阻塞和非阻塞,这篇就开始谈一谈socket的close(以tcp为例且基于linux-2.6.24内核版本)
当Linux服务器的TIME_WAIT过多时, 通常会想到去修改参数降低TIME_WAIT时长, 以减少TIME_WAIT数量,但Linux并没有提供这样的接口, 除非重新编译内核。 Linux默认的TIME_WAIT时长一般是60秒, 定义在内核的include/net/tcp.h文件中: #define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT state, * about 60 seconds */ #define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN /* BSD style FIN_WAIT2 deadlock breaker. * It used to be 3min, new value is 60sec, * to combine FIN-WAIT-2 timeout with * TIME-WAIT timer. */ 注意tcp_fin_timeout不是TIME_WAIT时间: # cat /proc/sys/net/ipv4/tcp_fin_timeout 60 tcp_fin_timeout实为FIN_WAIT_2状态的时长, Linux没有提供修改TIME_WAIT时长接口,除非修改宏的定义重新编译内核。 但Windows可以修改注册表中的TcpTimedWaitDelay值来控制TIME_WAIT时长。 RTO:超时重传(Retransmission Timeout) TIME_WAIT是一个常见经常的问题,相关内容(/etc/sysctl.conf或/proc/sys/net/ipv4): 1) net.ipv4.tcp_timestamps 为1表示开启TCP时间戳,用来计算往返时间RTT(Round-Trip Time)和防止序列号回绕 2) net.ipv4.tcp_tw_reuse 为1表示允许将TIME-WAIT的句柄重新用于新的TCP连接 3) net.ipv4.tcp_tw_recycle 为1表示开启TCP连接中TIME-WAIT的快速回收,NAT环境可能导致DROP掉SYN包(回复RST) 4) net.ipv4.tcp_fin_timeout FIN_WAIT_2状态的超时时长 5) net.ipv4.tcp_syncookies 为1时SYN Cookies,当SYN等待队列溢出时启用cookies来处理,可防范少量SYN攻击 6) net.ipv4.tcp_max_tw_buckets 保持TIME_WAIT套接字的最大个数,超过这个数字TIME_WAIT套接字将立刻被清除并打印警告信息 7) net.ipv4.ip_local_port_range 8) net.ipv4.tcp_max_syn_backlog 端口最大backlog内核限制,防止占用过大内核内存 9) net.ipv4.tcp_syn_retries 对一个新建连接,内核要发送多少个SYN连接请求才决定放弃,不应该大于255 10) net.ipv4.tcp_retries1 放弃回应一个TCP连接请求前﹐需要进行多少次重试,RFC规定最低的数值是3,这也是默认值 11) net.ipv4.tcp_retries2 在丢弃激活(已建立通讯状况)的TCP连接之前﹐需要进行多少次重试,默认值为15 12) net.ipv4.tcp_synack_retries TCP三次握手的SYN/ACK阶段重试次数,缺省5 13) net.ipv4.tcp_max_orphans 不属于任何进程(已经从进程上下文中删除)的sockets最大个数,超过这个值会被立即RESET,并同时显示警告信息 14) net.ipv4.tcp_orphan_retries 孤儿sockets废弃前重试的次数,缺省值是7 15) net.ipv4.tcp_mem 内核分配给TCP连接的内存,单位是page: 第一个数字表示TCP使用的page少于此值时,内核不进行任何处理(干预), 第二个数字表示TCP使用的page超过此值时,内核进入“memory pressure”压力模式, 第三个数字表示TCP使用的page超过些值时,报“Out of socket memory”错误,TCP 连接将被拒绝 16) net.ipv4.tcp_rmem 为每个TCP连接分配的读缓冲区内存大小,单位是byte 17) net.ipv4.tcp_wmem 为每个TCP
注: 此系列内容来自网络,未能查到原作者。感觉不错,在此分享。不排除有错误,可留言指正。
腾讯云服务器监控 agent 只采集了处于 ESTABLISHED 状态的 TCP 连接数量?
带宽问题是性能分析中常见的问题之一,其难点就在于,带宽不像 CPU 使用率那么清晰可理解,它和 TCP/IP 协议的很多细节有关,像三次握手,四次挥手,队列长度,网络抖动、丢包、延时等等,都会影响性能,关键是这些判断点还不在同一个界面中,所以需要做分析的人有非常明确的分析思路才可以做得到。而且现在的监控分析工具中,对网络的判断也是非常薄弱的。
常用的三个状态是:ESTABLISHED 表示正在通信,TIMEWAIT 表示主动关闭,CLOSEWAIT 表示被动关闭。关于closewait和timewait,tcp中的交互图:
loadrunner几尽为国内测试人员的专用压测工具,他的高度灵活性,数据分析功能,图表展示,用户行为模拟等功能非常强大,专业压测还是以loadrunner为准
由于nio的普及,ck10k的问题已经成为过去式。现在随便一台服务器,就可以支持数十万级别的连接了。那么我们来算一下,100万的连接需要多少资源。
运维如果想做自动化高效化,则少不了搭建监控系统。目前市面上已经有大量成熟、开源的监控平台可供挑选。但如果想实现一个监控系统,或了解监控系统的原理,则可参见本文。
在当今数字化时代,互联网已经成为了人们生活中不可或缺的一部分。而在互联网的基础之上,TCP协议扮演着关键的角色,它负责着数据在网络中的可靠传输。在TCP连接的建立过程中,我们已经了解了三次握手的过程和原理。然而,连接的建立只是TCP协议的一部分,同样重要的是连接的断开过程。本文将重点探讨TCP连接的断开过程,包括四次挥手的过程和状态变迁,以及为什么挥手需要四次和为什么需要TIME_WAIT状态。通过深入理解TCP连接断开的过程,我们可以更好地理解网络通信的原理
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/135798.html原文链接:https://javaforall.cn
本来是在研究epoll的另一个问题的,结果发现这个问题,所以这篇文章就先写这个问题吧。
接上一篇文章 Linux系统研究 - 操作系统是如何管理tcp连接的 (1),我们再来继续讲。
其实也可以用下面查看相关信息,这里已经是修改后的值了所以看到timewait值下降了。
在《网络编程-从TCP连接的建立说起》中介绍了TCP的三次握手以及一些常见问题,那么四次挥手又有哪些需要特别关注的问题?四次挥手你真的懂了吗?
ss 命令用来显示处于活动状态的套接字信息。ss 命令可以用来获取 socket 统计信息,它可以显示和 netstat 类似的内容。但ss的优势在于它能够显示更多更详细的有关 TCP 和连接状态的信息,而且比 netstat 更快速更高效。
看到一个有意思的case,运行超过497天的2008R2系统,timewait状态的端口不能释放,业务不断请求导致timewait状态的端口越来越多,最终可能端口耗尽,网络中断
①中断源发出中断请求; ②判断当前处理机是否允许中断和该中断源是否被屏蔽; ③优先权排队; ④处理机执行完当前指令或当前指令无法执行完,则立即停止当前程序,保护断点地址和处理机当前状态,转入相应的中断服务程序; ⑤执行中断服务程序; ⑥恢复被保护的状态,执行“中断返回”指令回到被中断的程序或转入其他程序。 上述过程中前四项操作是由硬件完成的,后两项是由软件完成的。
TCP 是传输层的协议,全称是叫做 Transmission Control Protocol,这个协议在 IETF RFC 793 进行了定义。 在互联网产生之前,我们的电脑都是相互独立的,每台机器都有着自己的操作系统并保持着自己的运行。 于是,为了将这些电脑连接起来,并能够基于一种"通道"的形式进行数据、资源的传输及交互,IETF 制定了 TCP 协议。
在 Linux 系统中,常见的动态追踪方法包括 ftrace、perf、eBPF/BCC 以及 SystemTap 等。
这篇文章,主要是整理一下 TCP 的一些知识要点,作为一名开发者来说,尽管有那么多的基础设施(框架、组件)帮我们屏蔽了这些细节。当我仍然认为了解它的一些基本原理必有些裨益,尤其是当你在分布式环境上遇到一些棘手问题时,一些原理性的知识可能会让你快速找到答案。
nginx作为最优秀的web服务器之一,以轻量级,高并发而著称,用户遍及全球各地。下面来讲述一下nginx常规的一些优化。仅供参考! 并发数调整 谈到web服务器,并发是一个无法规避的问题。那我们来看一下nginx的并发数是如何设置的。 nginx并发数调整,主要有取决于worker_processes和worker_connections参数,下面介绍关于ngnix性能优化全局设置的相关参数。 worker_processes:指定nginx开启的进程数,默认是1。每个进程消耗约12M左右的内存。进程数
我们知道 TCP 在关闭连接的时候,主动断开的一方将处于 TIME_WAIT 状态,并将持续两倍的 MSL。这个 MSL 在 RFC 793 中的建议是 1 分钟,但是很多系统实现都是 30 秒,所以 TIME_WAIT 的时长也就是 1 分钟。这个参数实在内核中设置的,如果想修改需要重新编译内核参数,查看可以使用ss 来查看 TIME_WAIT 的剩余存活时长(netstat 也可以 -o 参数)
领取专属 10元无门槛券
手把手带您无忧上云