Werden die Build-Assets vorab erstellt und verwendet? Oder haben Sie das deaktiviert? (oder den Kern so gepatcht, dass die vorab erstellten Assets nicht verwendet werden können)
Sie haben viel Swap, aber ein großer Teil davon wird bereits verwendet. Da ein Zwei-Container-Setup weniger Ausfallzeiten hat, ist es vielleicht wahr, dass die aktuelle Ausführung des Servers noch läuft und aufgrund eines Lecks viel Speicher verbraucht hat.
Vielleicht würde ein Neustart helfen, vor dem Update. Messen Sie vielleicht die Swap-Nutzung vor und nach dem Neustart.
Ich habe eine Art Speicherleck/Speichererweiterung auf einem meiner Server. Auf den vernünftigen Vorschlag von @RGJ hin habe ich einen Neustart jeden Montag früh (Westeuropa) per Cronjob geplant.
(Wir glauben, dass wir das Plugin mit dem Problem kennen, aber ich habe noch keine Zeit investiert, um herauszufinden, warum es ein Speicherleck/eine Speichererweiterung gibt.)
Dies sieht nach einem OOM-Kill aus: Ich habe ca. 2 GiB RAM und bei Zwei-Container-Neuerstellungen übersteigt die alte App + der neue Build den Speicher. Der Swap ist bereits vor dem Bootstrap auf ca. 3 GiB ausgelastet, sodass der Ember-Build-Spike mit SIGKILL beendet wird. Das Stoppen des laufenden Containers (oder eine Ein-Container-Neuerstellung) vermeidet die Überlappung und ist erfolgreich. Nächster Schritt ist die Bestätigung über dmesg und dann entweder ein Neustart vor den Neuerstellungen / Untersuchung, was den Swap im Laufe der Zeit in die Höhe treibt / RAM hinzufügen (der Swap allein scheint ihn nicht zu retten, wenn er bereits stark genutzt wird).
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.
Es scheint, als würde mehr Swap helfen. Es würde nicht schaden. Anstatt den gesamten Swap zu betrachten und zu sagen, es sei viel, schauen Sie auf den freien Swap und stellen Sie sicher, dass Sie Spielraum für einen Neuaufbau haben.
Klingt nach einer guten Idee! Starten Sie den Server neu oder nur den Container?
Jedenfalls ist es mir auf einem anderen 2GB+3GB Server wieder passiert. Dann habe ich web_only neu gestartet und es erneut versucht, und es funktionierte einwandfrei. Ich denke, ich werde zu meinen Tools hinzufügen, um web_only neu zu starten, vielleicht wenn der Speicher einen bestimmten Wert als „niedrig“ definiert.
Wir haben einen Fall gesehen, in dem ein Neustart von Linux geholfen hat. Ich weiß, dass wir Linux normalerweise nicht so betrachten wollen, aber es besteht immer noch die Möglichkeit von Fragmentierung und die Möglichkeit von Speicherlecks.
