虽然我没有针对您问题的具体答案，但我有处理生产流星应用程序的CPU问题的经验，因此我可以向您提供要调查的事情的列表。
升级到最新版本的流星和相应的节点版本（请参阅changelog）。在撰写本文时，这是流星0.8.2和节点0.10.28。
阅读本文和这篇文章。后者提出了一个很好的观点，即您确实应该始终尝试延迟激活订阅，直到需要它们为止。特别是，您可能不需要为未登录的用户发布任何内容。根据我的经验，流星CPU问题与订阅有关。
请注意
observe
和observeChanges
。这些很 昂贵 ，很容易滥用。特别是：- 确保
stop()
不再需要它们时调用它们的句柄（考虑使用诸如publish-with-relations之类的包，以便您完成此操作）。 - 仅获取您绝对需要的集合和字段。通过不断地扩散对象来观察工作（需要大量的CPU）。您拥有的对象越少，计算的内容就越少。
考虑使用 智能收藏它之前退休。使用oplog拖尾 -这可以使您的应用在性能和CPU使用率上昼夜不同。
- 确保
考虑使某些事物不具有反应性（在上面的文章中也提到过）。对我们来说，这是一个巨大的胜利。我们有一个非常昂贵的联接，该联接在站点上两个经常访问的页面上使用。当达到每30分钟将CPU固定为100％的程度时，我放弃了该元素的反应性，只是在服务器上进行了连接，并通过方法调用将数据发送给了客户端。我还为这些结果创建了一个服务器端过期缓存，并按用户存储了它们（特别感谢Matt DeBergalis的建议）。
每晚进行一次预防性重启。我有一份Cron作业，
forever
每天半夜重启一次我们的应用程序。这使CPU从约10％降至1％。这似乎是不可思议的事情，但是在重置后CPU使用率发生变化的事实使我相信这是个好主意。
更新的想法（1/13/14）
我们尽快将其迁移到oplog尾矿（流星0.7），这带来了很大的变化。请注意，为了访问操作日志，您可能需要托管自己的数据库或在您选择的托管提供程序上运行专用实例。我还建议添加该
facts
软件包，以实际判断其是否有效。在中发现了内存泄漏
publish-with-relations
，截至撰写本文时，大气版本（v0.1.5）并未受到影响以反映这些更改。如果您在生产环境中使用它，强烈建议您检出HEAD版本并在本地运行它。几周前，我们停止了每晚重启。到目前为止，一切都很好（手指交叉）。
更新的想法（7/2/14）
几个月前，我们切换到在mongohq上使用弹性部署。它价格适中，性能非常好，他们甚至还有一篇博客文章，告诉您如何启用oplog拖尾。
我强烈建议您检出kadira，以帮助诊断您应用中的性能问题。另外，请查阅其中包含许多技巧的学术文章。
