Suite à ce post : Slow Page Loads on User Profiles
Nous testons à nouveau notre import vers Discourse maintenant que ces modifications ont été déployées. Il y a une amélioration du chargement des profils (surtout après le chargement initial lorsque les données sont en cache), mais le chargement de certains profils prend toujours entre 5 et 10 secondes. Y a-t-il d’autres actions possibles pour aider dans ce cas ? Voici les requêtes qui semblent poser problème :
Comment avez-vous installé Discourse ?
Installation du conteneur Docker selon les instructions.
Combien de RAM ? Quelle est la taille de votre base de données ?
Cette VM dispose de 8 cœurs et de 32 Go de RAM. Je pense que la base de données fait environ 40 Go, mais je n’en suis pas tout à fait certain pour le moment.
Le chargement lent de la page de profil se produit-il toujours si
vous consultez la page de profil de l’utilisateur en tant qu’utilisateur anonyme (non connecté) ?
vous consultez la page de profil d’un utilisateur régulier par rapport à un utilisateur du personnel ?
Oui, pour les deux. J’ai testé avec un utilisateur standard et en étant déconnecté, et le comportement semble globalement identique.
J’ai tenté une exportation et une restauration (voir : Restore Failing - Check Free Disk Space), mais cela ne semble pas avoir modifié le comportement. Il est également à noter que je rencontre fréquemment une erreur lorsque j’essaie d’afficher ces pages de profil. Cela se produit après plusieurs secondes de tentative de chargement de la page.
La base de données fait désormais 104 Go après la restauration.
Ce sujet concernait principalement un certain nombre de requêtes N+1 que nous avions sur cette route, lesquelles sont toutes corrigées maintenant.
La page de profil comporte effectivement certaines requêtes lourdes, car elle génère un résumé très personnalisé et complet de l’utilisateur, mais une base de données de taille raisonnable devrait pouvoir la rendre en moins de 500 ms.
C’est une grosse base de données pour une petite machine virtuelle. Exécutez-vous tout sur la même VM (Web + DB + Redis) ?
Utilisez-vous la dernière version de PostgreSQL 13 ? Pouvez-vous essayer d’exécuter les tâches de performance optionnelles décrites dans Mise à jour PostgreSQL 13, à la fois le vacuum et le reindex ?
Les utilisateurs concernés sont ceux qui ont un grand nombre de publications. Les pages de profil des utilisateurs avec un faible nombre de publications se chargent immédiatement, comme prévu.
Peut-être dois-je ajuster mes attentes ici. Est-ce que 8 cœurs et 32 Go de RAM sont considérés comme faibles pour Discourse ? (Oui, nous utilisons une installation en conteneur unique.) Sur notre logiciel actuel, nous faisons fonctionner ce forum facilement avec 2 cœurs et 8 Go de RAM.
En ce qui concerne la base de données, il s’agit d’un conteneur fraîchement créé qui a démarré sur la version 13.1. Les opérations de vacuum et de réindexation seraient-elles nécessaires immédiatement après une restauration ?
Le VACUUM est définitivement recommandé pour une base de données de cette taille.
Je les ai lancés peu après votre message. La compression s’est terminée très rapidement, mais la réindexation est toujours en cours, plus de 24 heures après son démarrage. Est-ce normal ? Combien de temps est-ce censé prendre ? Comment puis-je identifier quelle ressource (le cas échéant) est limitée ? Je ne vois pas postmaster utiliser plus de 2 à 4 cœurs la plupart du temps, et il semble y avoir suffisamment de RAM disponible.
Je suis triste de vous annoncer que le reclassement est toujours en cours.
@Falco @codinghorror @pfaffman
@Ghan et moi avons essayé de perfectionner et de nous assurer que l’importation fonctionne pour notre communauté au cours de la dernière année, mais la question qui me vient à l’esprit est la suivante : y a-t-il d’autres considérations que nous devrions prendre en compte lors de l’importation d’une communauté comptant plus de 25 millions de messages ?
Existe-t-il des communautés aussi grandes sur Discourse ?
En examinant la liste publique des clients, j’ai remarqué qu’au moins parmi ceux que je peux voir, personne n’est proche de notre taille. Je peux imaginer qu’il n’y a que des milliers ou des dizaines de milliers d’autres clients que je ne peux pas voir. Nous avons réussi à effectuer notre importation, qui fonctionne de notre côté, mais nous continuons à rencontrer des problèmes tels que le problème de chargement des profils pour les comptes avec un grand nombre de messages et maintenant ce problème de réindexation.
Y a-t-il des conseils que vous pourriez nous donner pour faciliter cette transition ?
J’ai trouvé la commande rake db:stats dans un autre post.
La réindexation est toujours en cours, donc je ne suis pas sûr que ces chiffres soient définitifs à 100 %.
Oui, comme je l’ai mentionné dans un autre sujet, nous avons des instances avec des bases de données de 1 Go et d’autres avec des bases de données de 500 Go. Cependant, ces instances s’exécutent sur des machines virtuelles de tailles très différentes.
Quelles sont les performances du disque sur votre serveur ? Utilisez-vous d’anciens disques durs mécaniques ?
Nous disposons de deux SSD NVMe Intel P3600 de 1,2 To configurés avec une mise en miroir ZFS sur le serveur hôte.
La prochaine chose à vérifier est le réglage de PostgreSQL. Utilisez-vous les valeurs par défaut dans app.yml ?
Oui. Je ne savais pas si le lanceur définissait automatiquement certaines valeurs en fonction des ressources détectées sur la machine hôte ou s’il existait des recommandations pour le réglage. Existe-t-il un guide quelque part pour le réglage de la base de données ?
Il y a quelques commentaires dans le fichier app.yml, bien qu’il soit vraiment optimisé pour les petits sites auto-hébergés. Vous voudrez probablement augmenter les paramètres qui s’y trouvent (je ne me souviens pas de leurs noms exacts). Vous devrez consulter des sources plus générales sur PostgreSQL pour obtenir plus d’informations.
Ce n’est pas que Discourse ne puisse pas gérer une communauté de votre taille, c’est juste différent de la gestion d’une plus petite, et un peu plus difficile.
Merci, je vais certainement jeter un coup d’œil. Je ne connais pas bien Postgres, mais j’espère que les mêmes principes s’appliquent après avoir utilisé MySQL pendant des années.
Tout à fait. J’ai l’impression que dès que nous aurons identifié les types de modifications à apporter, tout se passera beaucoup plus fluidement.
