这看起来更像是宿主机耗尽内存的问题,而不是 pnpm 或 Ember 的问题。
关键细节是 SIGKILL。这通常意味着操作系统介入并终止了进程(通常是通过 OOM killer),而不是 ember build -prod 本身失败了。
在小型宿主机上,Ember 的生产环境构建很容易导致内存占用飙升至几 GB。即使启用了交换分区(swap),一旦交换分区大部分被使用,内核仍然可能决定终止一个占用大量内存的 node 进程。
有几点指向这个方向:
- 发生故障时,交换分区已经被大量使用。
- 当另一个容器同时运行时,故障更有可能发生。
- 如果我在运行引导程序之前停止另一个容器,完全相同的构建就能成功。
因此,交换分区有一点帮助,但它主要只是推迟了问题。停止其他容器可以降低内存压力,使构建得以完成。
有帮助的/可能有所帮助的措施:
- 避免并行运行多个引导程序或资源构建。
- 在
ember build -prod期间停止其他容器。 - 限制 Node 的内存使用(例如
NODE_OPTIONS=--max_old_space_size=1024)以减少峰值使用量。 - 如果可能,增加宿主机内存(4GB+)会使这种情况可靠得多。
希望这有助于解释为什么它感觉有点随机,以及为什么停止另一个容器能使其工作。