Optimización de un Discourse Multisite grande: cuellos de botella de base de datos y Sidekiq

Instalación Alojamiento
1

Estoy buscando orientación experta sobre cómo optimizar una configuración multisitio de Discourse. Tengo una única VM web y una VM de base de datos separada en un importante proveedor de nube. Si bien ambas máquinas tienen especificaciones decentes, estoy descubriendo que mi sistema se ve abrumado por un gran volumen de trabajos en segundo plano, lo que parece estar estresando la base de datos.

Mi configuración actual de app.yml es:

  • UNICORN_WORKERS: 4
  • UNICORN_SIDEKIQS: 4
  • DISCOURSE_SIDEKIQ_WORKERS: 10
  • DISCOURSE_DB_POOL: 8

Según mis observaciones, el cuello de botella no es alcanzar un límite de conexión estricto, sino el gran volumen de trabajos que compiten por los recursos de la base de datos al mismo tiempo. Las colas en Sidekiq se acumulan constantemente, lo que hace que el sitio se sienta lento, incluso para tareas administrativas básicas.

Estoy buscando un enfoque genérico para ajustar el sistema en cuanto a estabilidad y rendimiento. Específicamente, me gustaría entender las mejores prácticas para:

  • Concurrencia de Sidekiq: ¿Cómo se debe dimensionar DISCOURSE_SIDEKIQ_WORKERS en un entorno multisitio para manejar un alto volumen de trabajos sin estresar la base de datos?
  • Separación de colas: ¿Se recomienda ejecutar procesos Sidekiq separados para manejar diferentes colas (por ejemplo, prioridad crítica vs. baja)? Esto aseguraría que los trabajos pesados no bloqueen los más urgentes.

No busco una solución que requiera un cambio arquitectónico importante o migrar a un servidor web diferente en este momento, ya que quiero mantener el proceso lo más simple y de bajo riesgo posible. Espero recibir consejos sobre un camino seguro y efectivo.

¡Gracias!

3 Me gusta
2

Discourse debería poder adaptarse automáticamente en función de los recursos de su sistema. Tenga en cuenta que es seguro volver a ejecutar el script ./discourse-setup si ha aumentado recientemente los recursos de su sistema. El script puede adaptarse a los recursos aumentados y ajustar su archivo .yml en consecuencia.

2 Me gusta
3

¿Suena a que necesitas menos?

Estoy bastante seguro de que ya sabe priorizar los trabajos de alta prioridad.

2 Me gusta
4

@itsbhanusharma @pfaffman ¡Gracias por tu ayuda y aportación en esto! Aprecio que ambos se tomaran el tiempo para compartir su experiencia.

4 Me gusta
5

Si la base de datos es el cuello de botella, ¿ha considerado pasar a un tipo de instancia más grande para su base de datos en la nube?

1 me gusta
6

Este tema se cerró automáticamente 30 días después de la última respuesta. Ya no se permiten nuevas respuestas.