Comprendre la mise en pool de DB pour les travailleurs Sidekiq

Quelqu’un peut-il apporter des éclaircissements sur la mise en pool de bases de données des workers Sidekiq ?

Actuellement, nous avons défini DISCOURSE_DB_POOL sur 15, avec 2 workers Sidekiq ayant chacun une concurrence de 10. Après avoir lu la documentation de Sidekiq, il semble que les threads Sidekiq partagent le pool de bases de données, j’anticipe donc un maximum de 15 * 2 = 30 connexions de base de données de la part des workers Sidekiq. Cependant, malgré cette compréhension, nous observons des pics de connexions à la base de données dépassant le maximum attendu de 30.

Ces pics se produisent environ toutes les 15 minutes et semblent être principalement associés au job planifié PeriodicalUpdates.

Quelqu’un pourrait-il nous fournir des informations qui nous aideront à éviter ces pics ?

@david J’ai remarqué que vous avez fait un travail incroyable dans ce domaine. Pouvez-vous s’il vous plaît fournir quelques éclaircissements ?

Je crains de ne pas connaître les détails de tout cela sur-le-champ.

Il pourrait être utile de vérifier si vous avez personnalisé l’environnement UNICORN_SIDEKIQS. Cela indique combien de processus sidekiq sont lancés (chacun d’eux aura de nombreux threads).

Que montre exactement votre graphique ? S’agit-il de « connexions simultanées » ? Ou s’agit-il du « nombre de connexions créées » ? S’il s’agit de ce dernier cas, peut-être que certaines connexions sont créées et détruites très rapidement.

Et une dernière question : quel problème essayez-vous de résoudre ici ? Y a-t-il un problème causé par le nombre de connexions ?

Merci de votre retour.

Voici les configurations associées que nous avons :

  • DISCOURSE_DB_POOL : « 15 »
  • DISCOURSE_SIDEKIQ_WORKERS : « 10 »
  • UNICORN_SIDEKIQS : « 2 »

Cela signifie que nous avons 2 processus Sidekiq, chacun avec 10 threads.

Le graphique montre le nombre actuel de connexions client.

Nous essayons de configurer correctement la taille du pool de connexions (proxy RDS devant PostgreSQL). Pour ce faire, nous avons besoin d’une meilleure compréhension de la mise en pool des connexions côté application. Pourquoi l’application ne respecte-t-elle pas la configuration DISCOURSE_DB_POOL comme prévu ?
Si DISCOURSE_DB_POOL fonctionne comme prévu, pourquoi observons-nous des pics aussi importants dans les connexions à la base de données ? Ces pics semblent correspondre aux exécutions du travail planifié PeriodicalUpdates.

N’hésitez pas à me faire savoir si vous avez d’autres questions. J’apprécie votre aide pour percer ce mystère.

Avons-nous besoin d’avoir des fichiers de configuration en plus de la variable d’environnement DISCOURSE_DB_POOL pour configurer la mise en commun de la base de données ?

Êtes-vous sûr à 100 % que votre proxy n’est pas en faute ici ?

Oui, je ne pense pas que le proxy soit responsable ici.