Problème : traitement Sidekiq extrêmement lent après de grandes importations sur une instance multisite

Soutien
1

Nous exécutons plusieurs sites Discourse avec multisite sous une seule application. Récemment, nous avons effectué un lot d’importations d’utilisateurs à grande échelle (centaines de milliers d’utilisateurs sur 6 sites). Après les importations, Sidekiq traite les tâches en arrière-plan très lentement. Le tableau de bord Sidekiq montre une énorme file d’attente et les tâches sont traitées à un rythme beaucoup plus lent que prévu.

Détails de l’environnement :

  • La VM a été mise à niveau vers 16 processeurs / 16 Go de RAM.
  • Cependant, dans l’interface Sidekiq, nous ne voyons que 5 threads et il semble que seule une petite partie des ressources soit utilisée.
  • La file d’attente d’importation principale (“nursingjobs” en tant que parent multisite) gère les tâches de tous les sites enfants, mais le débit des tâches est très faible.
  • Métriques du serveur : CPU parfois à 80–90 %, mémoire autour de 6,7/7,2 Go.

Nous cherchons à :

  • Accélérer le traitement des tâches Sidekiq/arrière-plan pour vider les énormes files d’attente post-importation.
  • S’assurer que Discourse utilise toutes les ressources disponibles (CPU/RAM).
  • Comprendre s’il existe des limites de threads/processus qui doivent être ajustées.

Questions :

  1. Quelle est la meilleure façon de configurer Sidekiq/Discourse pour un débit élevé après une importation ?
  2. Quels sont les paramètres recommandés pour UNICORN_SIDEKIQS et DISCOURSE_SIDEKIQ_WORKERS sur de grands systèmes multi-cœurs ?
  3. Existe-t-il des paramètres Postgres ou d’autres paramètres app.yml que nous devrions ajuster pour éviter les erreurs de pool de base de données lors de l’augmentation de la concurrence Sidekiq ?
  4. Des meilleures pratiques pour vider rapidement et en toute sécurité d’énormes files d’attente Sidekiq après des importations ?

L'image affiche un tableau de bord Sidekick.io montrant le nombre de processus, les instances échouées, la latence et trois tâches mises en file d'attente, chacune avec des options de suppression. (Légendé par l'IA)
L'image affiche un tableau de bord Sidekick.io montrant le nombre de processus, les instances échouées, la latence et trois tâches mises en file d'attente, chacune avec des options de suppression. (Légendé par l'IA)1920×590 139 KB

Statistiques/captures d’écran Sidekiq disponibles si utiles !

3

La réponse à toutes ces questions est, pour l’essentiel, d’augmenter DISCOURSE_SIDEKIQ_WORKERS.

Je mettrais cette valeur à peut-être 32, car vous savez que vous disposez de beaucoup de CPU en réserve. Si vous avez encore beaucoup de CPU disponible après que cela ait tourné un moment, n’hésitez pas à l’augmenter davantage.

Vous pouvez probablement le réduire à, disons, 8 ou 12 pour une opération normale.

Assurez-vous d’avoir assez de max_connections pour PostgreSQL. Vous l’avez probablement déjà augmenté puisque vous utilisez un multisite, mais gardez un œil dessus.

2 « J'aime »
4

Merci @supermathie, ça fonctionne maintenant.
J’ai mis à jour la configuration comme suit :

  UNICORN_WORKERS: 8
  UNICORN_SIDEKIQS: 7
  DISCOURSE_SIDEKIQ_WORKERS: 10
  DISCOURSE_DB_POOL: 20

Et j’ai augmenté le CPU à :

8 vCPU
16 Go de mémoire
1 « J'aime »