记录一次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 Después de ajustar la memoria inicial y la memoria máxima de la JVM del servicio MQ a 4096M a las 10 a.m., se descubrió que el consumidor procesaba los mensajes muy lentamente. Desde la parte superior del servidor del consumidor, parece que un servidor está funcionando bajo una carga alta, 64 núcleos Básicamente, cada núcleo del servidor puede alcanzar el 100% de carga. Los otros tres servidores tienen una carga muy baja. El registro en segundo plano se supervisa. La salida del servicio de carga alta es significativamente más rápida que la del servidor de carga baja. Se sospecha que el servidor de carga baja no ha recibido el mensaje MQ. Tratar con Desde el registro de fondo de MQ, puede ver que los enlaces de transporte subyacentes correspondientes a un gran número de consumidores lentos están cerrados. Si varios consumidores en el cliente comparten una conexión, todos los consumidores se cerrarán. Después de que slowConsumerStrategy en activemq.xml se cambió a falso y se reinició, se restableció la velocidad de procesamiento, pero en realidad solo resolvió algunos problemas de los consumidores de baja velocidad. No se ha encontrado la razón para realmente reducir la velocidad de procesamiento. Enlace de referencia del consumidor de baja velocidad: https://blog.csdn.net/asdfsadfasdfsa/article/details/53501723.
En la mañana del 23 al 23, se descubrió que la velocidad de procesamiento del sistema B del consumidor se ha desacelerado nuevamente. Del número de subprocesos MQ, controladores, GC, superior, etc., no hay excepción. El sistema del servidor B tiene un problema de carga desequilibrada entre los servidores. Todavía es un servidor que funciona a alta carga, y cada núcleo básicamente alcanza el 100% de utilización, pero la carga de los otros tres servidores está completamente activa. Según las sugerencias de los expertos y la información relacionada en Internet, los tres servidores de baja carga del sistema B se detuvieron y el número de consumidores paralelos de los servidores de alta carga se redujo a 10. Después de reiniciar, se descubrió que la velocidad de procesamiento volvió a la normalidad. Teniendo en cuenta que MQ envía los datos al sistema del consumidor B de acuerdo con la prefetchsize = 1000 predeterminada, puede suceder que el servidor con alta carga pueda recibir el mensaje para procesar, mientras que el servidor con poca carga no puede procesar el mensaje, por lo que el sistema del consumidor B ajusta la captación previa El número es 4 (1000 por defecto), y el consumidor paralelo de un solo servidor es 60. Después de reiniciar, se descubre que la carga del servidor original de baja carga ha aumentado y la velocidad de procesamiento ha vuelto a la normalidad.
El 25 de enero de 2019, aproximadamente a las 11 a.m., el número de captaciones previas en el sistema B se ajustó a 30, y el límite de tiempo para que MQ juzgue a los consumidores lentos se ajustó de los 30 segundos a 60 segundos predeterminados. Cambios, pero más estables que antes. La velocidad también es más rápida que antes, con aproximadamente 10,000 procesados en 24 minutos.
25-01-2019 a las 14:00, el límite de tiempo para ajustar el consumo lento maxSlowDuration es de 90 segundos.
En la mañana del 2 de abril de 2019, el sistema A informó que la conexión no podía alcanzar MQ. El registro de MQ vio: no podía aceptar la conexión desde tcp: // IP: PORT: java.lang.IllegalStateException: el temporizador ya se canceló, verifique el estado de muchas conexiones para conexiones TCP Ambos son close_connection, puede ver en el registro que primero se lanzó una excepción: java.lang.OutOfMemoryError: no se puede crear un nuevo hilo nativo, bajo la premisa de que el número de hilos no se puede reducir rápidamente (relacionado con el número de consumidores paralelos), establecido temporalmente Los parámetros de memoria Xmx y Xms de la JVM son 4000m (anteriormente 6144m), y el problema está resuelto. (Consulte la comprensión en profundidad de la máquina virtual Java + características avanzadas y mejores prácticas de JVM), enlace de referencia: https://www.cnblogs.com/zhangshiwen/p/5793908.html, y posteriormente ajustó el número máximo de hilos que se pueden crear.
2019-05–05 Después de descubrir que MQ ha estado funcionando durante cinco días (reinicio del 04-30), compruebe jstat -gcuitl PID y descubrió que el espacio de generación anterior solo liberó una pequeña parte después de FULL GC, y porque el espacio de generación anterior se lanzó muy poco La frecuencia de GC COMPLETO aumenta gradualmente. En este momento, verifique el número de conexiones MQ (netstat -n | grep PID | wc -l), llegando a 9002, y el número de conexiones configuradas actualmente por MQ es 9000, y algunas conexiones se han suspendido. El número de sistemas B representó más del 90% de las conexiones. Después de la comunicación, el sistema B no utilizó la tecnología de grupo de conexiones. Este problema se resolvió después de que el sistema B utilizara la tecnología de agrupación de conexiones.
