我的 Meteor 应用程序在流量达到峰值时遇到了问题（峰值算不了什么，1k 次访问，一天内可能有 2,500 次网页浏览量）。 CPU 使用率飙升并且永远不会恢复，因此我开始使用 Nodetime 来监控使用情况，并且我一直在重新加载进程 (forever restart) 以使事情恢复正常。
我对分析还很陌生，所以找到根本原因让我不知从何下手。我相当肯定这与我的应用程序的服务器代码有关，但分析似乎将 Fibers 模块指向一个“热点”，据我所知，它有助于使我的服务器代码同步。
下面是分析结果的 sn-p。我希望有人能在正确的方向上指导我解决这个问题！
【问题讨论】：
虽然我对您的问题没有具体答案，但我有处理生产流星应用程序的 CPU 问题的经验，因此我可以为您提供一份需要调查的事项列表。
升级到最新版本的流星和适当的节点版本（见changelog）。在撰写本文时，流星 0.8.2 和节点 0.10.28。
阅读this 和this 文章。后者提出了一个很好的观点，即您确实应该始终尝试延迟激活订阅，直到您需要它们为止。特别是您可能不需要为未登录的用户发布任何内容。根据我的经验，meteor CPU 问题与订阅有关。
小心observe 和observeChanges。这些是昂贵并且很容易被滥用。特别是：
stop()（考虑使用像 publish-with-relations 这样的包，这样就可以完成）。在retired 之前考虑使用smart-collections。 使用oplog tailing - 这可能会在您的应用程序的性能和 CPU 使用率方面产生昼夜差异。
考虑让一些东西不响应（在上面的文章中也提到过）。对我们来说，这是一个巨大的胜利。我们有一个极其昂贵的连接，用于站点上两个经常访问的页面。当它达到 CPU 大约每 30 分钟固定在 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，其中包含许多很好的提示。
【讨论】：
我也遇到了这个问题。实际上有一个issue with 0.6.6.1，我运行meteor --release 0.6.6，cpu 现在恢复正常了。
【讨论】：