网站一般宽度是多少像素,商务网站建设策划书范文,健康云下载app,青海网站建设与制作原创文章#xff0c;转载请注明#xff1a;来自云栖社区 本文看点#xff1a;结合服务器运行案例和TCP代码分析orphan socket产生与消亡以及对系统的影响。精彩的部分在#xff08;二#xff09;细节分析章节。 问题背景 tengine服务器发生过多次orphan socket数量很多的情… 原创文章转载请注明来自云栖社区 本文看点结合服务器运行案例和TCP代码分析orphan socket产生与消亡以及对系统的影响。精彩的部分在二细节分析章节。 问题背景 tengine服务器发生过多次orphan socket数量很多的情况例如有一次使用ss -s命令查看 $ss -s
Total: 36569 (kernel 36823)
TCP: 142787 (estab 28586, closed 4842, orphaned 92575, synrecv 9198, timewait 4684/5073), ports 9868 总共142787条TCP连接处于orphaned状态的连接达到92575。某天orphan socket数量监控占总量百分比曲线图如下 10:30-10:49 约持续19分钟较高然后恢复。 dmesg命令可以查看到有大量的提示:[791.931967] Out of socket memory orphan socket 做关键词google一把有很多但没有查找到能详细说明来龙去脉的 先来看一下在网上关于orphan sockets一段较好的介绍。 Do you have too many orphan sockets?
First of all: whats an orphan socket? Its simply a socket that isnt associated to a file descriptor. For instance, after you close() a socket, you no longer hold a file descriptor to reference it, but it still exists because the kernel has to keep it around for a bit more until TCP is done with it. Because orphan sockets arent very useful to applications (since applications cant interact with them), the kernel is trying to limit the amount of memory consumed by orphans, and it does so by limiting the number of orphans that stick around. If youre running a frontend web server (or an HTTP load balancer), then youll most likely have a sizeable number of orphans, and thats perfectly normal. 简要理解即orphan sockets是没有与任何文件描述符关联的socket应用程序已经不能与此socket进行交互了但是由于内核中TCP未完成仍然占用TCP的内存暂时不能释放。读完这段还是丈二和尚摸不着头脑――摸不清底细。 对于维护线上稳定性需要搞清楚如下问题 什么原因或条件下会导致出现这么多orphan socket ? orphan socket的连接处于TCP状态的那一个阶段 orphan socket过多会给线上带来什么风险 原因定位 以某台机器为例看一下TCP各状态的连接数量。 $ss -s
Total: 37964 (kernel 38570)
TCP: 146848 (estab 29556, closed 5114, orphaned 94904, synrecv 9402, timewait 4823/5226), ports 10946 orphaned数量达到 94904 查看close调用后TCP连接各状态socket数量为什么直接查close调用后的状态请参细节分析部分另外因以下命令执行时间上的偏差可能会对不上ss -s的数值 $ss -nat | grep LAST-ACK | wc -l
67128$ss -nat | grep FIN-WAIT-2 | wc -l
11712$ss -nat | grep FIN-WAIT-1 | wc -l
12317$ss -nat | grep CLOSE-WAIT | wc -l
25$ss -nat | grep TIME-WAIT | wc -l
1410 top10输出分析ipport的连接占用 以下命令输出中第一列代表IP:PORT 第二列代表TCP连接数量。 LAST_ACK状态的top10的IP与PORT输出 $ss -ant | grep LAST-ACK | awk {S[\$4]} END {for(a in S) print a, S[a]} |sort -t -k 2 -n -r | head -n 10
10x.xxx.xxx.x38:51892 62190
10x.xxx.xxx.x38:51814 381
10x.xxx.xxx.x38:59206 97
10x.xxx.xxx.x38:56107 94
10x.xxx.xxx.x38:58271 92
10x.xxx.xxx.x38:59800 85
10x.xxx.xxx.x38:50851 55
10x.xxx.xxx.x38:52226 45
10x.xxx.xxx.x38:52199 27
10x.xxx.xxx.x38:57017 25 FIN-WAIT-1状态的top10的IP与PORT输出 $ss -ant | grep FIN-WAIT-1 | awk {S[\$4]} END {for(a in S) print a, S[a]} |sort -t -k 2 -n -r | head -n 10
10x.xxx.xxx.x38:51892 5581
10x.xxx.xxx.x38:51814 1208
10x.xxx.xxx.x38:59206 782
10x.xxx.xxx.x38:58271 749
10x.xxx.xxx.x38:56107 724
10x.xxx.xxx.x38:59800 611
10x.xxx.xxx.x38:50851 285
10x.xxx.xxx.x38:52199 142
10x.xxx.xxx.x38:50127 97
10x.xxx.xxx.x38:52435 65 FIN-WAIT-2状态的top10的IP与PORT输出 $ss -ant | grep FIN-WAIT-2 | awk {S[\$4]} END {for(a in S) print a, S[a]} |sort -t -k 2 -n -r | head -n 10
10.xxx.xxx.38:51814 1825
10.xxx.xxx.38:59800 1684
10.xxx.xxx.38:58271 1661
10.xxx.xxx.38:59206 1563
10.xxx.xxx.38:56107 1558
10.xxx.xxx.38:50851 329
10.xxx.xxx.38:52199 261
10.xxx.xxx.38:50127 203
10.xxx.xxx.38:52631 144
10.xxx.xxx.38:55488 114 可以明确看出这台主机上10x.xxx.xxx.x38:51892 占用了 62190 条socket处于LAST_ACK状态。为什么这么多LAST_ACK状态的连接看一下TCP状态迁移图可知LAST_ACK状态代表被动关闭的一端在发送FIN报文后最后等待另一端的ACK报文。 正常流程客户端TCP状态迁移 CLOSED-SYN_SENT-ESTABLISHED-FIN_WAIT_1-FIN_WAIT_2-TIME_WAIT-CLOSED正常流程服务器TCP状态迁移 CLOSED-LISTEN-SYN_RCVD-ESTABLISHED-CLOSE_WAIT-LAST_ACK-CLOSED 此机器是做为反向代理服务器符合上述正常流程服务器TCP状态迁移第一个现象通过监控查看10x.xxx.xxx.x38:51892对应的http流量发现此用户每秒的新建TCP连接数量是1.5K~2K且设置的流量带宽限制在20Mbps并在报文出口方向出现大量的丢包第二个现象http访问日志中记录大量的http 499状态码的访问连接。 根据以上两个现象推断10x.xxx.xxx.x38:51892收到client端的关闭FIN后会发送ACK进入到CLOSE_WAIT 状态应用程序中如果没有数据待发送会调用close()使TCP连接发送FIN进入LAST_ACK状态因为出口流量设置的限制大量的ACK和FIN报文被丢弃导致出现上述62190 条socket处于LAST_ACK状态。 后来与用户沟通得知client端是移动端APP程序其TCP连接读写超过限流量没有收到数据等会主动关闭连接可以佐证日志中大量出现的499状态码。 到此原因分析完成可以使用解决方案中调整服务器的内核参数解决如果需要更详细了解orphaned socket可以详细阅读下一篇的细节分析。 解决方案 如上细节分析中某些场景下会对当前sock做惩罚将当前orphan 的数量 2x 甚至 4x与系统限制值做比较。这样内核日志会打印出Out of socket memory但实际的数量并没有超过系统的限制值属于误报的一种情形可以根据具体的情况将 tcp_max_orphans 内核参数值适当调大。 系统中net.ipv4.tcp_orphan_retries 的默认值是 0内核重置为8次, 需要将tcp_orphan_retries改为较小的数值可大大降低orphans的数量降低tcp内存的占用量。注意设置较小的数值可以有效降低orphans的数量net.ipv4.tcp_orphan_retries 0并不是想像中的不重试 案例小结 内核日志dmesg命令看到 Out of socket memory出现内存不足可能会有两种情况 有太多的 orphan sockets通常对于一些负载较重的服务器经常会出现这种情况。 分配给 TCP 的内存确实较少从而导致内存不足。 第一种情况可以用ss -s命令或cat /proc/net/sockstat查看是否孤儿套接字过多。 第二种情况可以调整TCP的内存因网上有大量的此类分析解决这里不再详述。 最后来回答一下对于线上稳定性来说需要搞清楚的问题 orphan socket的连接处于TCP状态的那一个阶段 TCP_FIN_WAIT1、TCP_LAST_ACK、TCP_CLOSING状态都可归类计数于orphan socket但当通过TCP_LINGER2或sysctl_tcp_fin_timeout设置的超时时间大于60秒时的TCP_FIN_WAIT2的连接也归类计数于orphan socket小于60秒的TCP_FIN_WAIT2状态的连接则归类计数于TIME_WAIT从代码可以看出TCP_TIME_WAIT状态是不计入orphan socketTCP_CLOSE_WAIT 状态的连接既不计入orphan socket 也不计入TIME_WAIT。 什么原因或条件下会导致出现这么多orphan socket orphan socket过多会给线上带来什么风险 TCP_FIN_WAIT1 和 TCP_LAST_ACK 状态的连接都在等待对方回复ACK例如client端可以对产生的连接故意发送FIN半关闭而不回复最后的ACK使服务器端产生大量LAST_ACK消耗TCP资源这种情况下调整tcp_max_orphans参数和tcp_orphan_retries可以限制简单的DDOS攻击。
