Upgrade von 3.2.0.beta3-dev zu 3.2.0.beta3 fehlgeschlagen wegen Speichermangel

Installation
1

Hallo,

Ich habe versucht, ein Upgrade von 3.2.0.beta3-dev auf 3.2.0.beta3 durchzuführen, und es hat meine Discourse-Instanz aufgrund von Speichermangel während des Ember-Builds von Assets beschädigt. Ich habe versucht, ./launcher rebuild app auszuführen, mit demselben Ergebnis.

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb83f50 node::Abort() [ember]
 2: 0xa94834  [ember]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
 5: 0xf42265  [ember]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ember]
 7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ember]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ember]
11: 0x17035b9  [ember]
Aborted (core dumped)
error Command failed with exit code 134.
I, [2023-11-26T17:19:26.345389 #1]  INFO -- : yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Environment: development
WARNING: ember-test-selectors: You are using an unsupported ember-cli-babel version. data-test properties are not automatically stripped from your JS code.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Ich betreibe eine DigitalOcean-Instanz mit 1 GB für eine gemeinnützige Organisation, daher kann ich es mir nicht leisten, sie mit mehr Speicher zu vergrößern. 1 GB ist die Mindestgröße für Discourse und frühere Versionen liefen ohne Probleme. Haben Sie Ideen, wie ich es wieder zum Laufen bringen kann?

2

Haben Sie Swap?

Was ist die Ausgabe von

free -h
1 „Gefällt mir“
3 
               total        used        free      shared  buff/cache   available
Mem:           952Mi       321Mi       414Mi       3.1Mi       374Mi       631Mi
Swap:          2.0Gi        75Mi       1.9Gi
4

Sie müssten es nur während des Wiederaufbaus vergrößern.

2 „Gefällt mir“
5

Sie sollten in Erwägung ziehen, zu Hetzner zu wechseln, die wettbewerbsfähige Preise und 2 GB RAM in ihrem Basistarif anbieten.

1 „Gefällt mir“
6

Hallo und willkommen @andreid :slight_smile:

Meine 1GB DO-Testseite hatte in letzter Zeit auch Probleme mit Speicherproblemen während des Wiederaufbaus. Ich habe vorübergehend auf 2GB aufgerüstet, um sie über die Runden zu bringen.

1 „Gefällt mir“
7

Wäre es dann nicht lohnenswert, die Mindestanforderungen in der Dokumentation auf 2 GB RAM zu aktualisieren?

2 „Gefällt mir“
9

Ich erinnere mich, dass es letztes Jahr passiert ist und einige Anpassungen vorgenommen wurden JavaScript heap out of memory due to Ember CLI - #4 by JammyDodger. Ich bin mir nicht sicher, ob dieses Mal auch etwas getan werden kann, aber ich werde fragen. :+1:

3 „Gefällt mir“
10

Vielen Dank @RGJ und @JammyDodger, das vorübergehende Ändern der Größe hat den Trick gemacht.

3 „Gefällt mir“
11

Das Hinzufügen von 1 GB Swap sollte funktional dasselbe sein wie das Hinzufügen von 1 GB RAM, wenn Sie über genügend Festplattenspeicher verfügen. (Es wird wahrscheinlich länger dauern, das Upgrade auszuführen, aber das ist Leistung und keine Funktion. Was Sie anstreben, ist die Vermeidung einer Situation mit zu wenig Arbeitsspeicher.)

13

Ich habe zusätzliche Informationen, falls dies hilft, das Problem von Discourse-Seite aus zu mildern. Meine Instanz (DigitalOcean ~1GB Droplet mit 2GB Swap) begann kürzlich, deutlich länger für den Wiederaufbau zu benötigen und meldete den gleichen fatalen Fehler etwa 3 von 4 Malen (das Glück scheint sich nach dem Ausführen von ./launcher cleanup zu verbessern, aber ich habe keine ausreichende Stichprobengröße, um dies zu bestätigen).

Kurz vor dem Heap-Out-of-Memory-Fehler werden diese Zeilen protokolliert:

Node.js heap_size_limit (491.0) ist kleiner als 1024MB. Setze --max-old-space-size=1024.
Node.js heap_size_limit (491.0) ist kleiner als 2048MB. Deaktiviere Webpack-Parallelisierung mit JOBS=0, um Speicher zu sparen.

Ich bin hier nicht mehr in meinem Fachgebiet, daher entschuldige ich mich, wenn ich etwas falsch mache. Einige schnelle Recherchen deuten darauf hin, dass ember-cli von node.js abhängt, weshalb ich denke, dass dies relevant ist. Das Flag --max-old-space-size kann potenziell höher als der RAM gesetzt werden (es würde einfach in den Swap-Bereich gehen, was wie erwähnt in diesem Fall in Ordnung ist), daher ist 1024 vielleicht eine künstliche Decke, gegen die Discourse-Wiederaufbauten nicht mehr ankommen können.

Nebenbemerkungen: Anscheinend ist --optimize-for-size ein Node.js-Flag, das hilft, den Speicherverbrauch zu reduzieren (ich bin mir nicht sicher, ob es von Discourse/ember verwendet wird, vielleicht schon), und es gibt eine Anekdote, dass der Garbage Collector bei bestimmten Node.js-Verwendungen nicht aktiviert wird, was ein Problem sein könnte.

Wenn etwas davon relevant und von der Discourse-Seite der ember/node.js-Nutzung steuerbar ist, wäre es vielleicht wert, dass sich jemand damit beschäftigt. Wenn nicht, keine Sorge, ich werde die oben vorgeschlagene temporäre 2GB-Upgrade-Lösung anwenden. :slight_smile:

1 „Gefällt mir“
14

Das ist ein sehr guter Punkt! Im Moment erhöhen wir ihn auf 1024 MB auf Maschinen mit wenig RAM hier. Wir könnten sicherlich damit experimentieren, ihn auf 1500 oder 2000 zu erhöhen und sehen, ob es hilft.

Wenn Sie Zeit und Lust haben, es selbst auszuprobieren, könnten Sie es konfigurieren, indem Sie eine neue Variable zum env:-Abschnitt Ihrer app.yml-Datei hinzufügen:

Bearbeiten: :warning: dies ist jetzt der Standard von Discourse. Keine Notwendigkeit, es selbst zu konfigurieren

  NODE_OPTIONS: "--max-old-space-size=2048"
3 „Gefällt mir“
15

Ah, perfekt! Ich habe es ausprobiert.

Da der fatale Fehler nicht jedes Mal auftritt und ein Neuerstellungsprozess in letzter Zeit etwa 25 Minuten dauert (statt 5-10), kann es einige Zeit dauern, bis ich weiß, ob die Erhöhung dieser Zahl das Speicherproblem für diese Server-Spezifikationen löst.

Aber ich kann bereits bestätigen, dass die beiden Warnungen Node.js heap_size_limit im Neuerstellungsprotokoll nicht mehr erscheinen und meine erste Neuerstellung erfolgreich war, das ist also vielversprechend.

EDIT: Ich konnte jetzt mehrmals ohne Probleme neu erstellen, dank der NODE_OPTIONS-Einstellung oben in meiner app.yml. Juhu!

EDIT2: Diese Lösung sollte wahrscheinlich in Discourse Eingang finden, indem diese magische Zahl (Link aus Davids Beitrag) erhöht wird, damit andere Maschinen mit wenig RAM weiterhin funktionieren können. Wenn jemand das liest, der weiß, wie das geht, wäre das großartig. :slight_smile:

2 „Gefällt mir“
16

Wir sind auch auf https://caddy.community auf dieses Problem gestoßen.

Wir haben mehrmals ./launcher rebuild app ausgeführt und es kam zu verschiedenen Problemen.
Zuerst hatten wir Probleme mit bundle install, das sich über rbtrace beschwerte (endend mit An error occurred while installing rbtrace (0.5.0), and Bundler cannot continue.).

Dann hatten wir schließlich dieses OOM-Problem:

I, [2023-12-12T07:50:59.497921 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.

<--- Last few GCs --->

[3683:0x5dab130]   279104 ms: Scavenge 981.3 (1037.1) -> 974.5 (1037.1) MB, 8.3 / 0.0 ms  (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130]   279136 ms: Scavenge 981.8 (1037.1) -> 975.0 (1037.1) MB, 8.0 / 0.0 ms  (average mu = 0.699, current mu = 0.681) allocation failure;
[3683:0x5dab130]   282606 ms: Mark-sweep 994.8 (1050.6) -> 987.7 (1048.9) MB, 3316.1 / 0.0 ms  (average mu = 0.593, current mu = 0.501) allocation failure; GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb83f50 node::Abort() [ember]
 2: 0xa94834  [ember]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
 5: 0xf42265  [ember]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, [snip]
Aborted (core dumped)
error Command failed with exit code 134.

Und schließlich hat die Ausführung mit ./discourse_doctor es irgendwann geschafft, das Problem zu überwinden (warum eigentlich? mehr Zeug im Cache bei späteren Läufen, was zu weniger Speicherverbrauch führte? :thinking:)

I, [2023-12-12T08:02:50.556442 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
110:M 12 Dec 2023 08:07:50.026 * 100 changes in 300 seconds. Saving...
110:M 12 Dec 2023 08:07:50.030 * Background saving started by pid 3706
3706:C 12 Dec 2023 08:07:51.292 * DB saved on disk
3706:C 12 Dec 2023 08:07:51.294 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
110:M 12 Dec 2023 08:07:51.334 * Background saving terminated with success
Purging temp files
Bundling assets

Aber das war eine Reibung, die wir nicht hätten erfahren müssen. Hoffentlich verbessert sich das in Zukunft.

Nur zur Info:

# free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.3Gi        87Mi       138Mi       593Mi       394Mi
Swap:         2.0Gi       337Mi       1.7Gi
1 „Gefällt mir“
17

Auf jeden Fall, deshalb sammeln wir hier Informationen.

Es scheint, dass das Anpassen unserer NODE_OPTIONS-Umgebungsvariablen alles ist, was benötigt wird. Ich würde also vermuten, dass entweder eine Abhängigkeit der App oder eine V8-Änderung unseren vorherigen Wert dort nicht mehr funktionieren ließ.

@david wie sieht das aus?

1 „Gefällt mir“
18

Sieht gut aus für mich! Offensichtlich sind 30-Minuten-Wiederaufbauten immer noch nicht ideal, daher hoffe ich, dass wir die Dinge in nicht allzu ferner Zukunft verbessern können. Aber dies scheint eine gute Lösung zu sein, um die Blutung zu stoppen.

2 „Gefällt mir“
19

Es ist erwähnenswert, dass die Erhöhung der PostgreSQL-Version 16 im Vergleich zur Version 13 weniger Speicherplatz verbraucht und viel besser optimiert ist. Dies kann die insgesamt verbrauchte Serverarbeitsspeicher reduzieren.

20

Ich bin heute auf ein ähnliches Wiederaufbauproblem gestoßen (zwei Container) mit einer 2 GB + 2 GB Swap-Einrichtung für eine kleine Website.
Die Erweiterung auf 2 GB + 4 GB Swap hat es diesmal geschafft.

2 „Gefällt mir“
21

2 Beiträge wurden in ein neues Thema aufgeteilt: Rebuild zeigt „Environment: development“ während des Ember-CLI-Builds an

22

FWIW, in my case, adding

zu app.yml hat nicht geholfen. Was geholfen hat, war einfach


sudo apt update
sudo apt upgrade
2 „Gefällt mir“