Ah, je vois, cela aura du mal avec cette requête. Après la mise à jour vers la dernière version, pouvez-vous s’il vous plaît extraire la requête de mini_profiler, exécuter un explain analyze dessus et nous la partager ?
Sur Meta (RDS db.r6g.large 30 Go), cela ressemble à ceci :
Je vais essayer d’exécuter explain analyze à nouveau, mais nous n’avons pas encore réussi à faire aboutir cette requête.
Mise à jour : ce commit n’a rien changé. La base de données reste constamment à plus de 95 % après la mise à jour et tue toutes les anciennes requêtes en cours d’exécution. À la version beta4, elle fonctionnait de manière stable entre 20 et 30 % pour ce forum. Nous avons déjà exécuté un auto-vacuum et une réindexation du schéma.
Comment désactiver cette fonctionnalité ? Il ne semble pas logique de passer à une instance de base de données plus grande pour résoudre ce problème. Il y a manifestement un problème dans la façon dont cette requête est calculée, étant donné qu’elle fonctionnait parfaitement avant cette mise à jour.
La requête a réussi à se terminer après environ 21 minutes
Il est également à noter que nous utilisons PG 10.17, car nos résultats semblent différer considérablement.
Nous avons appliqué un correctif de type “monkey patch” en réorientant temporairement toutes les routes */private-messages-all/* vers */private-messages/*. Le résultat est que “Toutes les boîtes de réception” affiche le même contenu que “Personnel”, mais au moins, nous n’avons plus à gérer une utilisation du processeur à 100 % en permanence.
Code du monkey patch :
# name: discourse-private-messages-perf-hotfix
# version: 0.0.1
# authors:
# Préfixer pour remplacer les routes existantes
Discourse::Application.routes.prepend do
scope path: nil, constraints: { format: /(json|html|\\*\\/\\*)/ } do
scope "/topics", username: RouteFormat.username do
# Réorienter toutes les routes */private-messages-all/* vers */private-messages/* (messages personnels)
# La première est coûteuse, la seconde est peu coûteuse, ce qui peut économiser une utilisation significative du CPU de la base de données
get "private-messages-all/:username" => "list#private_messages", as: "topics_private_messages_override", defaults: { format: :json }
get "private-messages-all-sent/:username" => "list#private_messages_sent", as: "topics_private_messages_sent_override", defaults: { format: :json }
get "private-messages-all-new/:username" => "list#private_messages_new", as: "topics_private_messages_new_override", defaults: { format: :json }
get "private-messages-all-unread/:username" => "list#private_messages_unread", as: "topics_private_messages_unread_override", defaults: { format: :json }
get "private-messages-all-archive/:username" => "list#private_messages_archive", as: "topics_private_messages_archive_override", defaults: { format: :json }
end
end
end
Utilisation du CPU de notre base de données de forum après le déploiement du monkey patch ci-dessus :
@tgxworld Vous devriez revoir ce que font les routes */private-messages-all/*. Il est clair qu’il y a un problème dans leur implémentation ; elles ne sont pas assez efficaces pour les grandes bases de données de forums. Soit l’implémentation n’utilise pas le bon index de base de données, soit la génération de requêtes aboutit à des requêtes extrêmement coûteuses (en particulier sur PSQL 10, je ne suis pas sûr pour les versions 12/13 ?).
L’implémentation actuelle a pratiquement paralysé notre forum, faisant passer l’utilisation du CPU de ~15 % à 100 % constant et causant des ralentissements sur toutes les autres fonctionnalités du forum. Je ne vois aucune raison pour laquelle les requêtes pour les boîtes de réception Personnelles / de groupe prennent <50 ms alors que celles pour “Toutes les boîtes de réception” prennent plus de 20 minutes à s’exécuter.
Vous pouvez utiliser le dump d’analyse que @forkythetoy a publié juste au-dessus pour voir la requête qui a duré plus de 20 minutes auparavant.
@Falco, je viens de remarquer que tu as fusionné notre sujet ici, mais cela semble en réalité concerner un autre point de terminaison. Ce rapport de bug porte sur le point de terminaison private-message-topic-tracking-state, alors que nous parlons de */private-messages-all/*. Cela pourrait expliquer une partie de la confusion ici, toutes mes excuses pour cela. (J’ai initialement lié à celui-ci, ce qui a peut-être déclenché le malentendu)
Le point de terminaison private-message-topic-tracking-state est rapide sur notre forum, donc ce n’est pas le problème pour nous.
Pour nous, cette requête prend environ 200 à 300 ms de temps de base de données. Un peu plus long que ce à quoi l’on pourrait s’attendre, mais toujours dans des limites normales, oui.
Nous utilisons toutefois Postgres 13.
@Hooksmith J’ai une correction en cours de traitement
@Hooksmith @forkythetoy Pourrez-vous mettre à jour vers PG 13 ? C’est la version minimale requise par Discourse pour le moment. De plus, il m’est plus difficile de comparer les plans d’exécution lorsque les requêtes ne sont pas exécutées avec la même version de PG.
J’ai dû annuler cette modification car les performances de la nouvelle requête varient trop d’un utilisateur à l’autre.
@blattersturm Tu constates toujours que les performances de l’état de suivi des sujets sont lentes ?
Hésitant, je n’ai pas effectué de mise à niveau depuis quelques jours. Y a-t-il des commits à intégrer pour voir si des améliorations ont été apportées ?
Non, rien n’a changé, mais si tu peux me fournir un EXPLAIN ANALYZE de la requête, ce serait utile.
Notez que nous avons rétabli les boîtes de réception globales pour le moment en raison de préoccupations liées aux performances.
Ce sujet a été automatiquement fermé après 14 jours. De nouvelles réponses ne sont plus autorisées.
