Nachtrag zu diesem Beitrag: Slow Page Loads on User Profiles
Wir testen unseren Import nach Discourse erneut, da diese Änderungen bereitgestellt wurden. Die Profil-Ladezeit hat sich verbessert (insbesondere nach dem initialen Laden, wenn die Daten im Cache sind), aber das Laden einiger Profile dauert immer noch 5–10 Sekunden. Gibt es noch weitere Maßnahmen, die wir ergreifen können? Diese Abfragen scheinen das Problem zu verursachen:
Wie hast du Discourse installiert?
Docker-Container gemäß den Anweisungen installieren.
Wie viel RAM? Wie groß ist Ihre Datenbank?
Diese VM verfügt über 8 Kerne und 32 GB RAM. Ich schätze, die Datenbank hat etwa 40 GB, aber ich bin im Moment nicht zu 100 % sicher.
Tritt das langsame Laden der Benutzerprofilseite auch weiterhin auf,
wenn Sie die Benutzerprofilseite als anonymer (nicht angemeldeter) Benutzer aufrufen?
wenn Sie das Profil eines regulären Benutzers im Vergleich zu einem Mitarbeiter aufrufen?
Ja, beides. Ich habe es mit einem regulären Benutzer getestet und mich abgemeldet, und das Verhalten scheint weitgehend gleich zu sein.
Ich habe einen Export und eine Wiederherstellung versucht (siehe Restore Failing - Check Free Disk Space), aber das hat das Verhalten nicht geändert. Es ist auch erwähnenswert, dass ich häufig einen Fehler erhalte, wenn ich versuche, diese Profilseiten anzuzeigen. Dieser tritt nach einigen Sekunden des Ladens der Seite auf.
Die Datenbank hat nach der Wiederherstellung jetzt 104 GB.
Dieses Thema handelte hauptsächlich von einer Reihe von N+1-Abfragen, die wir auf dieser Route hatten, die jetzt alle behoben sind.
Die Profilseite hat zwar einige aufwändige Abfragen, da sie eine sehr personalisierte und vollständige Zusammenfassung des Benutzers ausgibt, aber eine Datenbank mit angemessener Größe sollte in der Lage sein, sie in unter 500 ms darzustellen.
Das ist eine große Datenbank für eine kleine VM. Betreiben Sie alles in derselben VM (Web+DB+Redis)?
Betreiben Sie die neueste Version von PostgreSQL 13? Können Sie versuchen, die optionalen Leistungsaufgaben auszuführen, die unter PostgreSQL 13-Update beschrieben sind, sowohl vacuum als auch reindex?
Die Benutzer, die das Problem haben, sind diejenigen mit vielen Beiträgen. Profilseiten von Benutzern mit wenigen Beiträgen laden erwartungsgemäß sofort.
Vielleicht muss ich meine Erwartungen hier anpassen. Gelten 8 Kerne und 32 GB RAM als wenig für Discourse? (Ja, wir betreiben es als Single-Container-Installation.) Auf unserer aktuellen Software läuft dieses Forum problemlos mit 2 Kernen und 8 GB RAM.
Was die Datenbank betrifft: Es ist ein neu erstellter Container, der mit Version 13.1 gestartet wurde. Wären VACUUM und Re-Indexierung direkt nach einer Wiederherstellung notwendig?
Bei einer Datenbank dieser Größe ist VACUUM definitiv empfehlenswert.
Ich habe diese kurz nach deinem Beitrag gestartet. Das Vakuum war sehr schnell abgeschlossen, aber die Neuindexierung läuft immer noch, mehr als 24 Stunden nach dem Start. Ist das normal? Wie lange soll das dauern? Wie kann ich feststellen, welche Ressource (falls vorhanden) begrenzt ist? Ich sehe, dass Postmaster die meiste Zeit nicht mehr als 2–4 Kerne nutzt, und es scheint ausreichend RAM verfügbar zu sein.
Ich muss leider mitteilen, dass der Reindex-Vorgang noch läuft.
@Falco @codinghorror @pfaffman
@Ghan und ich haben uns im vergangenen Jahr darum bemüht, den Import für unsere Community perfektioniert und sichergestellt, dass er funktioniert. Doch die Frage, die mich beschäftigt, lautet: Gibt es weitere Aspekte, die wir beim Import einer Community mit über 25 Millionen Beiträgen berücksichtigen sollten?
Gibt es auf Discourse überhaupt Communities dieser Größenordnung?
Bei einem Blick auf die öffentliche Liste der Kunden habe ich festgestellt, dass – zumindest von denjenigen, die ich einsehen kann – niemand in unserer Größenordnung ist. Ich kann mir zwar vorstellen, dass es Tausende oder Zehntausende weiterer Kunden gibt, die ich nicht sehen kann. Unser Import ist erfolgreich abgeschlossen und funktioniert auf unserer Seite, doch wir stoßen immer wieder auf Probleme wie die Profil-Ladezeit bei Konten mit einer großen Anzahl von Beiträgen und nun dieses Problem mit der Neuparametrierung (Re-Indexing).
Gibt es Ratschläge, die uns helfen könnten, diesen Übergang reibungsloser zu gestalten?
Ich habe den Rake-Befehl db:stats aus einem anderen Beitrag gefunden.
Die Neuindizierung läuft noch, daher bin ich mir nicht sicher, ob diese Zahlen zu 100 % final sind.
Ja, wie ich in einem anderen Thema bereits sagte, gibt es Instanzen mit 1-GB-Datenbanken und Instanzen mit 500-GB-Datenbanken. Allerdings laufen diese Instanzen auf völlig unterschiedlich großen VMs.
Wie ist die Festplattenleistung auf deinem Server? Verwendet er alte mechanische Festplatten?
Wir verfügen über zwei Intel P3600 NVMe SSDs mit jeweils 1,2 TB, die auf dem Host-Server in einem ZFS-Mirror konfiguriert sind.
Als Nächstes sollte die PostgreSQL-Optimierung überprüft werden. Verwendest du die Standardeinstellungen in der app.yml?
Ja. Ich war mir nicht sicher, ob der Launcher automatisch einige Werte basierend auf den auf dem Host-System verfügbaren Ressourcen setzt oder ob es empfohlene Richtlinien für die Optimierung gibt. Gibt es irgendwo einen Leitfaden zur Optimierung der Datenbank?
Es gibt einige Anmerkungen zur app.yml, die jedoch primär für kleinere selbst gehostete Sites optimiert ist. Wahrscheinlich möchten Sie die dortigen Einstellungen erhöhen (ich kann mich nicht mehr an die genauen Namen erinnern). Für weitere Informationen müssen Sie sich etwas allgemeiner zu PostgreSQL informieren.
Es liegt nicht daran, dass Discourse eine Community Ihrer Größe nicht bewältigen kann, sondern einfach anders ist als der Betrieb einer kleineren und etwas schwieriger.
Danke, ich werde mir das auf jeden Fall ansehen. Ich bin mit Postgres nicht vertraut, aber hoffentlich gelten die gleichen Prinzipien, die ich über Jahre beim Betrieb von MySQL gelernt habe.
Definitiv. Ich habe das Gefühl, dass es viel reibungsloser laufen wird, sobald wir Klarheit darüber haben, welche Änderungen vorgenommen werden müssen.
