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

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

异常信息：

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环境：

• Ubuntu：16.04.1 LTS
• RabbitMQ：3.5.7
• Erlang：18.3

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，重启服务之后，马上就生效了。

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

• vm_memory_high_watermark_paging_ratio：队列开始将消息分页到磁盘以释放内存的高水位标记限制的分数
• disk_free_limit：abbitMQ在其上存储数据的分区的磁盘可用空间限制。当可用磁盘空间低于此限制时，将触发流控制。
• channel_max：与客户端协商的最大允许通道数

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

第三个坑：

配置文件都配置完毕之后，大部分服务的消费都恢复正常了，也没有上面提到的报错信息了，但是有一个服务的消费还是为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要是对它相关配置都不了解的情况下，就安装了，出问题之后可想而知。