Stimme zu, was ist der Wert von Inhalten, die niemand liest? Und welche Leute werden sich tatsächlich hinsetzen und 10.000 Beiträge von Anfang bis Ende durchlesen? 
Es ist in Ordnung, wenn einige Themen flüchtige Chats sind, die mit der Zeit vollständig verschwinden, wie wir es zuvor als „Fast Lane“ im Gegensatz zu „Slow Lane“-Verkehr bezeichnet haben.
Kleines Update:
Da gemeldet und vereinbart wurde, alles oberhalb der Marke zu schließen (und die Grenzen wiederherzustellen), scheint die Leistung besser zu sein, deutlich besser. Wir erhalten zwar noch einige Meldungen wie „Aufgrund extremer Last wird dies vorübergehend so angezeigt, wie ein nicht angemeldeter Benutzer es sehen würde“, aber deutlich seltener.
Dazu noch:
Noch einmal ein riesiges Dankeschön an alle für die Unterstützung und das Feedback.
Postgres 12 wird helfen, da es in @falcos Tests die Größe von Tabellen und Indizes um 20 % reduziert.
Gibt es dafür schon ein Ziel-Datum?
Ich habe heute mit Benchmarks begonnen.
Wir müssen das hier auf Meta eine Weile laufen lassen, um Leistungsverschlechterungen zu erkennen, bevor wir es überall einführen.
Es tut mir leid, dass ich das Thema erneut anspreche, aber dies ist ein anderes Problem als die PostgreSQL-Migration. (Die ich aufgrund der Größe noch nicht durchführen kann).
Seit dem letzten Neuaufbau wächst meine Datenbankgröße ununterbrochen:
Der letzte Neuaufbau war am 17. Mai, und seitdem wächst die Datenbankgröße ununterbrochen und erreicht 57,3 GB. Der Großteil der Größe entfällt auf die Tabelle post_timings.
Mein Hauptproblem dabei ist, dass ich versuche, das PostgreSQL-Update durchzuführen (was die Indexgröße um 20 % reduzieren wird, aber das Problem langfristig nicht lösen wird). Und aus den Kommentaren des Supports hier geht hervor, dass diese Größe nicht normal ist, sodass sie weiter wachsen und nachtschrecklich teuer werden wird. Je mehr Zeit vergeht, desto mehr wächst sie, und es entsteht ein Teufelskreis, der zur Hölle bei der Wartung wird. Mein Hauptproblem bleibt also bestehen: Gibt es eine Möglichkeit, dieses post_timings-Problem anzugehen? Etwas, das gelöscht werden kann?
Kann ich Tabellen komprimieren oder ähnliches?
Danke an alle für ihre Hilfe.
Es gibt derzeit keinen anderen Weg. Wenn dein Forum wirklich groß ist, wird es eine große Zeittabelle haben.
Meta ist eine sehr alte Instanz, aber mittelgroß und hat eine kleine post_timings-Tabelle mit 4 GB. Andererseits hosten wir eine Instanz, die weniger als zwei Jahre alt ist, und die post_timings-Tabelle sollte mittlerweile über 100 GB groß sein.
Das Hosting großer Foren wird dich mehr kosten, und es gibt heute keine Umgehungen dafür.
Vielleicht verlegst du deine Datenbank auf einen separaten $20-Droplet (80 GB Festplatte) und stellst das Web auf einen anderen 10-Droplet? 30 monatliche Kosten für das, was wie eine recht große Community aussieht, klingen vernünftig.
Vielen Dank für deine Hilfe, @Falco.
Tja, ja, wie gesagt, ich fragte nur, weil es im Weltraum kein Magie gibt. Ich untersuche die Aufteilung, aber die App wird dann zu langsam aufgrund der Performance (lange Geschichte – ich notiere mir die Tests und werde sie später hier vorstellen, falls andere sie nützlich finden).
Ich habe den Test durchgeführt, den ich von dir angefragt hatte, bezüglich der Wiederherstellung eines Backups und Co., und ich denke, dass dies eine gute Gelegenheit ist, davon zu profitieren, da ich sofort feststelle, dass der Speicherplatzverbrauch um 30 % geringer ist (ich führe noch weitere Tests durch, um sicherzustellen, dass nichts fehlt). Allerdings gibt es ein kleines Problem mit diesem Ansatz. Obwohl die unmittelbaren Vorteile groß sind, wird dies einige Probleme verursachen (umso mehr, da ich nicht weiß, ob es zwischengespeichert wird oder ob die gespeicherten Bilder überhaupt funktionieren – ja, das Backup enthält sie).
Ich mache mir Notizen, damit ich den ursprünglichen Beitrag aktualisieren kann. Meine Idee ist es, eine kleine Reihe von Hinweisen für Leute hinzuzufügen, die sich Sorgen um die Performance und all die Dinge machen könnten, die ich bisher geändert habe.
[quote=“codinghorror, Beitrag: 21, Thema: 144277”]
Es ist in Ordnung, wenn einige Themen flüchtige Chats sind, die mit der Zeit vollständig verschwinden, wie wir es zuvor als „Fast Lane
Tatsächlich ist das eine ziemlich gute Idee und löst das Problem der Benutzerfreundlichkeit (denn, wie gesagt, niemand wird 10.000 Nachrichten lesen wollen). Die große Frage ist also, ob das für Server und Datenbank zu belastend wäre.
Ich bin mir nicht sicher, ob ein Antwortthema mit 9000 Antworten, von denen etwa 8600 gelöscht wurden, gut für die Leistung ist, aber ich bezweifle es irgendwie. Was sagst du dazu, @eviltrout?
Ich dachte, dass “versteckte” Beiträge nach einiger Zeit vollständig aus der Datenbank entfernt werden, aber nun sehe ich, dass dies wahrscheinlich nicht der Fall ist.
Daher kann meine Idee leistungstechnisch das Problem nicht lösen.
Gibt es eine Möglichkeit, diese Daten zu “bereinigen”?
Gelöschte Beiträge werden weich gelöscht. Sie werden jedoch häufig indiziert, sodass Sie möglicherweise einige Verbesserungen bemerken, wenn eine ganze Reihe entfernt wird. Ich würde es jedoch nicht empfehlen. Wenn es eine Möglichkeit gibt, zu einem neuen Thema zu wechseln, sobald eines groß wird, könnte das gut für Sie sein.
Was genau meinst du damit? Die Datenbank und die Web-App auf separaten Servern zu betreiben, sollte dir mehr Performance bieten, denn obwohl zwischen den Servern eine gewisse Latenz entstehen wird, müssen Unicorn und Postmaster nicht mehr um CPU und RAM konkurrieren.
Stelle sicher, dass sich die Server in derselben DO-Region befinden 
Entschuldigung, du hast recht. Das würde beide freisetzen und eine bessere Leistung erzielen als alles auf einem einzigen (ich habe mich bisher mit den Ressourcen verglichen, die ich auf einer einzelnen Maschine verwende, und mit den Anpassungen, die ich bisher vorgenommen habe).
Das ist tatsächlich eine sehr gute Idee. Lass mich versuchen, das Problem mit dem “Fehler beim Neuerstellen des Datencontainers” zu lösen, und das wird mein nächster Schritt in dieser Reise sein.
Ich habe mich intensiv mit diesem Thema beschäftigt, konnte aber keine Dokumentation finden, die erklärt, wie man dies idealerweise umsetzt. Gibt es einen solchen Leitfaden?
Auch wir stoßen bei unserer Standard-Installation auf einem einzelnen VPS an unsere Grenzen. Unser eher einzigartiges Dilemma sind die Spielchats, die während Eishockeyspielen stattfinden und zu starken Spitzen bei der Aktivität und Last führen. Besonders, wenn im Spiel etwas Außergewöhnliches passiert.
Sie müssten wahrscheinlich etwas haben, das stark genug ist, um Ihre geschäftigsten Momente zu bewältigen. Oder Sie müssten die Leistung in diesen Zeiten erhöhen. Vielleicht suchen Sie nach einem VPS, den Sie stundenweise bezahlen können. Eine Lösung (in Fortsetzung des vorherigen Tipps) wäre, den Web-Container auf einen extrem leistungsstarken VPS zu verlagern, den Sie nur für ein paar Stunden bezahlen, wenn Spiele stattfinden.
Sie müssen Folgendes tun:
Führen Sie PostgreSQL an einem anderen Ort aus (z. B. auf einem Droplet oder nutzen Sie einen gehosteten Dienst wie Worry-Free Managed Database Hosting | DigitalOcean) und verschieben Sie Ihre Daten dorthin.
Folgen Sie Discourse mit einem separaten PostgreSQL-Server ausführen
Und das kann auch durch die Verwendung von Discourses containerisierten Produkten erreicht werden? Web_only und data, richtig?
Aus meiner Erfahrung wird dies durch keinen aktuellen Ansatz direkt gelöst, und es gibt auch keine lineare Lösung. Tatsächlich ist die Trennung auf verschiedene Maschinen keine sofortige Abhilfe für dieses Problem.
Wir erleben ebenfalls starke Einbrüche und die Meldung „Die Seite ist extrem ausgelastet, daher sehen Sie sie so, als wären Sie nicht eingeloggt“, wenn ein großes Ereignis stattfindet (wie ein Spiel, wie @ljpp bereits erwähnte). Das拉gt die gesamte Seite herunter, nicht nur die Nutzer innerhalb dieses Themas.
Daher habe ich zwei verschiedene Ansätze versucht: eine getrennte Einrichtung und eine „große Maschine“. Beide weisen diese Art von Problemen auf. Meine Instanzen werden mit Prometheus überwacht, und die Logs sind in Grafana einsehbar usw. Ich habe also eine sehr granulare Kontrolle über die Hardware-/Container-Performance und kann bestätigen, dass es wirklich keine Rolle spielt, was man tut – das Problem tritt trotzdem auf.
Wenn man eine große Maschine dahinterstellt, kann man den Fehler vielleicht etwas verzögern, aber man wird dennoch Fehler und Session-Verluste erleben, während die Maschine kaum ausgelastet ist – egal ob bei Festplatte, CPU oder RAM. Dies tritt sowohl bei der „Standard-Installation“ als auch bei der „Zwei-Container-Installation“ auf.
Bei verschiedenen Maschinen ist das Problem dasselbe, unabhängig davon, ob es sich um gleichartige Maschinen handelt oder ob eine „CPU-optimiert“ und die andere „Festplatten-optimiert“ ist usw. Hinzu kommt eine zusätzliche Fehlerquelle: die Verbindung zwischen zwei verschiedenen Maschinen, die zwangsläufig zu Verzögerungen führt. Zwar kann das Ausmaß dieser Verzögerung davon abhängen, wie die Verbindung eingerichtet ist und wie „weit entfernt“ die beiden Maschinen voneinander sind, aber das gleiche Verhalten wird sich einstellen.
Als Anmerkung: Dieses Verhalten tritt auch bei Komponenten wie dem Babel-Plugin auf. Allerdings scheint das Babel-Plugin deutlich mehr „gleichzeitige“ Schreibvorgänge bewältigen zu können, auch wenn die „Chats“ eigentlich versteckte Themen sind. Der Unterschied liegt darin, wie sie dargestellt und „aktualisiert“/„abgerufen“ werden. Dieses unterschiedliche Verhalten hat mich zu der Schlussfolgerung geführt, dass es sich um eine anwendungsbezogene Korrelation handelt, die von einem Frontend-bedingten Problem herrührt, das die Anwendung zum Absturz bringt (obwohl Frontend nicht mein Fachgebiet ist – im Gegensatz zu Backend) sowie von den Operationen beim Posten und dem Warten der Nutzer auf ein Thema, das sich mit Dutzenden von Nachrichten innerhalb einer einzigen Minute „selbst aktualisiert“.
Dazu kommt noch der menschliche Faktor: Wenn Nutzer die Seite als „träge“ empfinden oder bemerken, dass ein Thema „nicht so schnell aktualisiert wird, wie es sollte“, drücken sie F5, bis es nicht mehr geht, was die Last weiter erhöht. Aber viel Glück dabei, die Nutzer in dieser Hinsicht zu „erziehen“
