これは pnpm や Ember の問題というより、ホストが単にメモリ不足になったように見えます。
重要な詳細は SIGKILL です。これは通常、OS が介入してプロセスを強制終了させた（多くの場合、OOM killer によって）ことを意味し、ember build -prod が単独で失敗したわけではありません。
小規模なホストでは、Ember の本番ビルドは簡単に数GBのRAMを消費することがあります。スワップが有効になっていても、スワップがほとんど使用されると、カーネルはメモリを大量に消費する node プロセスを強制終了させる可能性があります。
この方向性を示すいくつかの点があります。
- 障害が発生した時点でスワップがすでに多用されている。
- 別のコンテナが同時に実行されている場合に障害が発生する可能性が高い。
- ブートストラップを実行する前に別のコンテナを停止すると、全く同じビルドが成功する。
したがって、スワップは多少役立ちますが、主に問題の発生を遅らせるだけです。別のコンテナを停止すると、ビルドが完了するのに十分なメモリ圧力が緩和されます。
役立った点／役立つ可能性のある点：
- 複数のブートストラップやアセットビルドを並行して実行することを避ける。
ember build -prodの実行中に別のコンテナを停止する。- Node のメモリ使用量を制限する（例：
NODE_OPTIONS=--max_old_space_size=1024）ことで、ピーク使用量を削減する。 - 可能であれば、ホストの RAM を増やす（4GB以上）と、これがはるかに信頼性が高くなります。
これが、問題が少しランダムに感じられる理由や、別のコンテナを停止すると動作するようになる理由を説明するのに役立つことを願っています。