Comprendiendo el pooling de bases de datos para trabajadores de Sidekiq

¿Alguien puede aclarar el agrupamiento de bases de datos de los trabajadores de Sidekiq?

Actualmente, hemos configurado DISCOURSE_DB_POOL en 15, con 2 trabajadores de Sidekiq, cada uno con una concurrencia de 10. Después de leer la documentación de Sidekiq, parece que los hilos de Sidekiq comparten el grupo de bases de datos, por lo que anticipo un máximo de 15 * 2 = 30 conexiones de base de datos de los trabajadores de Sidekiq. Sin embargo, a pesar de esta comprensión, estamos observando picos en las conexiones de base de datos que superan el máximo esperado de 30.

Estos picos ocurren aproximadamente cada 15 minutos y parecen estar principalmente asociados con el trabajo programado PeriodicalUpdates.

¿Alguien podría ofrecer información que nos ayude a evitar estos picos?

@david He notado que has hecho un trabajo increíble en esta área. ¿Podrías por favor dar algunas ideas?

Me temo que no conozco los detalles de cómo funciona todo esto de memoria.

Puede que valga la pena comprobar si has personalizado el entorno UNICORN_SIDEKIQS. Eso indica cuántos procesos de sidekiq se inician (cada uno de los cuales tendrá muchos hilos).

¿Qué muestra exactamente tu gráfico? ¿Son ‘conexiones concurrentes’? ¿O es ‘número de conexiones creadas’? Si es lo último, quizás algunas conexiones se crean y destruyen muy rápidamente.

Y una última pregunta: ¿qué problema estás intentando resolver aquí? ¿Hay algún problema causado por el número de conexiones?

Gracias por responder.

A continuación, se muestran las configuraciones relacionadas que tenemos:

  • DISCOURSE_DB_POOL: “15”
  • DISCOURSE_SIDEKIQ_WORKERS: “10”
  • UNICORN_SIDEKIQS: “2”

Esto significa que tenemos 2 procesos Sidekiq, cada uno con 10 hilos.

El gráfico muestra el número actual de conexiones de clientes.

Estamos intentando configurar correctamente el tamaño del grupo de conexiones (el proxy RDS que se encuentra frente a PostgreSQL). Para hacerlo, necesitamos una mejor comprensión de la agrupación de conexiones en el lado de la aplicación. ¿Por qué la aplicación no respeta la configuración de DISCOURSE_DB_POOL como se esperaba?
Si DISCOURSE_DB_POOL está funcionando como se esperaba, ¿por qué vemos picos tan grandes en las conexiones de la base de datos? Estos picos parecen estar alineados con las ejecuciones del trabajo programado PeriodicalUpdates.

Por favor, hágame saber si tiene más preguntas. Agradezco la ayuda para desvelar el misterio.

¿Necesitamos tener algún archivo de configuración además de la variable de entorno DISCOURSE_DB_POOL para configurar el pooling de la base de datos?

¿Estás 100% seguro de que tu proxy no tiene la culpa aquí?

Sí, no creo que el proxy sea el culpable aquí.