其他分享
首页 > 其他分享> > 我服务又双叒叕奔溃了,含泪干货分享

我服务又双叒叕奔溃了,含泪干货分享

作者:互联网

今天服务又双叒叕出问题了,问题还不仅仅就一个,而是一堆!!!

异常信息:

Channel shutdown: clean channel shutdown; protocol method: #method<channel.close>(reply-code=406, reply-text=TIMEOUT WAITING FOR ACK, class-id=0, method-id=0)

Consumer failed to start in 60000 milliseconds; does the task executor have enough threads to support the container concurrency?

问题分析

一开始以为是服务本身导致的问题,但是最近一个礼拜都没有提交记录,所以应该不是因为异常提交导致的,只能先重启服务,看看能不能恢复过来。但是重启服务之后还是报类似的错误,而且不只一个服务报错,所以可以确定应该是mq本身的问题。

上述报错属于rabbitmq异常信息

问题原因定位

但是看mq内存、cpu、io、线程这些指标,发现都很正常,消息也没有堆积,这就很奇怪了,为了验证是否是mq的问题,重启了mq服务,重启后发现数据正常消费了,没有报上面的错了,开始二脸蒙蔽中。

通过上面流程,我们基本可以确定是因为mq本身的问题,那问题到底出现在哪里呢?从错误信息我们可以分析得出,是因为应用服务mq相关线程,被mq服务所限制导致的。针对这一结论,我们可以去rabbitmq官网翻一下官方配置文档。

bug原因

我们找到一个叫做vm_memory_high_watermark的配置信息,翻译的意思就是说,如果rabbitmq所在的服务器内存达到40%以上,mq就会进行限流控制。找到这个配置就好办了,解决方案也很简单,一个是加内存,另外一个就是修改vm_memory_high_watermark配置,接下来我们着重介绍一下如何修改vm_memory_high_watermark配置。

rabbitmq环境:

vm_memory_high_watermark的配置在rabbitmq.conf文件中,所以我们修改rabbitmq.conf相关的配置就可以了,本来博主也以为过程就是这样的,简单的很,然后就陷入一个接一个的坑中了。

博主的rabbitmq安装方式采用的是apt-get install rabbitmq-server直接一键安装的,所以很多细节都不是很清楚。第一步我们要知道相应的配置文件都在哪个目录下面,如果配置文件都没找到,那玩个锤子。

找线上正在运行的配置文件,我们可以通过ps -ef|grep rabbitmq来检索,通过这个命令我们可以得到正在运行的rabbitmq相关的路径信息,如下所示:

我们可以很清晰的找到,rabbitmq的安装地址是:/usr/lib/rabbitmq/lib/rabbitmq_server-3.5.7/sbin/,我们进入这个目录中看一下:

我们想要的配置文件位置就在rabbitmq-defaults中,打开文件我们就可以得到,我们心心念念的rabbitmq.conf配置文件就在/etc/rabbitmq/下面,大家是不是觉得找到这个就完事了,只要修改重启就game over了,错了。3.5.7版本是没有rabbitmq.conf文件的,全部走的都是默认的配置,需要我们自己创建配置。

第一个坑:

3.7.0之前的配置文件和之后的配置文件格式是不一样的,如下图所示:

3.7.0之前的采用的是json格式,之后采用的是sysctl format格式,所以如果配置文件搞错,那一切都是白搭。

开开心心修改完配置文件,通过

rabbitmqctl stop
rabbitmq-server start

重启后,用rabbitmqctl status检查状态,发现没有变化,还是修改之前的配置。搞的我一度怀疑是重启的命令没生效,最后无意中看到rabbitmq控制台的路径信息,也就是我们的第二个坑。

第二个坑:

3.5.7版本的rabbitmq配置文件后缀为config,而非conf

果然博主将后缀名称修改为config,重启服务之后,马上就生效了。

这边还需要注意的配置有:

这些配置和服务稳定可靠息息相关,具体得根据实际业务来设置。

第三个坑:

配置文件都配置完毕之后,大部分服务的消费都恢复正常了,也没有上面提到的报错信息了,但是有一个服务的消费还是为0,这也是博主遇到的第三个坑了。

像这种队列有消费者,但是消费速度为0的情况,mq本身服务各个指标都监控没有问题的的前提下,几乎可以肯定是应用程序本身的问题。

应用服务外部的配置有:redis、mysql、rabbitmq,rabbitmq排除掉了,redis、mysql查看对应的监控发现都没有任何异常指标,而且redis、mysql都设置了操作的超时时间,所以不可能长达几个小时没返回数据的情况,剖析到这里,我们基本可以将问题的聚焦点聚集在应用服务代码本身了。

但是应用服务内存、io、带宽、cpu都正常,然后检查线程的时候发现,http的请求线程一直长时间占用,然后顺藤摸瓜,将所有的http请求代码全部找出来,发现了如下代码:

config.setServiceURL(awsAuthenticationVo.getServiceUrl());
config.setConnectionTimeout(8000000);
config.setSoTimeout(8000000);

超时时间设置的过分长,计算一下时间,超时时间为好几天,这就是第三个大坑,http超时时间设置过长。

修改了超时时间,重启服务,消费者开始正常消费了,持续观察一段时间之后,没有发现消费者突然不消费的情况了,至此问题终于全部修复完毕。

总结:

遇到这种问题,排查难度会很大,因为得一步步分析,逐步排查。通过这次bug,我终于明白为什么阿里、腾讯这些大公司,要求完全理解jdk版本之后才能进行升级。就像上面rabbitmq要是对它相关配置都不了解的情况下,就安装了,出问题之后可想而知。

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

 

 

标签:服务,配置文件,含泪,重启,配置,rabbitmq,干货,mq,分享
来源: https://blog.51cto.com/u_8865295/3030153