当我的Meteor应用程序达到其最高流量时,我遇到了问题(此高峰没什么,1k访问量,一天可能有2,500次综合浏览量)。 CPU使用率激增并且永远不会恢复,因此我已经开始使用Nodetime来监控使用情况,并且我一直在重新加载流程(forever restart
)以使事情恢复正常。
我对分析很新,所以找到根本原因使我无法从哪里开始。我很确定它与我的应用程序的服务器代码有关,但分析似乎指向Fibers模块作为“热点”我理解帮助我使服务器代码同步。
以下是分析结果的摘录。我希望有人可以指导我正确的方向进行故障排除!
答案 0 :(得分:33)
虽然我对您的问题没有具体的答案,但我有处理生产流星应用程序的CPU问题的经验,所以我可以给你一个要调查的事项列表。
升级到最新版本的meteor和相应的节点版本(请参阅changelog)。截至本文撰写时,流星为0.8.2,节点为0.10.28。
阅读this和this文章。后者非常重要,你应该总是尝试延迟激活订阅,直到你需要它们。特别是您可能不需要为未登录的用户发布任何内容。根据我的经验,流星CPU问题与订阅有关。
小心observe
和observeChanges
。这些昂贵并且容易被滥用。特别是:
stop()
(考虑使用像publish-with-relations这样的程序包,这样就可以了。) 在smart-collections之前考虑使用retired。 使用oplog tailing - 这可以使您的应用在性能和CPU使用方面有日夜差异。
考虑制作一些不具有反应性的东西(在上面的文章中也有提及)。对我们来说这是一场大胜利。我们有一个非常昂贵的连接,用于网站上两个经常访问的页面。当它达到CPU每100分钟大约100%挂钩的程度时,我放弃了该元素的反应性,只是在服务器上进行了连接并通过方法调用将数据发送到客户端。我还为这些结果创建了一个服务器端过期缓存,并由用户存储(特别感谢Matt DeBergalis提供此建议)。
每晚重新开始预防。我有一个cron工作,告诉forever
每天半夜重启我们的应用程序。这使CPU从大约10%降低到1%。这看起来像黑魔法,但重置后CPU使用率发生变化这一事实让我相信这是一个好主意。
我们尽快迁移到oplog tailing(流星0.7)并且这有很大的不同。请注意,为了访问oplog,您可能需要托管自己的数据库或在您选择的主机提供程序上运行专用实例。我还建议添加facts
包来实际判断它是否正常工作。
在publish-with-relations
中发现了内存泄漏,截至撰写本文时,气氛版本(v0.1.5)尚未发现以反映这些变化。如果您在生产中使用它,我强烈建议您查看HEAD版本并运行它locally。
几个星期前我们停止了每晚重启。到目前为止一切都很好(手指交叉)。
几个月前,我们转而使用mongohq上的弹性部署。它价格实惠,性能非常好,甚至还有一个blog post告诉你如何启用oplog拖尾。
我强烈建议您查看kadira以帮助诊断应用中的效果问题。另请查看academy articles,其中包含许多好的提示。
答案 1 :(得分:1)
我也有这个问题。实际上有issue with 0.6.6.1,我运行meteor --release 0.6.6
,现在cpu恢复正常。