Hallo zusammen,
wir haben unseren CentOS-7-Server von 2.2.2 auf 2.7.0.beta4 aktualisiert und seitdem treten bei der Seitenladung Latenzen auf. Dies betrifft insbesondere Seiten mit Datenbank- oder Bildinhalten, bis hin zur Unbrauchbarkeit.
Jegliche Hinweise dazu wären sehr willkommen.
In den letzten Jahren ist einiges passiert. Es gab eine Bug-Änderung, die die Verarbeitung aller Bilder erfordert. Ich vermute, dass dein Server mit dieser Arbeit völlig überlastet ist. Du kannst dir unter /sidekiq die Warteschlange ansehen.
Wie groß ist deine Datenbank? Wie viele Bilder gibt es? Was zeigt Sidekiq an? Du verwendest doch SSD, oder?
Es handelt sich um einen VM-basierten Server, daher bin ich mir nicht sicher, ob es sich um eine SSD handelt.
Ich kann Sidekiq nicht einsehen, da diese Bereitstellung nicht von mir durchgeführt wurde, und ich bin mir nicht sicher, wie ich darauf zugreifen kann.
Weißt du, wie es installiert wurde? Es klingt so, als wäre es keine Standardinstallation (sonst stünde /sidekiq dir als Admin zur Verfügung).
Ihr bester nächster Schritt besteht darin, herauszufinden, warum die Leistung nachgelassen hat. Im Laufe der Jahre wurden eine ganze Menge von Hintergrundjobs hinzugefügt (Bildoptimierung, Neuberechnung usw.), die wahrscheinlich jetzt laufen und Ihre Serverressourcen beanspruchen. Sobald diese abgeschlossen sind, sollte sich die Leistung verbessern.
Der Zugriff auf /sidekiq (mit einem Administratorkonto!), um herauszufinden, welche Jobs laufen, ist ein hervorragender erster Schritt.
Okay, ich habe also Zugriff auf Sidekiq erhalten. Könnt ihr mir bitte helfen, das zu verstehen und Optimierungen vorschlagen? Ich stecke hier aufgrund dieser Leistungsprobleme ziemlich in der Klemme.
Das Verhalten, das ich auf dem Server beobachte, ist, dass die leere Warteschlange weiterhin angezeigt wird, selbst wenn ich versuche, einen Beitrag zu öffnen, um zu sehen, ob er aufgelistet wird. Das Sidekiq-Portal friert ebenfalls ein, wenn ein Beitrag geladen wird, und aktualisiert sich erst, nachdem der Beitrag vollständig geladen ist.
Außerdem wird die Warteschlange erneut als leer angezeigt, sobald der Beitrag geladen ist. Jegliche Hilfe oder Vorschläge wären sehr willkommen.
Wenn die Warteschlange leer ist, liegt das Problem nicht daran, dass viele Hintergrundjobs laufen. Es muss also etwas anderes sein.
Haben Sie Erweiterungen? Verwenden Sie Theme-Komponenten, die viele API-Aufrufe tätigen?
Ich habe oben noch weitere Fragen gestellt.
Wie groß ist Ihre Datenbank?
Wie viele Bilder?
Haben Sie Theme-Komponenten, die viele API-Aufrufe auslösen?
Können Sie mir bitte mitteilen, wie ich diese Informationen in einer Docker-basierten Einrichtung herausfinden kann? Ich weiß, dass das letzte Backup 135 MB groß ist.
Was die Plugins betrifft: Ja, wir haben folgende Plugins installiert:
- 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
Ich empfehle, das Mermaid-Plugin zu entfernen.
Wie viele Beiträge und Benutzer hast du? Wie ist der Traffic?
Wie viel RAM ist vorhanden?
Es sieht so aus, als würdest du mit einem 2-GB-DigitalOcean-Droplet gut zurechtkommen; du könntest einen solchen erstellen und testen, wie er funktioniert.
Vielleicht gibt es ein anderes Problem mit deinem Server? Ist er auf dem neuesten Stand? Wurde er kürzlich neu gestartet?
Ok, ich werde das entfernen.
Wir haben ca. 4.000 Beiträge und etwa 350 Nutzer.
Die durchschnittliche Anzahl gleichzeitig angemeldeter Nutzer ist nicht sehr hoch, maximal vielleicht 5–10 im Durchschnitt.
Dieser Server wurde vor kurzem hochgefahren und verfügt über 8 GB RAM sowie 10 GB Swap-Speicher. Er läuft derzeit erst seit 13 Tagen. Die Leistungsprobleme treten jedoch unabhängig von Neustarts und der Laufzeit auf.
Bei Ihrer Installation ist definitiv etwas falsch; mit dieser Hardware sollten Sie deutlich bessere Leistung erzielen.
Versuchen Sie, PostgreSQL einen expliziten VACUUM-Befehl ausführen zu lassen. Wenn Sie die All-in-One-Container-Installation verwenden:
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Type "help" for help.
discourse=# VACUUM ANALYZE;
VACUUM
Wie viele Unicorn-Worker sind in Ihrer app.yml konfiguriert?
Sie können Discourse auffordern, zusätzliche Performance-Header in den Antworten zu setzen, indem Sie im Abschnitt env Folgendes hinzufügen:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
Im Übrigen können Sie Miniprofiler aktivieren, indem Sie diesen Beitrag befolgen.
Das sollte völlig ausreichen.
Ich kann mich nicht erinnern, ob vorgeschlagen wurde, dass du discourse-setup erneut ausführst, um die Speichernutzung von Discourse anzupassen, oder ob diese Standardwerte angesichts dessen, was sonst noch den Server belegt, angemessen sind.
Falls du nach dem Upgrade auf PG13 die Datenbank nicht neu indiziert hast, lohnt sich ein Blick auf PostgreSQL 13 Update für weitere Informationen dazu.
Oh ja, das Fehlen von Tabellstatistiken (VACUUM ANALYZE) ist hier höchstwahrscheinlich die Ursache.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
Ich habe diese Befehle ausgeführt und den Header in der Umgebungsvariablen gesetzt, aber ich sehe kaum einen Unterschied bei der Ladezeit der Seite.
Ich verwende 8 Unicorn-Prozesse.
Du hast diese Befehle in PostgreSQL ausgeführt, oder?
Ja, ich habe docker exec -it -u postgres app psql discourse ausgeführt, bevor ich die oben genannten Befehle durchgeführt habe.
Nun, das ist alles sehr seltsam. Niemand sonst hat solche Probleme. Du scheinst ausreichend Hardware zu haben. Meine einzige Vermutung ist ein Problem mit einem Reverse-Proxy (du hast vermutlich noch andere Dinge auf dem Server?).
Ja, ein weiterer auf Docker basierender Dienst.
Aber überhaupt nichts, was leistungsintensiv wäre, da sich dies in den Leistungsmetriken der Maschine zeigen würde.
