Wir haben alle angepassten Werte wieder auf die Standardwerte zurückgesetzt und auf Version 2.6.0 beta4 aktualisiert. Die Spiele finden am Donnerstag und Freitag statt, sodass wir noch diese Woche eine gute Testabdeckung haben werden.
Leider löst der Fix das Problem nicht. Wir hatten ein moderat aktives Spiel mit 600 Nachrichten. Mehrere Einfrier-Vorfälle wurden sowohl durch meine eigenen Tests als auch durch unsere Mitglieder beobachtet. Diese korrelieren mit Spielereignissen, also Aktivitätsspitzen.
- Die CPU-Auslastung lag weit innerhalb der Grenzen, mit einem Spitzenwert von etwa 60 % und einer durchschnittlichen Last von rund 30 %.
- Es handelt sich definitiv um ein Problem auf Client-Seite. Wenn das Chat-Thema einfriert, kannst du zur Indexseite gehen und dort die Anzahl der ungelesenen Beiträge sehen. Gehe zurück zum Thema, und die Beiträge werden wieder sichtbar.
Was mich immer noch verblüfft und in diesem Thema nicht behandelt wird, ist die Frage, was sich seit v2.3 geändert hat, das dieses Problem nicht hatte?
Die großen Updates 2.4 und 2.5 fanden während unserer (durch COVID verlängerten) Nebensaison statt, daher hat niemand etwas bemerkt. Das Einfrieren war jedoch sofort beim allerersten Vorsaison-Testspiel offensichtlich.
Gibt es Parameter-Hacks, die wir für morgen ausprobieren könnten? Es wird ein heißes Derby und ein Auswärtsspiel, also wird die Community in Flammen stehen.
In unserem Fall hat das Deaktivieren des Plugins „Wer ist online“ und das Deaktivieren der Datei zur Ratenbegrenzung (und ich habe gelesen, dass es mit der neueren Beta einige Verbesserungen gab) bei uns den Ausschlag gegeben.
Wir haben mittlerweile auch ab und zu Fußballspiele, bei denen 300 oder etwas mehr Nutzer gleichzeitig in dasselbe Thema klicken und schreiben. Bei unserem letzten Spiel lief es deutlich besser.
Bist du auf der neuesten Version mit dem kürzlich veröffentlichten Fix?
Bitte, bitte aktualisieren auf „Tests bestanden“. Ich habe seit der Beta viel verfeinert.
Ja, die neueste Beta-Version (also die der letzten 48 Stunden).
Aktualisiert. Bericht folgt.
Leider immer noch kein Durchkommen. Klar – das Spiel war mit 950 Nachrichten sehr hitzig. Ich habe GAnalytics im Auge behalten: Rund 250 Personen waren dabei, 119 haben gepostet. Wie zuvor wurden mehrere Einfrieren beobachtet. Der Message-Bus hat einige 429-Fehler zurückgegeben, mit den Meldungen „Sie haben diese Aktion zu häufig ausgeführt, bitte warten Sie X Minuten“.
Die CPU-Auslastung erreichte einen Spitzenwert von etwa 70 %, und die Wartezeit (wa) war praktisch null. Obwohl die Aktivität hoch war, sind wir immer noch nicht in der Lage, das zu liefern, wozu die Hardware fähig wäre.
Könntest du mir bitte eine Frage beantworten, die mich schon lange beschäftigt: Was wurde nach Version 2.3 implementiert, das dies verursacht, und welchen Mehrwert soll es bringen?
Die Implementierung ist im Großen und Ganzen dieselbe wie immer, außer dass wir jetzt globale App-Ratenbegrenzungen haben, die konfigurierbar sind. Sie können diese erhöhen, wenn Sie möchten – das könnte jedoch zu einem vollständigen Zusammenbruch führen, ich weiß es nicht.
Ich verstehe nicht, was Sie mit „Einfrieren
Welchen Wert hat der Parameter db_shared_buffers? Anfangs hatten wir bei nur den empfohlenen 25 % des gesamten RAMs häufig ein „instabiles
Okay, dieses Phänomen ist in einer Produktionsumgebung (Spielchats) schwer zu überwachen, da jedes Spiel anders ist – unterschiedliche Anzahl kritischer Ereignisse, unterschiedliche Gegner, unterschiedliche emotionale Aufladung und so weiter.
Aus unserer Sicht besteht das Problem darin, dass unsere maximale Leistungsfähigkeit seit Version 2.3 gesunken ist. Das ist der entscheidende Punkt. Jeder Server hat seine Grenzen, aber wir erhalten nun weniger Leistung aus unseren Servern als im März, als wir Version 2.3 ausführten. Basierend auf einer groben Überwachung des Backends erreicht der Server keine 100 % Auslastung oder Kapazität.
Was die Endnutzer sehen, ist, dass der Chat-Verlauf einfach stoppt, ohne dass eine UI-Anzeige darüber informiert, was los ist. Das führt zu Verwirrung.
Ich bin ziemlich sicher, dass die Änderungen in den bestandenen Tests die Situation verbessert haben, aber die Leistung oder maximale Ausgabe ist immer noch deutlich niedriger als bei Version 2.3.
Wir haben einen VPS mit 6 schnellen Kernen und 16 GB RAM. Die Anzahl der Unicorn-Prozesse liegt bei 12, die RAM-Puffer-bezogenen Einstellungen sind auf den Standardwerten.
Ich denke, der beste nächste Schritt ist, eine historische Überwachung Ihres Systems einzurichten, damit wir herausfinden können, wo der Engpass liegt, da wir festgestellt haben, dass es nicht die CPU-Zeit ist. Es ist immer möglich, dass Sie Ihre Netzwerkverbindung voll auslasten!
zusätzlich zu herkömmlichen Servermetriken wie node-exporter.
Wenn dies der Fall ist und Sie das System stärker auslasten möchten:
-
Sie können die Ratenbegrenzungen reduzieren. Dies ermöglicht es den Benutzern, aggressiver mit Discourse zu interagieren. Konkret könnten Sie
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEundDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDSverdoppeln. -
Sie können versuchen, mehr Unicorn-Worker hinzuzufügen.
Dies ist vorübergehend während einer Überlastung zu erwarten, aber die Funktionen sollten sich automatisch erholen, sobald die Last sinkt.
Meine Vermutung ist, dass dies alles mit den Ratenbegrenzungen zusammenhängt. Diese sind neu und dienen dem Schutz des Servers. Es scheint, als würde Ihr Server bewusst geschützt werden.
Wir haben ein Spiel mit folgendem Konfiguration versucht:
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…und als die Emotionen in der dritten Periode zu steigen begannen, verschlechterte sich die Lage. Wir stießen an die Grenzen unserer Server, Benutzer wurden ständig in den abgemeldeten Modus versetzt, und der Spiel-Chat frierte ebenfalls ein.
Es war vier Jahre lang eine große Erfolgsgeschichte, doch jetzt befinden wir uns in einer sehr schwierigen Situation. Der Sprung auf die nächste Stufe der VPS-Kapazität würde uns in die Preiskategorie von etwa 160 € pro Monat bringen, was für eine Hobby-Seite eine Herausforderung darstellt. Dabei geht es gar nicht um riesige Nutzerzahlen – 116 Personen haben während des Spiels über 800 Nachrichten verfasst.
Auch die Ideologie „Keine Chats
Mein Forum ist ein Fußballforum, und ich habe ähnliche Herausforderungen erlebt.
Im Grunde stellte ich fest, dass es sich um ein Skalierbarkeitsproblem handelt.
Die Probleme traten bei mir auf verschiedenen Ebenen auf.
Digital Ocean:
1 CPU, 1 GB = 30–40 Nutzer in einer Chat-ähnlichen Situation
2 CPUs, 2 GB = 70–80 Nutzer in einer Chat-ähnlichen Situation
4 CPUs, 8 GB = problemlos für 120 Nutzer und 1000 Beiträge innerhalb von 2 Stunden. Die Grenze wurde nicht erreicht.
Ich teste derzeit verschiedene Stufen bei Hetzner (Spiegelwebsite), da sie günstiger ist, doch das lief nicht so reibungslos wie erhofft.
Meine bisherigen Erfahrungen:
3 CPUs (CPX 21 mit AMD-Chip) und 4 GB = Probleme mit 20 Nutzern
2 CPUs (Intel) und 8 GB = keine Probleme mit 20 Nutzern.
Ich werde gleich unter Spielbedingungen einen Test mit 80 bis 100 gleichzeitigen Nutzern durchführen.
Als ich die CPU-Auslastung bei Digital Ocean betrachtete, schien diese selbst unter Last zu allen Zeiten und auf allen Stufen relativ niedrig zu sein (<50 %).
Bei der Betrachtung der CPU-Auslastung bei Hetzner mit dem AMD-Chip sah ich eine mediane Auslastung von etwa 60 %, aber alle paar Minuten einen kurzen Spike bis zu 300 % der CPU-Auslastung. Dies trat bei dem Intel-Chip nicht auf.
Was das bedeutet, weiß ich nicht. Ich vermute, dass das CPU-Monitoring bei Hetzner besser funktioniert (Erfassung kurzer Spikes). Insgesamt scheint die CPU-Auslastung jedoch gut ausbalanciert zu sein. Auf den ersten Blick scheint Digital Ocean besser mit Spikes umzugehen, aber ich sollte nach diesem Wochenende mehr Informationen über Hetzner haben.
Ich sollte noch hinzufügen, dass bei dem Hetzner-Test das ‘Whose Online’-Plugin keine Auswirkung hatte.
Das ‘Discourse Quick Messages’-Plugin schien jedoch nachteilig zu sein.
Das nächste Spiel ist morgen fällig. Wir haben unsere eigenen Workarounds entfernt und testen diese Einstellungen.
Außerdem habe ich, als totale Fernschuss-Idee, die db_shared_buffers von 4 GB (25 %) auf 6 GB (37,5 %) erhöht. Zudem habe ich die Zeile mit db_work_mem 40 MB in der app.yml wieder aktiviert (dies ist übrigens eine sehr vage dokumentierte Option, die dem Administrator dennoch als eine Art Verbesserungsmöglichkeit präsentiert wird).
Ich erwarte nicht mehr, eine Lösung für das Problem zu finden, sondern nur eine bessere Schadensbegrenzung – also eine Parameterkombination, die die geringsten negativen Auswirkungen auf die Benutzererfahrung hat. In der Zwischenzeit muss ich herausfinden, wie wir unsere Hosting-Ressourcen weiter erhöhen können.
Frage an @sam und andere Entwickler.
Wie wirkt sich die ständig wachsende Größe der Datenbank auf diesen Anwendungsfall aus, bei dem Nutzer über mehrere Stunden hinweg ein einzelnes Thema intensiv nutzen?
Ich habe mir die historischen Aktivitäten im Spiel-Chat angesehen und festgestellt, dass wir bereits 2017 Spiele mit enormen Statistiken hatten, als unser Server nur einen Bruchteil der heutigen Ressourcen verfügte. Es gab Spiele, bei denen die Anzahl der Beiträge 1600 Nachrichten von 165 Nutzern erreichte, ohne dass jemand Leistungsmängel beklagte. Heute können wir nicht einmal die Hälfte davon bedienen, obwohl unser Server viel leistungsfähiger ist.
Du könntest versuchen, sie auf 80MB zu erhöhen. Vielleicht statt der anderen Änderung.
Dies ist ein Punkt, an dem wir ständig aktiv arbeiten.
Als Discourse neu war, hatten fast alle Seiten eine brandneue Datenbank, sodass die Datenbank problemlos im Arbeitsspeicher Platz hatte. Einige Jahre später haben einige Seiten nun Datenbanken von über 100 GB und RAM-Größen, die nicht einmal ein Zehntel davon ausmachen.
Ein bevorstehendes Update in den nächsten Wochen ist das PostgreSQL-13-Upgrade, das die Größe des größten Objekts halbieren wird.
Darüber hinaus ist Schritt 0 zur Fehlersuche bei Leistungsproblemen das Sammeln von Daten mit dem Prometheus-Exporter-Plugin für Discourse, damit wir nicht im Blindflug agieren.