12

当我的 Meteor 应用程序达到峰值流量时,我遇到了问题(峰值算不了什么,1k 次访问,一天可能有 2,500 次浏览量)。CPU 使用率达到峰值并且永远不会恢复,因此我开始使用 Nodetime 来监控使用情况,并且我一直在重新加载进程 ( forever restart) 以使事情恢复正常。

我对分析还很陌生,所以找到根本原因让我不知从何开始。我相当肯定它与我的应用程序的服务器代码有关,但分析似乎指向 Fibers 模块作为“热点”,我理解它有助于使我的服务器代码同步。

下面是分析结果的一个片段。我希望有人可以指导我正确的方向来解决这个问题!

在此处输入图像描述

4

2 回答 2

33

虽然我对您的问题没有具体答案,但我有处理生产流星应用程序的 CPU 问题的经验,因此我可以为您提供要调查的事项列表。

  1. 升级到最新版本的流星和适当的节点版本(请参阅更新日志)。在撰写本文时,流星 0.8.2 和节点 0.10.28。

  2. 阅读这篇文章和这篇文章。后者提出了一个很好的观点,即您确实应该始终尝试延迟激活订阅,直到您需要它们为止。特别是您可能不需要为未登录的用户发布任何内容。根据我的经验,meteor CPU 问题与订阅有关。

  3. 小心observeobserveChanges。这些很昂贵并且很容易被滥用。尤其是:

    • 确保stop()在不再需要句柄时调用它们(考虑使用像publish-with-relations这样的包,这样就可以完成)。
    • 仅获取您绝对需要的集合和字段。通过不断区分对象来观察工作(需要大量 CPU)。你拥有的对象越少越小,需要计算的东西就越少。
  4. 考虑在它退役之前使用智能收藏使用oplog 拖尾- 这会在您的应用程序中的性能和 CPU 使用率上产生昼夜差异。

  5. 考虑让一些事情不被动(在上面的文章中也提到过)。对我们来说,这是一个巨大的胜利。我们有一个极其昂贵的连接,用于站点上两个经常访问的页面。当它达到 CPU 大约每 30 分钟固定在 100% 的地步时,我放弃了对该元素的反应性,只是在服务器上进行连接,并通过方法调用将数据发送到客户端。我还为这些结果创建了一个服务器端过期缓存,并由用户存储(特别感谢 Matt DeBergalis 的建议)。

  6. 做一个预防性的夜间重启。我有一个 cron 作业,告诉forever我们每天半夜重新启动一次我们的应用程序。这使 CPU 从约 10% 下降到 1%。这似乎是黑魔法,但重置后 CPU 使用率发生变化的事实让我相信这是一个好主意。

更新的想法(1/13/14)

  • 一旦oplog tailing可用(meteor 0.7),我们就迁移到它,这产生了很大的不同。请注意,为了访问 oplog,您可能需要托管自己的数据库或在您选择的托管服务提供商上运行专用实例。我还建议添加facts包以实际判断它是否工作。

  • 在 中发现了内存泄漏publish-with-relations,并且在撰写本文时,大气版本 (v0.1.5) 还没有被碰撞以反映这些变化。如果您在生产中使用它,我强烈建议您查看 HEAD 版本并在本地运行它。

  • 几周前我们停止了夜间重启。到目前为止,一切都很好(手指交叉)。

更新的想法(7/2/14)

  • 几个月前,我们转而在mongohq上使用弹性部署。它价格实惠,性能非常好,他们甚至有一篇文告诉你如何启用 oplog 拖尾。

  • 我强烈建议您查看kadira以帮助诊断您的应用程序中的性能问题。还可以查看学院文章,其中包含许多好的技巧。

于 2013-10-19T17:03:22.333 回答
1

我也有这个问题。实际上0.6.6.1存在问题,我运行meteor --release 0.6.6并且 cpu 现在恢复正常。

于 2013-10-20T16:42:57.263 回答