早晨开始接到人员反馈，服务异常，开始进行排查，发现服务确实已经异常。
【定位问题】
- 突然接到消息反馈服务异常，然后开始定位问题，发现MQ服务宕机了。然后开始查看ECS服务(内存)监控发现在0点30分左右服务器的内存飙升至80%，然后开始思考为什么服务器内存才80%MQ就宕机了？经过手册了解到原来MQ为了防止自己内存无限扩大导致服务器宕机，而选择让自己服务器停止，这个不了解MQ的实属是一个大坑。尤其是刚开始业务量非常小，后期业务量大起来以后，这个需要格外留意。
4. 开始查看服MQ日志，发现确实是有过WARING预警，3652960712/1024/1024/1024 = 3.4020GB；
********************************************************** *** Publishers will be blocked until this alarm clears *** ********************************************************** =INFO REPORT==== 5-Mar-2022::00:01:29 === vm_memory_high_watermark set. Memory used:3652960712 allowed:3280974643 =WARNING REPORT==== 5-Mar-2022::00:01:29 === memory resource limit alarm set on node rabbit@RedisProduct.【处理问题】
因为考虑到业务量问题，MQ已经启动，不能进行停止否则将影响业务，进行了服务器升级，将原有的4核8G升级至8核16G。
【新的问题产生】升级完成MQ的服务已经正常，但是其中一个Vhost无法链接，链接返回
Cannot connect the mq service!!!
查看RabbitMQ日志，发现链接被拒绝：
=ERROR REPORT==== 5-Mar-2022::11:58:02 ==: Error on AMQP connection <0.31461.19> (xxx.xx.xxx.xxx:xxxx -> xxx.xx.xxx.xxx:xxxx, user: 'xxx_xxx', state: opening) : access to vhost "xxx_xxx_xxx' refused for user "xxx_xxx'【定位新问题】
然后通过别的虚拟主机链接，生产消息没有任何问题，开始把问题定位到是这个Vhost有问题。
【处理新问题】然后把这个Vhost进行删除重进建立，重新建立后，链接开始正常进入。
【总结问题】但是需要需要留意16GB的40%是否够并发业务量的使用，这个需要基于业务进行观察，如果不够，手册上说可以将配置文件调整至0.4~0.66；
注：配置文件需要重启服务器（永久有效）
使用命令不需要重启服务器，但是服务器一旦宕机，就会失效（临时生效）
