当Meteor应用达到峰值流量时,我遇到了麻烦(请注意,这没什么,每天访问1000次,一天的综合浏览量可能为2500次)。CPU使用率会激增并且永远不会恢复,因此我开始使用Nodetime来监视使用率,并且我一直在重新加载进程(forever restart)以使一切恢复正常。
forever restart
我对概要分析还很陌生,因此找到根本原因使我不知所措。我相当确定它与我的应用程序的服务器代码有关,但性能分析似乎将Fibers模块指向“热点”,据我了解,这有助于使服务器代码同步。
以下是分析结果的摘要。我希望有人可以引导我朝着正确的方向进行故障排除!
虽然我没有针对您问题的具体答案,但我有处理生产流星应用程序的CPU问题的经验,因此我可以向您提供要调查的事情的列表。
升级到最新版本的流星和相应的节点版本(请参阅changelog)。在撰写本文时,这是流星0.8.2和节点0.10.28。
阅读本文和这篇文章。后者提出了一个很好的观点,即您确实应该始终尝试延迟激活订阅,直到需要它们为止。特别是,您可能不需要为未登录的用户发布任何内容。根据我的经验,流星CPU问题与订阅有关。
请注意observe和observeChanges。这些很 昂贵 ,很容易滥用。特别是:
observe
observeChanges
stop()
考虑使某些事物不具有反应性(在上面的文章中也提到过)。对我们来说,这是一个巨大的胜利。我们有一个非常昂贵的联接,该联接在站点上两个经常访问的页面上使用。当达到每30分钟将CPU固定为100%的程度时,我放弃了该元素的反应性,只是在服务器上进行了连接,并通过方法调用将数据发送给了客户端。我还为这些结果创建了一个服务器端过期缓存,并按用户存储了它们(特别感谢Matt DeBergalis的建议)。
每晚进行一次预防性重启。我有一份Cron作业,forever每天半夜重启一次我们的应用程序。这使CPU从约10%降至1%。这似乎是不可思议的事情,但是在重置后CPU使用率发生变化的事实使我相信这是个好主意。
forever
我们尽快将其迁移到oplog尾矿(流星0.7),这带来了很大的变化。请注意,为了访问操作日志,您可能需要托管自己的数据库或在您选择的托管提供程序上运行专用实例。我还建议添加该facts软件包,以实际判断其是否有效。
facts
在中发现了内存泄漏publish-with-relations,截至撰写本文时,大气版本(v0.1.5)并未受到影响以反映这些更改。如果您在生产环境中使用它,强烈建议您检出HEAD版本并在本地运行它。
publish-with-relations
几周前,我们停止了每晚重启。到目前为止,一切都很好(手指交叉)。
几个月前,我们切换到在mongohq上使用弹性部署。它价格适中,性能非常好,他们甚至还有一篇博客文章,告诉您如何启用oplog拖尾。
我强烈建议您检出kadira,以帮助诊断您应用中的性能问题。另外,请查阅其中包含许多技巧的学术文章。