Tuning a Discourse server for performance

Are there any guides (or Topics here on the forum) that provide tips on tuning a server that hosts Discourse sites for performance?

I ran the ./Discourse-set and it set a quarter of the ram (to 4096mb) and added 8 unicorns workers - but is there anything else we can do, or tweak these?

The server has 64GB ECC Ram and two 512GB NVMe SSDs (in a raid array). Looking at top, only around 5GB of memory us being used, with 57392484 avail Mem. It does run other non-Docker sites, but they don’t use up much of the resources and MySQL is already tuned for a large 2GB db. Load averages are generally below 1.0 (usually around 0.50 up to 1.0 with occasionally going over). No problems have been reported, but I am hoping to utilise as much of the server as possible.

I’m wondering whether to start by doubling db_shared_buffers… and what about #db_work_mem: "40MB" which is currently commented out.

All info/tips appreciated :smiley:

3 „Gefällt mir“

Ich habe auch in den Foren danach gesucht.

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)

1 „Gefällt mir“

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.

1 „Gefällt mir“

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.

1 „Gefällt mir“
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.

1 „Gefällt mir“

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. :slight_smile:

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.

…ja, ich ziehe es vor, Arbeitsspeicher freizugeben, wenn er nicht genutzt wird, bis der Traffic Änderungen erfordert.

Danke nochmals.

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 :rofl: )

1 „Gefällt mir“

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. :slight_smile: