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. 