Ah, verstehe, das wird bei dieser Abfrage Schwierigkeiten bereiten. Nach dem Update auf die neueste Version könntest du bitte die Abfrage aus dem MiniProfiler extrahieren, eine explain analyze darauf ausführen und uns die Ergebnisse mitteilen?
Auf Meta (RDS db.r6g.large, 30 GB) sieht das so aus:
Ich werde versuchen, EXPLAIN ANALYZE erneut auszuführen, aber wir konnten diese Abfrage bisher nicht erfolgreich abschließen.
Update: Dieser Commit hat nichts geändert. Die Datenbank läuft nach dem Update weiterhin ständig mit über 95 % und beendet alle alten laufenden Abfragen. In der Beta 4 lief sie für dieses Forum stabil bei 20–30 %. Wir haben bereits eine automatische Vakuierung und eine Schema-Neuindizierung durchgeführt.
Wie können wir diese Funktion deaktivieren? Es scheint nicht richtig zu sein, eine größere Datenbankinstanz zu verwenden, um dieses Problem zu lösen. Angesichts der Tatsache, dass die Abfrage vor diesem Update einwandfrei lief, scheint bei der Berechnung dieser Abfrage etwas nicht zu stimmen.
Die Abfrage konnte nach ca. 21 Minuten abgeschlossen werden.
Zusätzlich sei angemerkt, dass wir PG 10.17 verwenden, da unsere Ausgaben offenbar recht stark voneinander abweichen.
Wir haben das Problem vorübergehend durch einen Monkey-Patch behoben, indem wir alle */private-messages-all/*-Routen auf */private-messages/* umgeleitet haben. Das Ergebnis ist, dass „Alle Postfächer" denselben Inhalt wie „Persönlich" anzeigt, aber wir müssen uns zumindest nicht ständig mit 100 % CPU-Auslastung auseinandersetzen.
Monkey-Patch-Code:
# name: discourse-private-messages-perf-hotfix
# version: 0.0.1
# authors:
# Voranstellen, um bestehende Routen zu überschreiben
Discourse::Application.routes.prepend do
scope path: nil, constraints: { format: /(json|html|\*\/\*)/ } do
scope "/topics", username: RouteFormat.username do
# Alle */private-messages-all/*-Routen stattdessen auf */private-messages/* umleiten (persönliche Nachrichten)
# Ersteres ist teuer, letzteres ist günstig; potenziell erhebliche Einsparungen der Datenbank-CPU-Auslastung
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
CPU-Auslastung unserer Forendatenbank nach dem Bereitstellen des oben genannten Monkey-Patches:
@tgxworld Du solltest dir noch einmal ansehen, was genau die */private-messages-all/*-Routen tun. Offensichtlich liegt ein Fehler in der Implementierung vor; sie ist für große Forendatenbanken nicht effizient genug. Entweder wird nicht der richtige Datenbankindex verwendet, oder die Abfragegenerierung führt zu extrem teuren Abfragen (insbesondere bei PSQL 10, bei 12/13 bin ich mir nicht sicher).
Die aktuelle Implementierung hat unser Forum praktisch lahmgelegt: Die CPU-Auslastung stieg von ca. 15 % auf konstant 100 %, was zu langsamer Leistung bei allen anderen Forenfunktionen führte. Ich sehe keinen Grund, warum Abfragen für Persönliche/Gruppen-Postfächer unter 50 ms dauern, während die für „Alle Postfächer" über 20 Minuten benötigen.
Du kannst den von @forkythetoy weiter oben geposteten Analyze-Dump verwenden, um den vorherigen Lauf von über 20 Minuten zu sehen.
@Falco Ich habe gerade bemerkt, dass du unser Thema hier zusammengeführt hast, aber es scheint sich eigentlich um einen anderen Endpunkt zu handeln. Dieser Fehlerbericht betrifft den Endpunkt private-message-topic-tracking-state, doch wir sprechen über */private-messages-all/*. Das könnte hier für einige Verwirrung gesorgt haben, dafür entschuldige ich mich. (Ich habe zunächst auf diesen verlinkt, was möglicherweise zu dem Missverständnis geführt hat.)
Der Endpunkt private-message-topic-tracking-state ist auf unserem Forum schnell, daher liegt das Problem bei uns nicht daran.
Bei uns dauert dieser Vorgang etwa 200–300 ms an Datenbankzeit. Etwas länger als man vielleicht erwartet, aber immer noch im normalen Bereich, ja.
Wir nutzen jedoch Postgres 13.
@Hooksmith Ich habe eine Lösung auf dem Weg.
@Hooksmith @forkythetoy Werdet ihr auf PG 13 aktualisieren können? Das ist derzeit die Mindestversion, die Discourse erfordert. Außerdem fällt es mir schwerer, Abfragepläne zu vergleichen, wenn die Abfragen nicht mit derselben PG-Version ausgeführt werden.
Ich musste dies rückgängig machen, da sich die Leistung der neuen Abfrage zwischen den Benutzern zu stark unterscheidet.
@blattersturm Siehst du immer noch, dass die Performance des Topic-Tracking-Zustands langsam ist?
Unklar, seit ein paar Tagen wurde kein Upgrade mehr durchgeführt. Gibt es Commits, die man einziehen sollte, um zu sehen, ob sich etwas verbessert hat?
Nein, nichts hat sich geändert, aber wenn du mir eine EXPLAIN ANALYZE für die Abfrage geben kannst, wäre das hilfreich.
Beachten Sie, dass wir aufgrund von Leistungsbedenken vorerst alle Posteingänge wiederhergestellt haben.
Dieses Thema wurde automatisch nach 14 Tagen geschlossen. Neue Antworten sind nicht mehr erlaubt.
