排查服务器偶发性闪断问题

上周开始公司托管在IDC机房的一台服务器频繁掉线，导致ssh连接不上，过几分钟又恢复。通过监控查看，没有什么有价值的结果，因为是对公网IP监控的，当时监控是没有数据的，唯一有价值的就是通过监控的No data 时间来看，是不定时触发的，排除了因某些定时任务导致。

监控排查无果后，果断询问机房人员，调取问题发生的时间段流量监控，发现交换机的入口流量已经超过了100M（百兆交换）导致流量骤增，公网无法访问。 机房那边的的入流量徒增也就是我们服务器这边的出流量，猜测有大量上传操作或者cpu飙升的现象。

ssh连接不上我们先要确定是 机器确实宕机了 还是 ssh断掉了 还是公网IP无法连接了 ？

问题再次出现时，通过托管在机房的集群环境中其他机器，用内网IP尝试登陆，成功！ 机器是存活的，ssh服务也没有挂！所以就是结合前面的结果，问题就在带宽流量打满了，无法连接。

登录上去以后，top命令 C ， 果断找到"罪魁祸首"

根据PID，找到程序父ID，直接定位是哪个进程引起的

根据公司业务逻辑java程序都以容器的方式运行，并且可以看到运行信息带有env为prod的字样，用docker ps 找出这个容器

ss命令看soket连接情况

结果上看有两处 ESTAB状态时，Send-Q 堆积过多，这肯定是不正常的

这个客户端IP也比较可疑，来自香港，因为这个服务只是公司内部调用 ，集群机器也没有香港的机器。

当务之急的解决办法最快清除这些堆积的包与链接，就是重启容器，询问相关业务人员，进行了重启后，再次查看CPU状态已经恢复正常，通过公网IP也可以立刻链接上了，目前需要多观察几天，是否还会复发。

表示收到的数据已经在本地接收缓冲，但是还有多少没有被进程取走，recv()

如果接收队列Recv-Q一直处于阻塞状态，可能是遭受了拒绝服务 denial-of-service 攻击。

对方没有收到的数据或者说没有Ack的,还是本地缓冲区.

如果发送队列Send-Q不能很快的清零，可能是有应用向外发送数据包过快，或者是对方接收数据包不够快。

从图中可以看到是大量的 send-Q ,可以判定是发送数据给目的地址的时候出现了阻塞的问题，导致了包堆积在本地缓存中，不能成功发出去。那么问题就产生在了客户端， 重启了容器，清掉正发送的队列，再次观察。

包括在tomcat调优时会有accept-count ，max-connections 参数

参考：

https://www.cnblogs.com/leezhxing/p/5329786.html

https://blog.csdn.net/yjh314/article/details/51038774

我估计应该是客户端，或服务器的网卡驱动有问题。如果所有的客户端ping服务器都有问题，应该就是服务器的网卡驱动问题了。我以前遇到过，升级一下驱动就可以了，你试试。

-----------------------------------

呵呵，放松，一切都会好起来的！

---