Socket是应用层与TCP/IP协议族通信的中间软件抽象层,它是一组接口。在设计模式中,Socket其实就是一个门面模式,它把复杂的TCP/IP协议族隐藏在Socket接口后面,对用户来说,一组简单的接口就是全部,让Socket去组织数据,以符合指定的协议。
主机 A 的应用程序要能和主机 B 的应用程序通信,必须通过 Socket 建立连接,而建立 Socket 连接必须需要底层 TCP/IP 协议来建立 TCP 连接。建立 TCP 连接需要底层 IP 协议来寻址网络中的主机。我们知道网络层使用的 IP 协议可以帮助我们根据 IP 地址来找到目标主机,但是一台主机上可能运行着多个应用程序,如何才能与指定的应用程序通信就要通过 TCP 或 UPD 的地址也就是端口号来指定。这样就可以通过一个 Socket 实例唯一代表一个主机上的一个应用程序的通信链路了。
//////////////////////////////////////////////////////////////////////////////////////////////////////////(转发)
方法一:利用netstat命令
统计 TIME_WAIT/CLOSE_WAIT/ESTABLISHED/LISTEN 等TCP状态的连接数
netstat -tan |grep ^tcp |awk '{++a[$6]} END{for (i in a) print i, a[i]}'
方法二:利用ss命令
Total: 541 (kernel 0)
TCP: 77 (estab 27, closed 45, orphaned 0, synrecv 0, timewait 45/0), ports 0
Transport Total IP IPv6
* 0 - -
RAW 0 0 0
UDP 8 5 3
TCP 32 31 1
INET 40 36 4
FRAG 0 0 0
TCP连接状态回顾
- CLOSED:初始状态,表示没有任何连接。
- LISTEN:Server端的某个Socket正在监听来自远方的TCP端口的连接请求。
- SYN_SENT:发送连接请求后等待确认信息。当客户端Socket进行Connect连接时,会首先发送SYN包,随即进入SYN_SENT状态,然后等待Server端发送三次握手中的第2个包。
- SYN_RECEIVED:收到一个连接请求后回送确认信息和对等的连接请求,然后等待确认信息。通常是建立TCP连接的三次握手过程中的一个中间状态,表示Server端的Socket接收到来自Client的SYN包,并作出回应。
- ESTABLISHED:表示连接已经建立,可以进行数据传输。
- FIN_WAIT_1:主动关闭连接的一方等待对方返回ACK包。若Socket在ESTABLISHED状态下主动关闭连接并向对方发送FIN包(表示己方不再有数据需要发送),则进入FIN_WAIT_1状态,等待对方返回ACK包,此后还能读取数据,但不能发送数据。在正常情况下,无论对方处于何种状态,都应该马上返回ACK包,所以FIN_WAIT_1状态一般很难见到。
- FIN_WAIT_2:主动关闭连接的一方收到对方返回的ACK包后,等待对方发送FIN包。处于FIN_WAIT_1状态下的Socket收到了对方返回的ACK包后,便进入FIN_WAIT_2状态。由于FIN_WAIT_2状态下的Socket需要等待对方发送的FIN包,所有常常可以看到。若在FIN_WAIT_1状态下收到对方发送的同时带有FIN和ACK的包时,则直接进入TIME_WAIT状态,无须经过FIN_WAIT_2状态。
- TIME_WAIT:主动关闭连接的一方收到对方发送的FIN包后返回ACK包(表示对方也不再有数据需要发送,此后不能再读取或发送数据),然后等待足够长的时间(2MSL)以确保对方接收到ACK包(考虑到丢失ACK包的可能和迷路重复数据包的影响),最后回到CLOSED状态,释放网络资源。
- CLOSE_WAIT:表示被动关闭连接的一方在等待关闭连接。当收到对方发送的FIN包后(表示对方不再有数据需要发送),相应的返回ACK包,然后进入CLOSE_WAIT状态。在该状态下,若己方还有数据未发送,则可以继续向对方进行发送,但不能再读取数据,直到数据发送完毕。
- LAST_ACK:被动关闭连接的一方在CLOSE_WAIT状态下完成数据的发送后便可向对方发送FIN包(表示己方不再有数据需要发送),然后等待对方返回ACK包。收到ACK包后便回到CLOSED状态,释放网络资源。
- CLOSING:比较罕见的例外状态。正常情况下,发送FIN包后应该先收到(或同时收到)对方的ACK包,再收到对方的FIN包,而CLOSING状态表示发送FIN包后并没有收到对方的ACK包,却已收到了对方的FIN包。有两种情况可能导致这种状态:其一,如果双方几乎在同时关闭连接,那么就可能出现双方同时发送FIN包的情况;其二,如果ACK包丢失而对方的FIN包很快发出,也会出现FIN先于ACK到达。
状态变化图如下:
![高并发下的oom killer_第1张图片](http://img.e-com-net.com/image/info8/b63e138b32b841d9bd181de13cfbf5b1.jpg)
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////(转发https://blog.csdn.net/u010954257/article/details/54178160)
最近在做一个大并发服务的测试(目前测到86万,当然有大量长连接,每天打的日志高到170多g,不打算继续测了),业务系统为反向代理ATS,服务的内容为动态域名,大部分的url很长,不过打开后的值只是0或1这样的标记。
当服务器在几万并发时,一般不需要考虑TCP连接消耗内存的问题,但当服务器承载几十万并发时,会暴漏出各种的问题,因此不得不考虑TCP连接对内存资源的消耗,当然跑到86万的并发需要对业务系统、Centos做各种参数优化,牵涉面太多,今天只说TCP内存占用(由于线上系统干扰条件很多,无法特定的对某个参数去调试,只分享一下做过程的心得,抛砖引玉),出现的问题如下:
![QQ截图20160319085753.png 高并发下的oom killer_第2张图片](http://img.e-com-net.com/image/info8/16383e39f3eb4463bf82963d9be9e1b9.gif)
(内存不够用,kernel直接把ats的进程给杀掉了,然后out of socket memory)
![QQ截图20160316161212.png 高并发下的oom killer_第3张图片](http://img.e-com-net.com/image/info8/6d3fb0a6533f490d85f24da2a125b624.gif)
(跑着跑着,直接out of socket memory)
![QQ截图20160322094706.png 高并发下的oom killer_第4张图片](http://img.e-com-net.com/image/info8/48a520787bfb46d8b370e03450fecc3b.gif)
(tsar的内存监控数据)
每一个TCP连接都会有对应的socket封装,而每个socket都要占用一个fd,现在的业务系统大都采用epoll的网络I/O模型,他可以高效的处理大批量socket句柄,而这个socket句柄的对应的TCP读写缓存再加上一个TCP控制块就是单个TCP连接所消耗的内存,当然这个读写缓存的大小是根据系统的需要动态变化的,和TCP的滑动窗口大小成正相关。
对于tcp能够使用多少缓存,centos是会有全局控制的,例如我线上的服务器(内存62G,有15个G做内存cache使用)。
TCP能够使用的内存:这三个值就是TCP使用内存的大小,单位是页,每个页是4K的大小,如下:
![132.png wKioL1brz0PycydHAAAJQKtWQW0638.png](http://img.e-com-net.com/image/info8/12a08c68996d4b01b02cc36f7a853408.png)
这三个值分别代表
Low:6179424 (6179424*4/1024/1024大概23g)
Pressure:8239232 (8239232*4/1024/1024大概31g)
High:12358848 (echo 12358848*4/1024/1024大概47g)
这个也是系统装后的默认取值,也就是说最大有47个g(75%的内存)可以用作TCP连接,这三个量也同时代表了三个阀值,TCP的使用小于第二个值时kernel不会有任何提示操作,当大于第二个值时进入压力模式,当高于第三个值时将不接受新的TCP连接,同时会报出“Out of socket memory”或者“TCP:too many of orphaned sockets”。
TCP读缓存大小,单位是字节:第一个是最小值4K,第二个是默认值85K,第三个是最大值16M,如下:
![456.png wKioL1brz-vA-pohAAAJ6zc3ROE318.png](http://img.e-com-net.com/image/info8/5ea7030967f3487fb061bd762b5594d4.png)
这个可以在sysctl.conf中net.ipv4.tcp_rmem中进行调整。
TCP写缓存大小,单位是字节:第一个是最小值4K,第二个是默认值64K,第三个是最大值16M,如下:
![789.png wKioL1brz_6gQCgPAAAMO0VkVyE066.png](http://img.e-com-net.com/image/info8/a106ebc09a9b46a5968e8419526d4829.png)
这个可以在sysctl.conf中net.ipv4.tcp_wmem中进行调整。
也就是说一个TCP在三次握手建立连接后,最小的内存消耗在8K左右,最大的内存消耗在32M左右,你可以通过MTU估算MSS,然后算出一个滑动窗口有多少个MSS。现在可以进行简单计算了,按照系统TCP的全局控制,有47个g可用作内存缓存,假设按照默认的读写缓存计算,一个TCP连接占用149K加1K的tcp控制块共150K的内存,那么系统能承受最大的并发为 47*1024*1024/150 = 32万,当然这只是理论,一个TCP连接占用的内存实际是大小混用的,根据传输的文件大小以及网络状况动态调整。那么当前是什么情况呢,是有很多的长连接,而且每个请求的数据都很小,也就是说很有大量TCP连接只占了10K左右的内存,所以可以尝试更大的并发。
好了,我顺着思路往下想,“Out of socket memory”除了业务系统恶意丢弃请求、或者孤儿套接字太多、或者fd(已经优化的很大了,不存在)用完了,就可能是为新的soket分配内存资源内存不够用了,因为在之前测试到30万左右的连接的时候出过这个问题,查看内存基本跑满,当时是把ats的logbuffer改小(动态连接一个url有时到45K的长度,于是当时把log buffer改的特别大)后就不报了,后来继续跑到50万左右又报错了,内存基本跑满,后把内存cache从30G调到了15G,再腾出15G给TCP连接及其与资源使用,跑到70万左右又不行了,大量这个错误。因为当前内存使用的很杂,有ats的内存缓存,有大量的孤儿Orphan soket(占用64K左右内存),还有大量的没有释放的TCP连接,还有ats的log等线程使用的内存,七七八八算下来,TCP能使用的内存不多,长连接、小链接、大链接的比例也不好计算,只能按照经验去尝试,目前看跑到70万已经到头了吧。
可是后来又想,系统对于刚开始建连接的时候可能是默认的内存占用,之后再动态调整,按照当前域名质量情况,大多数都是小的不能再小的请求,我是否可以更改默认TCP的读写缓存呢,于是调整,读写默认缓存各变为原来的一半分别是43K和32K,第二天晚高峰检查,跑到86万,没有出现问题,好了到此为止,不再测了。
![86万1.png 高并发下的oom killer_第5张图片](http://img.e-com-net.com/image/info8/7618a36f89c645af82f3a161697522b9.gif)
总结:其实系统单纯能跑多大并发在乎全局fd和内存,但大并发下还能继续保持业务正常服务就是技术活儿了,每个业务系统的参数、操作系统的参数都得琢磨尝试,其余方面的优化小记有空再写。
//////////////////////////////////////////////////////////////////////////////////////
关于系统fd限制的修改
如果不考虑内存大小的限制,在linux下面,fd (即file descriptor)的数量来自2个限制(阈值)。
其一:是操作系统的限制。
这个限制主要是在linux内核中,我们知道,用户程序的fopen操作最后都通过system call进入到linux kenrel。
linux kernel会对此进行检查,防止某个用户占用太多的系统资源。
现在的内核都可以通过sysctl命令在开机的时候来调整。他是不是还有一个代码级别的最大值(如定义了宏),我没有仔细研究关于此的代码,故不能确定。但据我所知,某些程序开上万个fd也是有在用的。
命令sysctl fs.file-max=655360可以调整内核的阈值,当然你得有root权限。想一劳永逸,参考/etc/sysctl.conf,用命令man sysctl.conf
命令sysctl -a可以显示所有的能够调整参数。
其二:是用户进程的限制。
举例,在bash环境下启动的程序将继承bash缺省的或用户定制的限制。
这个限制可以通过bash的内部命令ulimit来调整,当然不能高过操作系统的限制。
比如命令:ulimit -n 20规定了在当前bash环境下运行的程序只能同时打开20个fd,但是如果你做上面的测试程序,则只有17个。还有3个哪里去了?动脑筋想一下你应该能找到答案。
ulimit -n 命令只能往下调fd,不能往上调。如果你改的过小了,想反悔?好像只能关闭当前的bash再重新开启一个。
那么,bash又是从哪里继承的呢?参考/etc/security/limits.conf,用命令man limits.conf
ulimit -a可以显示包括fd在内的全部阈值:如最大数据段大小、最大代码段大小、最大栈大小、用户能创建的进程的最大数目、一个进程中线程的最大数目。
试试在s2服务器上运行此命令,结果应该是最大可同时打开1024个fd。
寻求更多的信息?老办法:输入命令man bash,然后查找ulimit。
一般系统默认每个进程最多持有1024个fd,当进程的并发比较高并且存在系统间调用时,建议将这个值调大;