Das sieht weniger nach einem pnpm- oder Ember-Problem aus, sondern eher danach, dass dem Host einfach der Arbeitsspeicher ausgegangen ist.
Das Schlüsseldetail ist das SIGKILL. Das bedeutet normalerweise, dass das Betriebssystem eingegriffen und den Prozess beendet hat (oft durch den OOM-Killer), nicht, dass ember build -prod von selbst fehlgeschlagen ist.
Auf kleinen Hosts können Ember-Produktions-Builds leicht auf ein paar GB RAM ansteigen. Selbst wenn Swap aktiviert ist, kann der Kernel, sobald der Swap größtenteils aufgebraucht ist, immer noch entscheiden, einen speicherhungrigen node-Prozess zu beenden.
Ein paar Dinge, die in diese Richtung deuten:
- Der Swap wird zum Zeitpunkt des Fehlschlags bereits stark genutzt.
- Der Fehler tritt viel wahrscheinlicher auf, wenn gleichzeitig ein anderer Container läuft.
- Wenn ich den anderen Container stoppe, bevor ich den Bootstrap ausführe, gelingt derselbe Build.
Swap hilft also ein wenig, verzögert das Problem aber hauptsächlich nur. Das Stoppen anderer Container reduziert den Speicherdruck so weit, dass der Build abgeschlossen werden kann.
Was geholfen hat / helfen könnte:
- Vermeiden Sie die parallele Ausführung mehrerer Bootstraps oder Asset-Builds.
- Stoppen Sie andere Container während
ember build -prod. - Begrenzen Sie die Speichernutzung von Node (z. B.
NODE_OPTIONS=--max_old_space_size=1024), um die Spitzenlast zu reduzieren. - Wenn möglich, erhöht eine Erhöhung des Host-RAMs (4 GB+) die Zuverlässigkeit erheblich.
Hoffentlich erklärt dies, warum es sich etwas zufällig anfühlt und warum das Stoppen eines anderen Containers dazu führt, dass es funktioniert.