Bonjour à tous,
Nous avons récemment mis à jour notre serveur CentOS 7 de la version 2.2.2 vers la version 2.7.0.beta4. Depuis cette mise à jour, nous rencontrons des problèmes de latence lors du chargement des pages, en particulier sur celles contenant des bases de données ou des images. La situation est telle que le système est devenu inutilisable.
Toute aide ou recommandation à ce sujet serait grandement appréciée.
Un tas de choses se sont produites au cours des dernières années. Il y a eu un changement de bug qui nécessite le traitement de toutes les images. Je soupçonne que votre serveur est saturé par ce travail. Vous pouvez consulter /sidekiq pour voir la file d’attente.
Quelle est la taille de votre base de données ? Combien d’images ? Que montre Sidekiq ? Vous utilisez bien un SSD, n’est-ce pas ?
C’est un serveur basé sur une machine virtuelle, donc je ne sais pas s’il utilise un SSD ou non.
Je ne vois pas Sidekiq accessible, car ce déploiement n’a pas été effectué par moi, donc je ne sais pas comment y accéder.
Savez-vous comment il a été installé ? Cela ressemble à une installation non standard (sinon, /sidekiq serait à votre disposition si vous étiez administrateur).
Votre meilleure option est d’enquêter sur les raisons de la baisse des performances. De nombreuses tâches en arrière-plan ont été ajoutées au fil des ans (optimisation d’images, rebaking, etc.) et sont probablement en cours d’exécution, consommant ainsi les ressources de votre serveur. Une fois ces tâches terminées, les performances devraient s’améliorer.
Accéder à /sidekiq (en utilisant un compte administrateur !) pour découvrir quelles tâches sont en cours d’exécution est un excellent premier pas.
Le comportement que j’observe avec le serveur est qu’il continue d’afficher cette file d’attente vide, même lorsque j’essaie d’ouvrir un post pour voir s’il est listé. De plus, le portail Sidekiq se fige également lors du chargement du post et ne se rafraîchit qu’une fois le post entièrement chargé.
En outre, une fois chargé, il affiche à nouveau une file d’attente vide. Toute aide ou suggestion serait grandement appréciée.
Si la file d’attente est vide, vous n’avez pas le problème de nombreux jobs en arrière-plan en cours d’exécution. C’est donc quelque chose d’autre.
Avez-vous des plugins ? Avez-vous des composants de thème qui effectuent de nombreuses appels API ?
J’ai posé d’autres questions plus haut.
Quelle est la taille de votre base de données ?
Combien d’images ?
Avez-vous des composants de thème qui effectuent de nombreuses appels API ?
Pourriez-vous m’indiquer comment obtenir ces informations à partir d’une configuration Docker donnée ? Je sais que la dernière sauvegarde fait 135 Mo.
En ce qui concerne les plugins, oui, nous avons les plugins suivants :
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
Je recommande de supprimer le plugin mermaid.
Combien de publications et d’utilisateurs avez-vous ? Quel est votre trafic ?
Quelle quantité de RAM disposez-vous ?
Il semble que vous puissiez très bien fonctionner avec une instance Digital Ocean de 2 Go ; vous pourriez en lancer une pour voir comment cela se passe.
Peut-être y a-t-il un autre problème avec votre serveur ? Est-il à jour ? A-t-il été redémarré récemment ?
D’accord, je vais supprimer cela.
Nous avons environ 4 000 publications et environ 350 utilisateurs.
Le nombre moyen d’utilisateurs connectés simultanément n’est pas très élevé, peut-être 5 à 10 au maximum en moyenne.
Ce serveur a été récemment lancé et dispose de 8 Go de RAM et de 10 Go d’espace d’échange. Il est actuellement en ligne depuis 13 jours. Cependant, les problèmes de performance persistent indépendamment du redémarrage et du temps de fonctionnement.
Il y a clairement un problème avec votre installation ; vous devriez obtenir de bien meilleures performances avec ce matériel.
Essayez d’exécuter un VACUUM explicite sur PostgreSQL. Si vous utilisez l’installation tout-en-un via conteneur :
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Tapez "help" pour obtenir de l'aide.
discourse=# VACUUM ANALYZE;
VACUUM
Combien de workers Unicorn avez-vous configurés dans votre fichier app.yml ?
Vous pouvez demander à Discourse d’ajouter des en-têtes de performance supplémentaires dans les réponses en ajoutant la ligne suivante dans votre section env :
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
Pendant que vous y êtes, vous pouvez activer miniprofiler en suivant ce post.
Cela devrait être largement suffisant.
Je ne me souviens plus si cela avait été suggéré et si vous avez relancé discourse-setup pour ajuster l’utilisation de la mémoire par Discourse, ou si ces paramètres par défaut sont raisonnables compte tenu des autres processus utilisant le serveur.
Si vous n’avez pas réindexé la base de données après la mise à niveau vers PG13, vous pourriez consulter la mise à jour PostgreSQL 13 pour obtenir des informations à ce sujet.
Oh oui, l’absence de statistiques de table (VACUUM ANALYZE) est très probablement la cause ici.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
J’ai donc exécuté ces commandes et défini l’en-tête dans l’environnement également, mais je ne vois pas beaucoup de différence dans le temps de chargement de la page.
Je fais tourner 8 unicorns.
Tu as bien exécuté ces commandes dans PostgreSQL, non ?
Oui, j’ai exécuté docker exec -it -u postgres app psql discourse avant d’exécuter les commandes ci-dessus.
Eh bien, c’est tout à fait étrange. Personne d’autre n’a rencontré de tels problèmes. Vous semblez avoir suffisamment de matériel. Ma seule hypothèse est un problème lié à un proxy inverse (je suppose que vous avez d’autres choses sur la machine ?).
Oui, un autre service basé sur Docker.
Mais rien de vraiment intensif en termes de performances, car cela se serait reflété dans les métriques de performance de la machine.
