重建时内存不足，即使有 4GB 交换空间？

安装
1

我今天遇到了几次双容器引导失败，错误信息类似：

 ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL 命令因 SIGKILL（强制终止）而被终止：ember build -prod”]

我想在添加交换空间后，它在下一次运行时成功了。但这是 4GB 的交换空间：

# free -h
               total        used        free      shared  buff/cache   available
Mem:           1.9Gi       1.1Gi       391Mi        45Mi       661Mi       830Mi
Swap:          4.0Gi       3.1Gi       911Mi

但它仍然失败。如果我在引导之前停止容器，它会成功。

1 个赞
2

构建是否正在获取/使用预构建资源？还是您禁用了它？（或者修改了核心代码，使得预构建资源无法使用）

2 个赞
3

您的交换空间很多，但其中很大一部分已被使用。由于双容器设置的停机时间较短，也许当前正在运行的服务器实例仍然在运行，并且由于内存泄漏等原因占用了大量内存。

也许在更新之前重启一下会有帮助。也许可以测量重启前后的交换空间使用情况。

3 个赞
4

我的某个服务器出现某种内存泄漏/膨胀问题。根据 @RGJ 的合理建议，我设置了 cron 计划，在每周一凌晨（西欧时间）重启一次。

（我们认为我们知道有问题的插件，但我还没有花时间找出内存泄漏/膨胀的原因。）

2 个赞
5

这看起来像是内存溢出（OOM）终止：我使用的是约 2 GiB 内存，在双容器重建中，旧应用和新构建的重叠将内存推过极限。在引导之前，交换空间（Swap）已经使用了约 3 GiB，因此 Ember 构建的峰值被发送了 SIGKILL 信号。停止正在运行的容器（或进行单容器重建）可以避免重叠并成功。下一步是通过 dmesg 确认，然后要么在重建前重启 / 调查是什么导致交换空间随时间推移而增加 / 增加内存（一旦交换空间已被大量使用，仅靠交换空间似乎无法挽救）。

1 个赞
6

这看起来更像是宿主机耗尽内存的问题，而不是 pnpm 或 Ember 的问题。

关键细节是 SIGKILL。这通常意味着操作系统介入并终止了进程（通常是通过 OOM killer），而不是 ember build -prod 本身失败了。

在小型宿主机上，Ember 的生产环境构建很容易导致内存占用飙升至几 GB。即使启用了交换分区（swap），一旦交换分区大部分被使用，内核仍然可能决定终止一个占用大量内存的 node 进程。

有几点指向这个方向：

  • 发生故障时，交换分区已经被大量使用。
  • 当另一个容器同时运行时，故障更有可能发生。
  • 如果我在运行引导程序之前停止另一个容器，完全相同的构建就能成功。

因此，交换分区有一点帮助，但它主要只是推迟了问题。停止其他容器可以降低内存压力，使构建得以完成。

有帮助的/可能有所帮助的措施：

  • 避免并行运行多个引导程序或资源构建。
  • 在 ember build -prod 期间停止其他容器。
  • 限制 Node 的内存使用（例如 NODE_OPTIONS=--max_old_space_size=1024）以减少峰值使用量。
  • 如果可能，增加宿主机内存（4GB+）会使这种情况可靠得多。

希望这有助于解释为什么它感觉有点随机，以及为什么停止另一个容器能使其工作。

2 个赞
7

感觉增加更多的交换空间会有帮助。增加一些也无妨。不要只看总交换空间并认为它很多，而要查看可用交换空间，并确保你有重建所需的余量。

2 个赞
8

另外，请检查您是否已启用超额分配（overcommit）。

9

听起来是个好主意！你是重启服务器还是只重启容器？

无论如何，我的另一个 2GB+3GB 的服务器又出现了这种情况。然后我重启了 web_only 再次尝试，它运行得很好。我想我会将重启 web_only 添加到我的工具中，也许当内存低于某个“低”的定义时。

感谢大家提供的建议！

1 个赞
10

整个服务器 :sweat_smile:

2 个赞
11

老天，这不是 Windows。:rofl:

2 个赞
12

哦，天哪，我记得那些日子！:grimacing:

2 个赞
13

我们确实看到一个案例，重启 Linux 有所帮助。我知道这通常不是我们喜欢看待 Linux 的方式，但仍然存在碎片化和内存泄漏的可能性。

2 个赞