Optimisation d'un Discourse Multisite de grande taille : goulets d'étranglement de la base de données et de Sidekiq

Je cherche des conseils d’experts pour optimiser une configuration multisite Discourse. J’ai une seule VM web et une VM de base de données séparée sur un fournisseur de cloud majeur. Bien que les deux machines aient des spécifications décentes, je constate que mon système est submergé par un grand volume de tâches d’arrière-plan, ce qui semble mettre à rude épreuve la base de données.

Ma configuration app.yml actuelle est :

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

D’après mes observations, le goulot d’étranglement n’est pas une limite de connexion stricte, mais plutôt le volume élevé de tâches en concurrence pour les ressources de la base de données en même temps. Les files d’attente dans Sidekiq sont constamment saturées, ce qui rend le site lent, même pour les tâches administratives de base.

Je cherche une approche générique pour régler le système en vue de la stabilité et des performances. Plus précisément, j’aimerais comprendre les meilleures pratiques pour :

  • Concurrence Sidekiq : Comment dimensionner DISCOURSE_SIDEKIQ_WORKERS dans un environnement multisite pour gérer un volume élevé de tâches sans surcharger la base de données ?
  • Séparation des files d’attente : Est-il recommandé d’exécuter des processus Sidekiq séparés pour gérer différentes files d’attente (par exemple, priorité critique vs faible) ? Cela garantirait que les tâches lourdes ne bloquent pas les tâches plus urgentes.

Je ne cherche pas une solution qui nécessite un changement architectural majeur ou le passage à un autre serveur web pour le moment, car je souhaite garder le processus aussi simple et à faible risque que possible. J’espère obtenir des conseils sur une voie sûre et efficace.

Merci !

3 « J'aime »

Discourse devrait pouvoir s’adapter automatiquement en fonction de vos ressources système. Notez qu’il est sûr de réexécuter le script ./discourse-setup si vous avez récemment augmenté vos ressources système. Le script peut s’adapter aux ressources accrues et ajuster votre fichier .yml en conséquence.

2 « J'aime »

Il semble que vous en ayez besoin de moins ?

Je suis à peu près sûr qu’il sait déjà qu’il doit prioriser les tâches à haute priorité.

2 « J'aime »

@itsbhanusharma @pfaffman Merci pour votre aide et vos commentaires à ce sujet ! J’apprécie que vous ayez tous deux pris le temps de partager votre expertise.

4 « J'aime »

Si la base de données est le goulot d’étranglement, avez-vous envisagé de passer à un type d’instance plus grand pour votre base de données cloud ?

1 « J'aime »

Ce sujet a été automatiquement fermé 30 jours après la dernière réponse. De nouvelles réponses ne sont plus autorisées.