Gibt es Anleitungen (oder Themen hier im Forum), die Tipps zur Leistungsoptimierung eines Servers bieten, der Discourse-Instanzen hostet?
Ich habe ./Discourse-set ausgeführt, wodurch ein Viertel des Arbeitsspeichers (auf 4096 MB) zugewiesen und 8 Unicorn-Arbeiter hinzugefügt wurden. Gibt es jedoch noch weitere Maßnahmen, die wir ergreifen können, oder können wir diese Einstellungen anpassen?
Der Server verfügt über 64 GB ECC-RAM und zwei 512 GB NVMe-SSDs (in einem RAID-Array). Wenn ich top betrachte, werden nur etwa 5 GB Arbeitsspeicher verwendet, mit 57392484 avail Mem. Der Server hostet auch andere Nicht-Docker-Websites, die jedoch nur wenige Ressourcen beanspruchen, und MySQL ist bereits für eine große Datenbank mit 2 GB optimiert. Die Lastdurchschnitte liegen in der Regel unter 1,0 (meist zwischen 0,50 und 1,0, gelegentlich auch darüber). Es wurden keine Probleme gemeldet, aber ich hoffe, die Serverressourcen so weit wie möglich auszunutzen.
Ich frage mich, ob ich damit beginnen sollte, db_shared_buffers zu verdoppeln … und was ist mit #db_work_mem: "40MB", das derzeit auskommentiert ist?
Es gibt (oder gab) ein paar Themen zur Optimierung. Die meisten erfolgreichen, glaube ich (mit Ausnahme dieses hier), geben einige genaue Details zu verfügbaren Ressourcen, db_shared_buffers und anderen Einstellungen an und beschreiben die Probleme, vielleicht mit Ausgaben von htop oder anderen Tools. Wie groß ist Ihre Datenbank? Welches Problem haben Sie? (Sie möchten vielleicht ein neues Thema eröffnen)
Danke! Bisher keine Probleme. Mir ist nur der hohe Speicherverbrauch aufgefallen, obwohl das Forum nicht übermäßig stark genutzt wird. Ich bin es einfach gewohnt, proaktiv zu denken und zu prüfen, welche Ressourcen am meisten genutzt werden. Das läuft auf einem 3GB VPS mit 6 Kernen @ 3,5 GHz. Nicht langsam, wirklich schnell, aber ich sehe, dass der Speicherverbrauch ein zukünftiges Problem werden könnte und bin neugierig, was ich optimieren kann.
Ich werde mich noch weiter über allgemeine Ruby on Rails-Anwendungen und Optimierung informieren. Nochmals danke.
Abhängig davon, welche Messung von „Nutzung“ Sie meinen, könnte das normal sein. Aber mit 3 GB gibt es wahrscheinlich nicht viel zu optimieren, da die Vermutungen, wenn Sie ./discourse-setup ausgeführt haben, wahrscheinlich gut genug sind.
free -h
total used free shared buff/cache available
Mem: 2.9Gi 1.8Gi 167Mi 100Mi 1.0Gi 895Mi
Swap: 1.0Gi 587Mi 436Mi
Verfügbar sind ca. 900M. Noch kein Problem. Aber ein Problem hat mich nicht hierher gebracht. Ich möchte wissen, was ich tun kann, wenn der verfügbare Speicherplatz in Zukunft ein Problem darstellt. Abgesehen davon, natürlich mehr Speicher hinzuzufügen.
Auf diesem Niveau besteht die einzige wirkliche Möglichkeit darin, mehr RAM hinzuzufügen. Wenn Sie 8 oder 16 GB haben, gibt es einige Dinge zu tun. Wenn überhaupt, möchten Sie vielleicht noch 1 GB Swap hinzufügen, aber Sie werden wahrscheinlich in Ordnung sein.
Wenn Sie ./discourse-setup ausführen würden, hätte es eine 2-GB-Swap-Datei erstellt. Sie könnten Probleme bekommen, wenn Sie einen Rebuild durchführen.
ok, ich konnte die verfügbare Speichernutzung gerade so verdoppeln, indem ich die Installationsstandardeinstellung von: UNICORN_WORKERS: 8
zu UNICORN_WORKERS: 4
geändert habe.
Dann: sudo ./launcher rebuild app
Ich richte jetzt die Überwachung von PostgreSQL ein und werde sehen, was dort vor sich geht.
Es gibt immer einen Zeitpunkt, an dem eine Ressource zum Engpass wird. Aber Ihr Server erscheint mir derzeit stark überdimensioniert.
Sie werden mehr Speicher verbrauchen, wenn Sie mehr Unicorn-Prozesse haben.
Sie werden mehr Unicorn-Prozesse benötigen, wenn Sie mehr Traffic auf Ihrer Website haben.
Ich sehe, dass alle Unicorn-Prozesse 0,0 % CPU verbrauchen und nur worker[0] tatsächlich etwas zu tun scheint.
Sie haben den Speicher reduziert, indem Sie weniger Unicorns laufen ließen. Das ist gut, da Sie sie ohnehin nicht zu nutzen schienen. Aber verfügbarer Speicher ist eigentlich schlecht. Sie optimieren für die falsche Variable.
Unbenutzter Speicher bringt Ihnen nichts. Es bedeutet, dass Sie für etwas bezahlen, das Sie ohnehin nicht nutzen. Wenn Sie ständig 2 GB verfügbar haben*, könnten Sie Ihren Server verkleinern und etwas Geld sparen.
*) Der Wiederaufbau von Discourse verbraucht mehr Speicher, daher müssen Sie prüfen, wie viel Speicher während des Wiederaufbaus verfügbar ist. In der Praxis sollten Sie nicht unter die gesamten 2 GB gehen und/oder sicherstellen, dass Sie genügend Swap haben, wie Pfaffman bereits sagte.
Nicht korrekt. „Freier“ Arbeitsspeicher, der nichts tut, ist schlecht. Aber „verfügbarer“ Arbeitsspeicher ist Arbeitsspeicher, der vom System genutzt wird und leicht freigegeben werden kann, was eine gute Sache ist.
Oder offiziell:
Verfügbarer Arbeitsspeicher: Schätzung, wie viel Arbeitsspeicher zum Starten neuer Anwendungen zur Verfügung steht, ohne zu swappen.
Quelle: man free
Wie im Screenshot unten zu sehen ist, hat sich der freie Arbeitsspeicher kaum verändert. Daher wird fast der gesamte Arbeitsspeicher des Systems genutzt. Das System wird jedoch jetzt weniger swappen, da mehr verfügbarer Arbeitsspeicher vorhanden ist, der bei Bedarf freigegeben werden kann.
Ich vermute, schlecht bedeutet hier, dass es etwas kostet, aber nichts einbringt. Das ist eine ziemlich gängige Denkweise, denn wenn man mehr Ressourcen benötigt, wird es auch teurer – und RAM ist ein kostspieliger Teil dieser Gleichung.
Und wenn man nicht zu viel Geld zu verschwenden hat, ist es irgendwie dumm, zu viel zu bezahlen (finnischer Werbeslogan, keine Beleidigung )
Ja, genau, in Bezug auf den freien Speicher. Allerdings ist „verfügbarer Speicher ist eigentlich eine schlechte Sache“ …das ist es, was ich eigentlich angesprochen habe.
)