【问题标题】:Server collapses when memory reaches 88%内存达到 88% 时服务器崩溃
【发布时间】:2018-07-28 17:36:22
【问题描述】:

我在 8 GB 内存 / 80 GB 磁盘 / Ubuntu 16.04.3 x64 / 4 个 vCPU 的 Digital Ocean 液滴中使用带有 Angular 通用的服务器端渲染和 PM2 作为进程管理器。

我用的是6GB的swap文件,“free -m”时可用内存如下:

          total    used        free      shared  buff/cache   available
Mem:       7983    1356        5290          16        1335        6278
Swap:      6143      88        6055

ram used 看起来不错。 PM2集群模式有4个进程。

每隔 6-8 小时,当我的 Digital Ocean 面板中的内存达到 ~88% 时,CPU 会变得非常高,Web 应用程序无法正确响应,PM2 必须重新启动进程,不确定 Web 需要多长时间应用程序无法正常运行。

这是发生了什么的图片:

正常工作时性能还不错:

我想我缺少某种配置或其他东西,因为这总是在同一时间段发生。

EDIT1 到目前为止,我修复了我的代码中的一些不兼容问题(应用程序正在运行,但有时因此失败),并添加了一个 1GB 的 memory limit in pm2。我不确定这是否是要走的路,因为我对进程管理有点陌生,但现在 CPU 水平很好。任何评论表示赞赏。我留下了当前行为的图片,每次四个进程中的一个达到 1GB 时,它都会重新启动:

EDIT2我添加了 3 张图片,2 张显示来自 Digital Ocean 的顶级进程,还有一张显示 Keymetrics 状态:

EDIT3 我发现我的 Angular 应用程序存在一些内存泄漏(我忘记取消订阅几个订阅)并且系统行为得到了改善,但内存线仍在上升。我会继续调查 Angular 中的内存泄漏问题,看看我是否犯了其他错误:

【问题讨论】:

  • 你能看看/var/log/messages有什么有用的吗?您是否看到系统杀死了内存不足 (OOM) 的进程?重启时哪个应用程序正在使用 CPU?
  • 我在 /var/log 中没有该文件,但在 kernel.log 和 syslog 中我只有“[UFW BLOCK]”消息。内存溢出的进程(来自数字海洋Top Processes)是:“node /var/www/name-of-the-app”。我再附上 3 张图片:来自数字海洋和 Keymetrics 面板的顶级流程
  • 内存经常重启是否“正常”?
  • 不,绝对不正常。看看“Angular Universal”和内存泄漏,也许会有所收获。
  • 谢谢,我认为问题来自“Angular 内存泄漏”。我没有取消订阅几个订阅。现在我做得更好了,但记忆线不断上升,我用另一张图片更新了帖子。既然你指出了问题,我会给你奖励,但是你能告诉我你是否知道任何可以让我了解这一点的来源吗?或有关预期的内存行为以及何时应该升级服务器的任何信息?我找不到与“内存正常行为”相关的任何信息。这条线应该总是水平的,有一些起伏?

标签: server monitoring digital-ocean pm2 angular-universal


【解决方案1】:

看起来您的 Angular Universal 应用程序正在泄漏内存,它不应该随着您观察到的时间增加,而是基本保持平稳。

您可以尝试查找内存泄漏(看起来您已经发现了一个问题并怀疑它可能是什么)。

您可以尝试的另一件事是定期重启您的应用。 请参阅here,例如如何每隔几个小时重新启动您的 pm2 进程以重置并防止您遇到的 OOM 情况。

【讨论】:

    【解决方案2】:

    在我们的(边缘)案例中,kubernetes 运行状况检查是问题的原因。健康检查通过内部 IP 访问主页。该页面使用调用方 URL(在本例中为它的 IP)来加载一些它无法以这种方式找到的资源。这会导致错误并以某种方式被缓存并慢慢耗尽所有内存。由于健康检查的规律性,即使在夜间,我们的记忆力也会呈线性增长。

    我们通过让运行状况检查调用“/health”解决了这个问题,我们只返回一个 200 代码。无论如何都应该这样做。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-06-12
      • 2017-07-29
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多