Meteor Node Использование процессора CPU приближается к 100%

У меня возникают проблемы с моим приложением Meteor, когда он достигает максимального количества трафика (пик для этого - ничто, 1k посещений, а может быть 2500 просмотров страниц в день). CPU использует всплески и никогда не восстанавливается, поэтому я использовал Nodetime для мониторинга использования, и я перезагрузил процесс (forever restart), чтобы вернуть нормальное состояние.

Я новичок в профилировании, поэтому найти основную причину я не понимаю, с чего начать. Я вполне уверен, что это связано с моим кодом сервера приложений, но профилирование, по-видимому, указывает на модуль Fibers как "горячую точку", который, как я понимаю, помогает сделать код сервера синхронным.

Ниже приведен фрагмент результатов профилирования. Надеюсь, кто-то может помочь мне в правильном направлении в устранении этой проблемы!

enter image description here

ОТВЕТЫ

Ответ 1

В то время как у меня нет конкретного ответа на ваш вопрос, у меня есть опыт работы с проблемами процессора для нашего приложения meteor производства, поэтому я могу дать вам список вещей для расследования.

  • Перейдите к последней версии метеора и соответствующей версии node (см. журнал изменений). На момент написания это метеор 0.8.2 и node 0.10.28.

  • Прочитайте this и эту статью. Последнее делает большой вывод, что вы действительно должны всегда пытаться откладывать активацию подписки, пока они вам не понадобятся. В частности, вам может не понадобиться публиковать что-либо для пользователей, которые не вошли в систему. По моему опыту, проблемы с метеорным процессором имеют все, что связано с подписками.

  • Будьте осторожны с observe и observeChanges. Это дорогой и их легко использовать. В частности:

    • Убедитесь, что вы вызываете stop() на своих дескрипторах, когда они больше не нужны (подумайте об использовании пакета, например publish-with-relations, чтобы это делается для вас).
    • Выбираем только те коллекции и поля, которые вам абсолютно необходимы. Наблюдайте за работой, постоянно различая объекты (требуется много CPU). Чем меньше и меньше объектов у вас есть, тем меньше приходится вычислять.

  • Рассмотрите возможность использования smart-collections до отставной. Используйте oplog tailing - это может привести к разнице в производительности и производительности процессора в ночном и дневном времени в вашем приложении.

    /li >

  • Считайте, что некоторые вещи не реагируют (также упоминается в статьях выше). Для нас это была большая победа. У нас было одно чрезвычайно дорогое соединение, которое использовалось на двух часто доступных страницах на сайте. Когда он дошел до того, что процессор был привязан на 100% каждые 30 минут, я отказался от реактивности для этого элемента и просто присоединился к серверу и отправил данные клиенту с помощью вызова метода. Я также создал кеширующий кэш на стороне сервера для этих результатов и сохранил их пользователем (особая благодарность Мэтту Дебергалису за это предложение).

  • Сделайте профилактический ночной перезапуск. У меня есть задание cron, которое сообщает forever перезапустить наше приложение один раз в день в середине ночи. Это приводит к снижению КПД с ~ 10% до 1%. Это похоже на черную магию, но тот факт, что использование ЦП изменяется после reset, заставляет меня думать, что это хорошая идея.

Обновленные мысли (1/13/14)

  • Мы перешли на oplog tailing, как только он был доступен (метеор 0.7), и это имело большое значение. Обратите внимание, что для получения доступа к oplog вам, вероятно, потребуется либо разместить свой собственный db, либо запустить выделенный экземпляр на хостинг-провайдере по вашему выбору. Я также рекомендую добавить пакет facts, чтобы действительно сказать, работает ли он.

  • В publish-with-relations обнаружена утечка памяти, и с этой точки зрения версия атмосферы (v0.1.5) не была затронута, чтобы отразить эти изменения. Если вы используете его в производстве, я настоятельно рекомендую проверить версию HEAD и запустить ее локально.

  • Мы перестали делать ночные перезагрузки пару недель назад. Пока все было хорошо (пальцы скрещены).

Обновленные мысли (7/2/14)

  • Несколько месяцев назад мы переключились на использование Elastic Deployment на mongohq. Это было доступно, производительность была отличной, и у них даже есть сообщение в блоге, в котором рассказывается, как включить хвостовое оперение.

  • Я настоятельно рекомендую проверить kadira, чтобы помочь в диагностике проблем с производительностью в вашем приложении. Также ознакомьтесь с статьями академии, в которых есть много хороших советов.

Ответ 2

У меня также есть эта проблема. На самом деле существует проблема с 0.6.6.1, я запускаю meteor --release 0.6.6, и процессор возвращается к нормальному состоянию сейчас.