一、概述

(一)现象

服务器有两个现象,第一是tcp连接数不多,不超过10个,但是time_wait状态的2000。第二个按照以往的性质,在很少用户访问的情况下,服务器的资源几乎没有使用,比如CPU,不超过5%。现在没有什么用户的的情况下,CPU损耗坚持在40%左右,夜间也不停歇。里面运行着好几个web项目,都用docker启动的容器分开。

(二)相关知识

tcp连接有3次握手,断开有四次挥手。

三次握手中第一次,是主动端发出SYN信号给正在listen的被动端,然后自己变成了SYN-SENT状态;第二次是被动端发送ACK确认收到信号和SYN信号;第三次是主动端发出ACK信号确认已经收到了被动端的SYN。然后双双进入了enblished状态,便是已经连接成功。

四次挥手中的第一次就是主动端断开,发送FIN信号,变成FIN-WAIT-1状态;第二次是被动方收到FIN信号,就变成CLOSE-WAIT状态,然后赶紧发送ACK信号给主动方确认,这是时候主动方变为FIN-WAIT-2状态;第三次还是被动方等自己的应用断开连接的时候,发送FIN信号给主动方,被动方的状态变成LAST-ACK;第四次是主动方收到被动方的FIN信号,然后发送的ACK信号,瞬间自己变成TIME-WAIT状态,然后等待回收。

就是说,谁有TIME-WAIT,谁就是主动方。这点可以排除用户频繁关闭网页的可能。意思就是说这都是服务器主动请求断开连接的,而TIME-WAIT状态的链接也没有回收。

二、问题推测

(一)网络

网络上面的就是网络不好,或者被攻击。

(二)应用

中间件的参数不对,导致有中间件断开的连接,或者应用程序错误造成的主动断开连接。或者也是应用方面导致消耗资源太多。

三、排查

这个服务器有三个项目,每个项目的架构都是lanmp。问题复杂在于服务器里面好几个项目,每个项目用都一个反向代理。好的一点是后端是docker容器,分开的。

(一)TCP连接上的IP

1.下图是容器的IP

命令:for i in $(docker ps|awk 'NR!=1 {print $NF}');do echo -e $i "\c";docker inspect --format '{{ .NetworkSettings.IPAddress }}' $i;done

2.下图是连接中本地的IP

命令:netstat -tn|grep TIME_WAIT|awk '{print $4}'|sort|uniq -c|sort -nr|head

排名第一这个是我们本地IP,6601是api项目的监听端口,从这里可以看出在所欲的TIME_WAIT状态的TCP里面,API项目的后端是被请求最多的那个。估计反向代理服务器也被请求了很多。

3.下图是连接本地API项目的主动IP

命令:netstat -ant|grep 10.25.20.251:6601

途中可以看出,请求连接API后端的全部都是nginx的IP,这也很容易理解,nginx反向代理是入口嘛。下面就看看到底是谁对nginx发出请求。

4.下图是连接中外地的IP

命令:netstat -tn|awk '{print $5}'|sort|uniq -c|sort -nr|head

对API的请求是600,对nginx的请求是300,说明所有的TIME-WAIT,一部分是请求nginx的,一部分是nginx请求API的。

5.下图是展示到底是对请求了API的web前端nginx

命令:netstat -ant|grep 192.168.42.32:443

原来是192.168.42.1这个IP的请求。其实192.168.42.1这个IP是docker的虚拟网卡的IP,作为全部容器的网关,也就是说反正这就是这些容器发出的请求,但是不能确定是哪一个。

综上所述,可以排除网络问题,中间件apache的参数没有改,但是对web前端nginx的请求那么多,可以说明问题不是出现在apache的请求上面。那就往代码错误方面考虑。

(二)宿主机上的容器

1.应用和网络的关系

可能TIME-WAIT的问题就是后端程序乱发请求,apache是主项目的后端容器,apache-api就是api的后端程序。webserver占用的CPU上升,刚好就说明容器使用的系统资源就是由这种请求引起的。下面用tail看看api的access日志。

实时监测,发现API一秒钟被请求12次左右,根据业务性质和docker的状态显示,可以断定是主项目的循环请求造成的系统资源内耗。而每次请求API项目就返回了access_token,API返回数据之后就发出断开信号,逻辑和现象很符合,也可以断定TIME_WAIT的状态也是这请求引起。而TIME_WAIT不是不回收,而是回收了,但不断的生成。

TIME_WAIT状态过多的排查的更多相关文章

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

    TIMEWAIT状态本身和应用层的客户端或者服务器是没有关系的.仅仅是主动关闭的一方,在使用FIN|ACK|FIN|ACK四分组正常关闭TCP连接的时候会出现这个TIMEWAIT.服务器在处理客户端请 ...

  2. 服务器TCP连接中 TIME_WAIT 状态过多

    今天查看服务器的TCP连接数,发现其中 TIME_WAIT 状态的太多了: # netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a ...

  3. LINUX下解决netstat查看TIME_WAIT状态过多问题

     来源:多3度热爱 的BLOG   查看连接某服务端口最多的的IP地址 netstat -nat |awk '{print $5}'|awk -F: '{print $1}'|sort|uniq -c ...

  4. LINUX下解决netstat查看TIME_WAIT状态过多问题(转)

    原文连接:www.itokit.com/2012/0516/73950.html # netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c 16 CLOSIN ...

  5. 从Linux源码看TIME_WAIT状态的持续时间

    从Linux源码看TIME_WAIT状态的持续时间 前言 笔者一直以为在Linux下TIME_WAIT状态的Socket持续状态是60s左右.线上实际却存在TIME_WAIT超过100s的Socket ...

  6. 也说说TIME_WAIT状态

    也说说TIME_WAIT状态 一个朋友问到,自己用go写了一个简单的HTTP服务端程序,为什么压测的时候服务端会出现一段时间的TIME_WAIT超高的情况,导致压测的效果不好呢? 记得老王有两篇文章专 ...

  7. TIME_WAIT连接过多解决办法

    问题起因: 自己开发了一个服务器和客户端,通过短连接的方式来进行通讯,由于过于频繁的创建连接,导致系统连接数量被占用,不能及时释放.看了一下18888,当时吓到了. 现象: 1.外部机器不能正常连接S ...

  8. Linux-TCP/IP TIME_WAIT状态原理

    TIME_WAIT状态原理---------------------------- 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态. 客户端主动关闭连接时,会发送最后一个a ...

  9. TCP/IP TIME_WAIT状态原理

    原文转载:http://elf8848.iteye.com/blog/1739571 IME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后,主动 ...

随机推荐

  1. linux之systemd---学习

    linux 操作系统的启动首先从 BIOS 开始,接下来进入 boot loader,由 bootloader 载入内核,进行内核初始化.内核初始化的最后一步就是启动 PID 为 1 的 init 进 ...

  2. java8 LocalDateTime转unix时间戳(带毫秒,不带毫秒)

    转载自:LocalDateTime To Timestamp Epoch Seconds And Milliseconds Convert LocalDateTime to seconds since ...

  3. NumPy学习_02 ndarray基本操作

    1.算术运算符 它们只用于位置相同的元素之间,即为元素级的运算. 所得到的运算结果组成一个新的数组. 不用编写循环即可对数据执行批量运算.(矢量化) import numpy as np # 创建一个 ...

  4. HDU 6041.I Curse Myself 无向仙人掌图

    I Curse Myself Time Limit: 8000/4000 MS (Java/Others)    Memory Limit: 131072/131072 K (Java/Others) ...

  5. core的微服务相关

    网关是ocelot consul 服务发现 配置中心apollo

  6. STC项目风险分析

    一.引言 由于项目的实现具有不确定性,所以每个项目都是存在风险的. 项目实现过程中的复杂性以及项目内外许多变化的因素,都会造成项目实现过程中的风险. 如果不能对项目的风险进行很好的分析和管理,那么项目 ...

  7. python3 第二十五章 - comprehensions(推导式)

    推导式(又称解析式),是Python的一种独有特性.推导式是可以从一个数据序列构建另一个新的数据序列的结构体. 共有三种推导,在Python2和3中都有支持: 列表(list)推导式 字典(dict) ...

  8. sourceInsight4 完美破解

    sourceInsight4 完美破解 参考路径: https://blog.csdn.net/zxy020/article/details/75047670 首先确保你在官网下载了原版4.0并安装好 ...

  9. dubbo入门学习 二 RPC框架

    rpc框架解释 谁能用通俗的语言解释一下什么是 RPC 框架? - 远程过程调用协议RPC(Remote Procedure Call Protocol) 首先了解什么叫RPC,为什么要RPC,RPC ...

  10. thinkpadE系列重装系统:u盘启动

    一.下载深度装机大师,制作启动u盘. 二.重启电脑:按F1;进入bios设置:     thinkpad e430c笔记本使用u盘装系统时无法使用u盘启动,这是由于thinkpad e430c笔记本u ...