一次码头工人中复述,连接暴增的问题解决方案

这篇文章主要讲解了一次码头工人中复述,连接暴增的问题解决方案,内容清晰明了,对此有兴趣的小伙伴可以学习一下,相信大家阅读完之后会有帮助。

周六生产服务器出现复述,服务器不可用状态,错误信息为:

状态不可用,等待后台检查程序恢复方可使用.Unexpected流;预期类型& # 39;状态# 39;

如下图所示,下6300年图就是我们复述,服务器运行的端口。

头一次碰到此类问题,心想难道是复述,挂掉了,随即通过telnet ip +端口。发现运行正常,然后就想着进入复述,看下目前连接情况。一看发现竟然高达1903条这么多。

然后想着应该是代码创建复述,连接过多导致的,查看代码。

发现复述,创建只有这一个地方有,这里也是服务注册时才执行。也就是应用程序启动时才被执行一次。然后整个项目查找,没有其他地方再有调用复述,初始化。

心有不甘,难道是每次在复述,读写数据时都会创建连接吗?会和读写频繁有关系吗?总感觉不会啊,随即创建测试代码进行测试一番。

在本地搭建了一个复述,环境,测试之前先看看接数多少,目前看只有1个,也就是目前的cmd连接客户端,这个属于正常的了。

开始测试,运行程序。代码是创建一个连接对象,并一共测试1000次写,和1000次读。

不管我怎么测试连接都是6个,那么也就是说我们程序最多创建了5个连接,当然主要有线程池在里面。

所以基本的存储读取这块代码肯定是没问题。

但代码这块也没算完全放弃排查,因为生产服务器通过码头工人运行着大约6个应用程序。都是连接的同一个复述,会不会是其他应用程序导致的?

然后就想直接通过复述,连接列表里的中随便一个端口来查询对应的进程信息就可以知道是哪些应用程序了。

Linux中通过查询网络端口号显示进程信息。

 netstat -atunlp | grep 60852 

首先看这端口对应的IP,比如这里第一个是172.17.0.1。熟悉码头工人的同学应该知道这个IP是码头工人网关IP。我们容器中的程序都是通过这个网关IP来和我们宿主主机来通讯的。我们通过ifconfig就能发现码头工人这个网关IP,第二个172.17.0.3:6379这个一看就是复述的容器IP,

这样一看确实无法找到具体对应哪个容器中的程序和我们建立连接的。

有一个最笨的办法就是挨个进入容器里面。即码头工人执行——测试/bin/bash然后查看当前容器的网络连接情况。这样非常麻烦,并且需要安装很多组件才能执行一系列命令。

另外一个办法lsof命令,如果没有则需要安装。我们可以通过进程去找所有网络连接情况。

比如我们刚发现我们的进程主要是码头工人,他的pid是582251 .

<代码> lsof我| grep 582251> lsof - i - p 582251

结果如下图,右边其实出现了具体IP,这个IP就是码头工人容器具体的IP地址。

现在知道所有IP和端口了,我们将命令执行结果下载下来。

首先找到自己每个容器对应的IP。

docker inspect name |grep IPAddress//name 容器名称或者id

找到每个ip后然后根据刚下载的所有网络连接信息进行统计，看哪个IP连接最多，最多的一个肯定有问题。

一次码头工人中复述,连接暴增的问题解决方案