# 重建时内存不足，即使有 4GB 交换空间？ **URL:** \ **Category:** Self-hosting\ **Created:** [2026年一月6日 23:41 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831 "2026-01-06T23:41:29Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2026年一月6日 23:41 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/1 "2026-01-06T23:41:29Z")
我今天遇到了几次双容器引导失败，错误信息类似： ``` ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL 命令因 SIGKILL（强制终止）而被终止：ember build -prod”] ``` 我想在添加交换空间后，它在下一次运行时成功了。但这是 4GB 的交换空间： ```plaintext # free -h total used free shared buff/cache available Mem: 1.9Gi 1.1Gi 391Mi 45Mi 661Mi 830Mi Swap: 4.0Gi 3.1Gi 911Mi ``` 但它仍然失败。如果我在引导之前停止容器，它会成功。 ---
**Author:** ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)\ **Post date:** [2026年一月6日 23:48 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/2 "2026-01-06T23:48:20Z")
构建是否正在获取/使用预构建资源？还是您禁用了它？（或者修改了核心代码，使得预构建资源无法使用） ---
**Author:** ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)\ **Post date:** [2026年一月7日 09:57 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/3 "2026-01-07T09:57:16Z")
您的交换空间很多，但其中很大一部分已被使用。由于双容器设置的停机时间较短，也许当前正在运行的服务器实例仍然在运行，并且由于内存泄漏等原因占用了大量内存。 也许在更新之前重启一下会有帮助。也许可以测量重启前后的交换空间使用情况。 ---
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [2026年一月7日 10:13 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/4 "2026-01-07T10:13:31Z")
我的某个服务器出现某种内存泄漏/膨胀问题。根据 @RGJ 的合理建议，我设置了 cron 计划，在每周一凌晨（西欧时间）重启一次。 （我们认为我们知道有问题的插件，但我还没有花时间找出内存泄漏/膨胀的原因。） ---
**Author:** ![Ethsim2](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ethsim2/32/522255_2.png) [@Ethsim2](https://meta.discourse.org/u/Ethsim2)\ **Post date:** [2026年一月7日 11:39 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/5 "2026-01-07T11:39:45Z")
这看起来像是内存溢出（OOM）终止：我使用的是约 2 GiB 内存，在双容器重建中，旧应用和新构建的重叠将内存推过极限。在引导之前，交换空间（Swap）已经使用了约 3 GiB，因此 Ember 构建的峰值被发送了 SIGKILL 信号。停止正在运行的容器（或进行单容器重建）可以避免重叠并成功。下一步是通过 `dmesg` 确认，然后要么在重建前重启 / 调查是什么导致交换空间随时间推移而增加 / 增加内存（一旦交换空间已被大量使用，仅靠交换空间似乎无法挽救）。 ---
**Author:** ![Thefacto](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/thefacto/32/537948_2.png) [@Thefacto](https://meta.discourse.org/u/Thefacto)\ **Post date:** [2026年一月7日 11:49 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/6 "2026-01-07T11:49:05Z")
这看起来更像是宿主机耗尽内存的问题，而不是 pnpm 或 Ember 的问题。 关键细节是 `SIGKILL`。这通常意味着操作系统介入并终止了进程（通常是通过 OOM killer），而不是 `ember build -prod` 本身失败了。 在小型宿主机上，Ember 的生产环境构建很容易导致内存占用飙升至几 GB。即使启用了交换分区（swap），一旦交换分区大部分被使用，内核仍然可能决定终止一个占用大量内存的 `node` 进程。 有几点指向这个方向： - 发生故障时，交换分区已经被大量使用。 - 当另一个容器同时运行时，故障更有可能发生。 - 如果我在运行引导程序之前停止另一个容器，完全相同的构建就能成功。 因此，交换分区有一点帮助，但它主要只是推迟了问题。停止其他容器可以降低内存压力，使构建得以完成。 有帮助的/可能有所帮助的措施： - 避免并行运行多个引导程序或资源构建。 - 在 `ember build -prod` 期间停止其他容器。 - 限制 Node 的内存使用（例如 `NODE_OPTIONS=--max_old_space_size=1024`）以减少峰值使用量。 - 如果可能，增加宿主机内存（4GB+）会使这种情况可靠得多。 希望这有助于解释为什么它感觉有点随机，以及为什么停止另一个容器能使其工作。 ---
**Author:** ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)\ **Post date:** [2026年一月7日 12:17 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/7 "2026-01-07T12:17:11Z")
感觉增加更多的交换空间会有帮助。增加一些也无妨。不要只看总交换空间并认为它很多，而要查看可用交换空间，并确保你有重建所需的余量。 ---
**Author:** ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)\ **Post date:** [2026年一月7日 12:19 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/8 "2026-01-07T12:19:31Z")
另外，请检查您是否已启用超额分配（overcommit）。 > [@Ed\_S](#): > > 我非常相信，一旦你设置了超额分配，你需要的交换空间就会更少。 ---
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2026年一月7日 18:20 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/9 "2026-01-07T18:20:51Z")
> [@merefield](#): > > 我的某个服务器出现了某种内存泄漏/膨胀。根据 @RGJ 的合理建议，我设置了 cron 计划，在每周一凌晨（西欧时间）重启一次。 听起来是个好主意！你是重启服务器还是只重启容器？ 无论如何，我的另一个 2GB+3GB 的服务器又出现了这种情况。然后我重启了 `web_only` 再次尝试，它运行得很好。我想我会将重启 `web_only` 添加到我的工具中，也许当内存低于某个“低”的定义时。 感谢大家提供的建议！ ---
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [2026年一月7日 19:27 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/10 "2026-01-07T19:27:01Z")
> [@pfaffman](#): > > 听起来是个好主意！你是重启服务器还是只重启容器？ 整个服务器 😅 ---
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2026年一月7日 20:40 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/11 "2026-01-07T20:40:36Z")
> [@merefield](#): > > 整个服务器 😅 老天，这不是 Windows。🤣 ---
**Author:** ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\ **Post date:** [2026年一月7日 20:46 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/12 "2026-01-07T20:46:26Z")
哦，天哪，我记得那些日子！😬 ---
**Author:** ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)\ **Post date:** [2026年一月8日 07:44 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/13 "2026-01-08T07:44:37Z")
我们确实看到一个案例，重启 Linux 有所帮助。我知道这通常不是我们喜欢看待 Linux 的方式，但仍然存在碎片化和内存泄漏的可能性。 ---
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2026年二月7日 07:45 UTC](https://meta.discourse.org/t/out-of-memory-on-rebuild-with-4gb-swap/392831/14 "2026-02-07T07:45:21Z")
此主题在最后一次回复后 30 天自动关闭。不再允许新的回复。