Hoher Wiederherstellungs-Speicherbedarf: April 2025 Ausgabe

Ok, nächster Test abgeschlossen.

Ich habe mit den folgenden Plugins gebaut:

https://github.com/discourse/docker_manager.git
https://github.com/discourse/discourse-data-explorer
https://github.com/communiteq/discourse-legal-compliance
https://github.com/pfaffman/discourse-allow-pm-to-staff
https://github.com/singerscreations/discourse-stopforumspam
https://github.com/discourse/discourse-cakeday

Swap war deaktiviert, also nur 4GiB/3,8GB RAM.

Die maximale Speichernutzung während des Builds betrug 3,4 GB. Die Build-Zeit betrug 6m 48s.

4 „Gefällt mir“

Auf dem Weg ist das Problem die Swap-Datei. Nachdem sie von 0 auf 2 GB erhöht wurde, ist vorerst alles in Ordnung.

sudo fallocate -l 2G /swapfile        
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Im Terminal Ihres Servers. Danach neu erstellen.

2 „Gefällt mir“

Ich stelle eine starke Zunahme des für den Neuaufbau benötigten Speichers fest. Ich habe 8 GB Speicher und selbst mit dem Hinzufügen einer 8 GB großen Swap-Datei geht mir der Speicher bei diesem Schritt aus: cd /var/www/discourse && sudo -E -u discourse bundle exec rake multisite:migrate

Es handelt sich um eine Multisite-Installation mit vier Foren. Ich musste bisher keine Swap-Datei hinzufügen.

Edit Habe es jetzt mit 16G Swap versucht und der Speicher geht immer noch zur Neige.

Dies geschieht unter Linux, mit minimal aktivierten Plugins.

2 „Gefällt mir“

Hmm… Ich frage mich, sollten die Dokumentationen aktualisiert werden, um höhere Speicheranforderungen widerzuspiegeln? Hat Introducing pre-compiled JS assets for self-hosters geholfen, die Last zu verringern? Ich hätte gedacht, dass mit dieser Änderung weniger RAM benötigt wird :thinking: .

Es ist vielleicht ein paar Monate her, dass ich einen Neuaufbau durchgeführt habe, aber es funktionierte vorher mit 8 GB RAM und ohne Swap. Ich habe das Problem immer noch nicht gelöst, und daher sind alle vier Websites ausgefallen.

Ich weiß nicht, ob dies damit zusammenhängt, aber es ließ sich nicht erstellen, bis ich die Umgebungsvariable HOME: /var/www/discourse gesetzt habe – andernfalls versuchte es, nach /root zu schreiben und erhielt eine Berechtigungsverweigerung.

Hmm, ich sehe über hundert dieser Prozesse:

node /usr/bin/pnpm add pnpm@10.28.0 --loglevel=error --allow-build=@pnpm/exe --no-dangerously-allow-all-builds --config.node-linker=hoisted --config.bin=bin

Ist das eine Art Fork-Bombe?

1 „Gefällt mir“

Fügen Sie auf jeden Fall eine MENGE Swap hinzu, selbst wenn es nur darum geht, wieder zum Laufen zu kommen. Der Vorteil der Verwendung von Swap besteht hier darin, dass Builds ein vorübergehender Spitzenwert sind.

Ich verwende das Zwei-Container-Setup und der Speicher steht während des Bootstrap noch stärker unter Druck, da Sie auch zwei laufende Container haben. :sweat_smile:

Ich habe jetzt 40 GB Swap hinzugefügt und es ist nicht genug.

Ich sehe Hunderte dieser Node-Prozesse, das scheint das Problem zu sein?

Ich fange an zu glauben, dass die eigentliche Ursache dieselbe ist wie bei meinem früheren Problem, bei dem ich HOME: /var/www/discourse setzen musste, da es sonst versuchen würde, Dateien unter /root zu schreiben. Ich weiß allerdings nicht, was ich dagegen tun soll.

2 „Gefällt mir“

Ok, etwas stimmt hier ganz und gar nicht. Ich würde auch in Erwägung ziehen, ein Backup zu erstellen und von Grund auf neu zu beginnen.

1 „Gefällt mir“

Wie würde ich dabei vorgehen?

Siehe:

Danke, ich denke, ich werde zuerst den gesamten Server auf einen als gut bekannten Zustand zurücksetzen und von einem funktionierenden System aus ein Backup erstellen.

Hat jemand Ideen, was schiefgelaufen sein könnte?

1 „Gefällt mir“

Das Problem lag tatsächlich daran, dass HOME nicht korrekt gesetzt war. Das Hinzufügen von -H zum sudo-Befehl für die Multisite-Migration hat es behoben, wie hier detailliert beschrieben:

6 „Gefällt mir“