记录一次ActiveMQ使用过程中问题以及解决流程
19年元旦前上线一个ActiveMQ服务，版本为5-13-2，使用文件持久化实现主备。
2019-01-17号晚，A系统（生产者）在未通知broker的情况下，开始通过MQ发送队列消息给B系统（消费方），数量约为20万，第二天早上9点左右，发现MQ停止了响应，重启之后服务恢复，但是B系统的处理速度明显没有之前的快。
2019-01-19号晚上A系统反馈向MQ推送消息时，无法连接上MQ。01-20号早上7点左右调整了MQ的最大连接数（activemq.xml maximumConnections），从3000到5000，重启后A系统反馈能正常推送数据了。当日中午，MQ的服务挂了，从后台日志中查看，异常原因为：too many open files，进程在某个时刻打开了超过系统限制的文件数量以及通讯链接数，通过调整/etc/security/limits.conf，在其中加入* - nofile 60000问题解决。（后续监控发现MQ进程的句柄数峰值为2900）。
2019-01-21号晚上，A系统开始重新推送新的数据，01-22号凌晨MQ服务挂掉，后台日志出现OutOfMemoryError，当时MQ进程使用的JVM的初始化内存栈和最大内存都为2000M，其中，内存中ActiveMQTestMessage占用了938M，连接connection占用约503M。这两者主要来源为因消费方速度跟不上生产者推送的速度出现的消息堆积。
01-22早上10点调整MQ服务的JVM初始内存和最大内存为4096M之后，发现消费者处理消息速度很慢，从消费者服务器的top来看，表象为一台服务器在高负载工作，64核服务器基本每个核都能达到100%负载，其他三台服务器负载很低，监控后台日志，高负载的业务输出明显快于低负载的服务器，怀疑低负载的服务器未拿到MQ中的消息进行处理。从MQ后台日志中可以看到大量低速消费者（slow consumer）对应的底层transport链接被关闭，若客户端多个consumer共享一个connection的话，会导致所有的consumer被关闭。修改了activemq.xml中slowConsumerStrategy为false后重启之后，处理速度恢复了，但其实只是解决了低速消费者的一些问题，真正拖慢处理速度的原因还没找到。低速消费者参考链接：https://blog.csdn.net/asdfsadfasdfsa/article/details/53501723。
01-23早上发现消费者B系统处理速度又变慢了。从MQ的线程数、句柄数、GC、top等查看，无异常。B系统服务器出现各服务器负载不均衡问题，依然是一个服务器在高负载工作，各个核基本达到100%使用率，但其他三个服务器的负载完全没上去。综合各位专家的建议，以及网上相关信息，停掉了B系统三个低负载的服务器，并减少高负载服务器的并行消费者数量为10，重启后，发现处理速度恢复正常。考虑到MQ是根据默认prefetchsize=1000向消费者B系统推送数据，可能出现高负载的服务器能拿到消息进行处理，而低负载的服务器拿不到消息处理，让消费者B系统调整了预取数量为4（默认1000），单服务器并行消费者为60，重启后，发现原低负载服务器的负载上去了，并且处理速度已经恢复正常。
2019-01-25,约上午11点，调整了B系统的预取数量为30，以及调整了MQ判断为慢速消费者的时间限制从默认30秒到60秒，目前队列的消费者数量还是变化，不过比之前稳定了。速度也比之前快，24分钟处理了约10000条。
2019-01-25下午14:00，调整慢速消费者maxSlowDuration的时间限制为90秒。
2019-04-02上午，A系统反馈连接不到MQ，MQ日志看到：could not accept connection from tcp://IP:PORT:java.lang.IllegalStateException:Timer already cancelled,查看TCP连接很多连接的状态都为 close_connection,日志中可以看到先抛出了异常：java.lang.OutOfMemoryError: unable to create new native thread，在线程数无法很快降下来的前提下（与并行消费者数量有关），暂时设置JVM的内存参数Xmx和Xms为4000m（之前为6144m），问题解决。（参考深入理解Java虚拟机+JVM高级特性与最佳实践），参考链接：https://www.cnblogs.com/zhangshiwen/p/5793908.html，后续调整了系统最大的可创建线程数量。
2019-05–05发现MQ在运行了五天之后（04-30重启的），查看jstat -gcuitl PID发现老年代空间在FULL GC后只释放了很少一部分，并且由于老年代空间释放很少，FULL GC的频率逐渐升高。此时查看MQ的连接数(netstat -n |grep PID|wc -l)，达到了9002，而MQ目前配置的连接数是9000，已经有部分连接挂起了。连接中B系统数量占90%以上，经沟通，B系统未使用连接池技术。该问题在B系统使用连接池技术后解决了。
