Rendimiento
Los despliegues de IBM Cloud® Messages for RabbitMQ se pueden escalar manualmente para adaptarlos a su uso, o se pueden configurar de modo que se escalen automáticamente bajo determinadas condiciones de recursos. Cuando ajuste el rendimiento del despliegue, tenga en cuenta algunos factores.
Supervisión del despliegue
Los despliegues de Messages for RabbitMQ ofrecen una integración con el servicio IBM Cloud® Monitoring para permitir la supervisión básica del uso de recursos del despliegue. Se presentan muchas de las métricas disponibles, como el uso de disco y el IOPS, para ayudarle a configurar el escalado automático en su despliegue. La observación de tendencias en el uso y la configuración del escalado automático para darles respuesta puede ayudar a aliviar los problemas de rendimiento antes de que las bases de datos queden inestables debido al agotamiento de recursos.
Uso de memoria de RabbitMQ
RabbitMQ proporciona un desglose sólido del uso de memoria, que puede proporcionarle información sobre cómo se asignan los recursos de memoria y cómo se utilizan en el despliegue. Especialmente, las conexiones, los espejos de colas y los mensajes acumulados utilizan memoria. Si el caso de uso llama a muchas conexiones abiertas a la vez, probablemente sea conveniente aumentar la memoria. Del mismo modo, si tiene colas que contienen sólo mensajes transitorios que no necesitan réplica, puede reducir el uso de memoria ajustando la política de duplicación correspondiente. Los cambios en la política de duplicación, que implican que los mensajes tienen menos duplicados o que no tienen ninguno, pueden hacer que se supriman los mensajes cuando se reinicia el nodo y esos habrán desaparecido para siempre.
Ocasionalmente, RabbitMQ puede experimentar picos de memoria. Específicamente, con los despliegues de Messages for RabbitMQ, las actualizaciones y el mantenimiento en los que reiniciar o suprimir un nodo hacen que aumente el uso de memoria para volver a sincronizar el nodo reiniciado o nuevo. Si su RabbitMQ utiliza de forma habitual un alto porcentaje de su memoria disponible, uno de estos picos puede hacer que su despliegue se quede sin memoria y que se cuelgue. Se recomienda escalar la memoria para que tenga suficiente espacio para resincronizar un nodo.
Alarmas de memoria de RabbitMQ
De forma predeterminada, cuando el servidor de RabbitMQ utiliza más del 40 % de la RAM disponible, genera una alarma de memoria y bloquea los mensajes entrantes de los editores. La alarma de memoria se borra si los consumidores utilizan suficientes mensajes o si los mensajes se mueven al disco. Una vez que se ha borrado la alarma de memoria, se reanuda el servicio normal y se desbloquean los editores. Tenga en cuenta que esto no impide que el servidor RabbitMQ utilice más del 40 % de la memoria asignada, es simplemente el punto en el que se regulan los editores. Para obtener más información, consulte la documentación deRabbitMQ.
Alarmas de disco de RabbitMQ
De forma predeterminada, cuando el servidor de RabbitMQ detecta que el espacio libre de disco ha descendido por debajo de un determinado umbral, genera una alarma de disco. El umbral para Messages for RabbitMQ es el 80 % del tamaño de disco del despliegue. La alarma bloquea los mensajes entrantes de los editores y evita que los mensajes en la memoria se graben en disco. La alarma es de todo el clúster, por lo que si el espacio de disco en un nodo es demasiado bajo, la alarma bloquea todos los nodos. Para borrar la alarma, es necesario consumir los mensajes que se han grabado en el disco y reclamar ese espacio, o bien escalar el despliegue a un tamaño de disco más grande.
Puede encontrar más información sobre las alarmas de memoria en la documentación deRabbitMQ.
IOPS de disco
El número de operaciones de entrada/salida por segundo (IOPS) está limitado por el tipo de volumen de almacenamiento que se está utilizando. Los volúmenes de almacenamiento para los despliegues de Messages for RabbitMQ se suministran en volúmenes de Block Storage Endurance con el nivel de 10 IOPS por GB. Los límites de IOPS pueden afectar a las operaciones de almacenamiento y al rendimiento de los mensajes de RabbitMQ. Alcanzar estos límites puede hacer que el disco se quede atrás en la reclamación de espacio después de que se consuman los mensajes, lo que genera alarmas de disco y la regulación de los editores hasta que la actividad se ralentiza. Puede aumentar el número de IOPS disponible en el despliegue aumentando el espacio de disco.
Colas de quórum
La alta disponibilidad se puede gestionar con colas de quórum. La utilización de colas de quórum afecta al rendimiento; necesita más memoria y espacio de disco para WAL del que utiliza para mantener el estado de las operaciones. También necesita más E/S de disco ya que conserva todos los datos en el disco. Si ha implementado colas de quórum o las está considerando, la documentación de RabbitMQ tiene una buena reseña del efecto correspondiente en uso de recursos y el rendimiento.
Supervisión de alarmas de RabbitMQ
Cuando se desencadena una alarma de disco o memoria, RabbitMQ emite una notificación deconnection.blocked
a las conexiones de publicación.
Muchos controladores dan admiten el protocolo necesario para capturar la notificación por lo que puede diseñar su aplicación para responder a las alarmas de RabbitMQ.
También puede supervisar alarmas desde la API HTTP de RabbitMQ. Utilice los puntos finales GET /api/nodes
y busque
mem_alarm
y disk_free_alarm
en la respuesta.
Para obtener más comprobaciones relacionadas con las alarmas de memoria, puede recopilar información relacionada con la memoria de un solo nodo mediante el punto final GET /api/nodes/{node}/memory
.
Comprobaciones de estado estándar
La API HTTP de RabbitMQ proporciona un par de puntos finales de comprobación de estado para verificar el estado de los nodos de RabbitMQ en el despliegue.
- Todos los nodos -
GET /api/healthcheck/node
- Nodo único -
GET /api/healthcheck/node/<node_name>
Las comprobaciones de estado consumen recursos del sistema. Para despliegues más pequeños y menos ocupados, la comprobación de estado no debe tardar en dar una respuesta. En despliegues más grandes o con mucha carga, puede tardar más tiempo en devolver resultados.