Je suis surtout perplexe quant à la façon dont les performances peuvent osciller entre l’exécution d’environ 11 millions et 300 000 tâches par jour en l’espace d’une semaine, avec la même configuration. Une différence de vitesse d’environ 35 fois en termes de tâches par seconde.
Pour l’utilisation du processeur, elle est retombée à environ 15-20 %, ce qui est la normale. Le traitement des tâches se fait à la même vitesse (lente).
Pour clarifier/confirmer, je voulais dire affecter (et non ajouter) certains Sidekiqs exclusivement pour traiter la file d’attente de priorité faible, car il semblait que les tâches de priorité faible puissent être traitées beaucoup plus rapidement et ne souffrent peut-être pas des mêmes goulots d’étranglement. Je spéculais que cela pourrait expliquer pourquoi le nombre de tâches par seconde peut varier de manière si drastique (c’est-à-dire des tâches « faciles » de priorité faible bloquées derrière l’accumulation de la file d’attente par défaut).
Pour clarifier : pensez-vous que les performances de PostgreSQL sont à l’origine de la lenteur d’achèvement des tâches, ou seulement de l’événement de forte utilisation du processeur que j’ai remarqué hier (qui est maintenant revenu à la normale) ?
Mise à jour : J’ai essayé de supprimer la file d’attente à faible priorité et la file d’attente par défaut plusieurs fois, sans aucun impact sur la vitesse, car la file d’attente par défaut repousse immédiatement. J’ai ensuite essayé de supprimer la file d’attente par défaut et d’activer le mode lecture seule. Cela a fait grimper drastiquement le nombre de tâches par seconde, vidant la file d’attente à faible priorité à une vitesse fulgurante (~100 fois plus de tâches par seconde).
Édition : Il semble que même avec une grande file d’attente à faible priorité, la vitesse de traitement reste lente. Si je passe Discourse en mode lecture seule, puis que je vide les files d’attente à faible et à priorité par défaut, le traitement des tâches qui suit reste extrêmement rapide, vidant les tâches planifiées et les files d’attente jusqu’à ce que je désactive le mode lecture seule.
Ma prochaine étape consisterait à identifier précisément le processus qui pose problème en accédant à l’application Discourse et en exécutant htop ou top pour observer les processus les plus gourmands en CPU.
Cela ressemble effectivement à un goulot d’étranglement côté PostgreSQL. Vous pourriez configurer Prometheus pour suivre ses performances et vérifier qu’il dispose de suffisamment de RAM.
Merci pour votre retour @pfaffman Je pense que db_shared_buffers et db_work_mem dans app.yml sont les seuls contrôles pour l’accès à la RAM de PostgreSQL, n’est-ce pas ?
J’ai un peu expérimenté, tant à la hausse qu’à la baisse. Les paramètres actuels dans app.yml sont :
db_shared_buffers : “32768MB”
db_work_mem : “128MB”
Avec une RAM système totale de 128 Go.
J’ai également essayé de modifier max_connections dans /var/discourse/shared/standalone/postgres_data/postgresql.conf, puis de reconstruire Discourse. J’ai testé des valeurs supérieures à la valeur par défaut (100), de 200 à 500. Actuellement réglé à 300. Je ne suis pas sûr que la modification ici change réellement la valeur maximale des connexions.
Je vois ceci dans /var/discourse/templates/postgres.template.yml :
Merci @bartv, en suivant votre suggestion, j’ai surveillé depuis l’intérieur de l’application Discourse via top. Je constate un grand nombre de processus postmaster exécutés par l’utilisateur postgres, avec des niveaux d’utilisation du CPU variables. Les captures d’écran représentent des périodes prolongées avec des statistiques d’utilisation similaires.
Vous devriez vous renseigner sur l’optimisation de PostgreSQL. Ce niveau de performance dépasse un peu l’auto-hébergement typique que l’on voit ici.
Je vous conseillerais d’allouer environ les 3/4 de la RAM à PostgreSQL. Je séparerais certainement les conteneurs de données et de web. Mais vous pourriez avoir besoin d’une configuration PostgreSQL plus complexe pour obtenir les performances dont vous avez besoin.
EDIT : Mais je n’ai pas beaucoup d’expérience avec des bases de données beaucoup plus volumineuses, donc voyez ci-dessous !
J’ai essayé d’exécuter des requêtes, mais j’obtiens cette erreur :
ERROR: pg_stat_statements doit être chargé via shared_preload_libraries
Je suppose que mes modifications apportées au fichier postgresql.conf (/var/discourse/shared/standalone/postgres_data/postgresql.conf) ne fonctionnent pas (j’ai reconstruit Discourse après les avoir effectuées). Est-il possible d’apporter ces modifications via le fichier app.yml ? Ou voyez-vous une erreur dans ce que j’ai fait ?
Reconstruire Discourse effacera ces modifications. Redémarrer le conteneur devrait probablement suffire. (quelque chose comme sv restart postgres à l’intérieur du conteneur pourrait aussi fonctionner).
Je soupçonne que ce n’est pas dans ce fichier que je devrais apporter ces modifications
Peut-être parce que j’utilise uniquement app.yml (et mail-receiver.yml) dans le dossier des conteneurs, sans avoir mis en œuvre l’utilisation de data.yml.
Sans même regarder, il s’agit probablement de /etc/postgres à l’intérieur du conteneur. Vous devrez peut-être également installer la bibliothèque dont il a besoin.
Merci, cela a beaucoup aidé, au début. . Le problème semblait résolu et la file d’attente des tâches fonctionnait très rapidement simplement en augmentant le nombre maximal de connexions dans postgresql.conf. Malheureusement, cela a ralenti à nouveau après environ une journée.
Voici les étapes, au cas où elles seraient utiles à d’autres personnes souhaitant augmenter le nombre maximal de connexions de PostgreSQL.
docker ps
Récupérez l’ID du conteneur, par exemple aaabbbccc123, et remplacez-le dans les commandes ci-dessous :
Copiez le fichier postgresql.conf depuis l’intérieur du conteneur Docker vers le système de fichiers local :
I can’t really read the result though, I think I’ve done something wrong.
total | avg | query
1671.1110420745 | 374.736186677194 | SELECT COUNT(*) FROM ( +
| | SELECT $1 FROM +
| | notifications n +
| | LEFT JOIN topics t ON t.id = n.topic_id +
| | WHERE t.deleted_at IS NULL AND +
| | n.notification_type <> $2 AND +
| | n.user_id = $3 AND +
| | n.id > $4 AND
Maintenant que vous savez ce que vous souhaitez faire, vous pouvez apporter ces modifications en ajoutant un bloc replace dans votre fichier app.yml.
Vous pouvez également exécuter ./launcher enter app et modifier les fichiers directement. Notez toutefois que lors de la reconstruction, ces modifications ne seront pas présentes dans le nouveau conteneur.
Je pense que 
. Le problème semblait résolu et la file d’attente des tâches fonctionnait très rapidement simplement en augmentant le nombre maximal de connexions dans postgresql.conf. Malheureusement, cela a ralenti à nouveau après environ une journée.