У меня есть приложение Meteor (0.8.0), развернутое с использованием Meteor до Digital Ocean, которое застряло на 100% -ном процессоре, только для того, чтобы потерпеть крах из-за нехватки памяти и снова запустить его на 100% -ном CPU. Он застрял так в течение последних 24 часов. Странная часть - никто не использует сервер, а meteor.log не показывает много подсказок. У меня есть MongoHQ с oplog для базы данных.
Цифровые характеристики океана:
1GB Ram 30GB SSD Disk New York 2 Ubuntu 12.04.3 x64
Снимок экрана, показывающий проблему:
Обратите внимание, что снимок экрана был взят вчера, и он остался привязан к 100% процессорному процессу, пока он не сработает с нехваткой памяти. В журнале отображается:
FATAL ERROR: Сбой эвакуации - процесс из памяти ошибка: обнаружено навсегда script было убито сигналом: ошибка SIGABRT: Перезапуск script навсегда
Верхние дисплеи:
26308 meteorus 20 0 1573m 644m 4200 R 98,1 64,7 32: 45,36 node
Как это началось: У меня есть приложение, которое берет список писем через csv или mailchimp oauth, отправляет их в fullcontact через их пакетный вызов http://www.fullcontact.com/developer/docs/batch/ и затем соответствующим образом обновляет коллекции Meteor в зависимости от статуса ответа. Отрывок из ответа 200
if (result.statusCode === 200) {
var data = JSON.parse(result.content);
var rate_limit = result.headers['x-rate-limit-limit'];
var rate_limit_remaining = result.headers['x-rate-limit-remaining'];
var rate_limit_reset = result.headers['x-rate-limit-reset'];
console.log(rate_limit);
console.log(rate_limit_remaining);
console.log(rate_limit_reset);
_.each(data.responses, function(resp, key) {
var email = key.split('=')[1];
if (resp.status === 200) {
var sel = {
email: email,
listId: listId
};
Profiles.upsert({
email: email,
listId: listId
}, {
$set: sel
}, function(err, result) {
if (!err) {
console.log("Upsert ", result);
fullContactSave(resp, email, listId, Meteor.userId());
}
});
RawCsv.update({
email: email,
listId: listId
}, {
$set: {
processed: true,
status: 200,
updated_at: new Date().getTime()
}
}, {
multi: true
});
}
});
}
Локально на моем wimpy ноутбуке Windows, работающем с Vagrant, у меня нет проблем с производительностью, обрабатывающих сотни тысяч электронных писем за раз. Но на Digital Ocean он даже не может справиться с 15 000 (я видел всплеск процессора до 100%, а затем сбой с OOM, но после того, как он появляется, он обычно стабилизируется... не в этот раз). Меня беспокоит, что сервер не восстановился вообще, несмотря на отсутствие активности в приложении. Я проверил это, посмотрев на аналитику. GA показывает 9 сеансов в течение 24 часов, делая немного больше, чем удары/и подпрыгивая, MixPanel показывает только 1 зарегистрированный пользователь (меня) в тот же таймфрейм. И единственное, что я сделал с момента первого сбоя, - это проверить пакет facts, который показывает:
mongo-livingata наблюдения-мультиплексоры 13 наблюдение-драйверы-oplog 13
oplog-watchers 16 наблюдающих ручек 15 фаз, затраченных времени в QUERYING
87828 время, потраченное в FETCHING-фаза 82 прожиточное
invalidation-crossbar-listeners 16 подписки 11 сеансов 1
Meteor APM также не показывает ничего необычного, meteor.log не показывает никакой метеорной активности, кроме OOM, и перезапускает сообщения. MongoHQ не сообщает ни о медленных запросах, ни о многих действиях - 0 запросов, обновлений, вставок, удалений в avg, глядя на панель мониторинга. Насколько я могу судить, в течение 24 часов активности не было много, и, конечно же, не было ничего интенсивного. С тех пор я пытаюсь установить newrelic и nodetime, но ни один из них не работает - newrelic не показывает никаких данных, а meteor.log имеет сообщение об отладке nodetime
Не удалось загрузить расширенное расширение nodetime.
Поэтому, когда я пытаюсь использовать nodetime CPU profiler, он становится пустым, а моментальный снимок кучи возвращается с Ошибка: инструменты V8 не загружаются.
У меня в основном нет идей на данный момент, и поскольку Node для меня довольно новичок, мне кажется, что я нахожусь в тихих местах в темноте. Пожалуйста, помогите.
Обновление: сервер по-прежнему привязан к 100% через четыре дня. Даже init 6 ничего не делает - перезапускается сервер, процесс Node запускается и возвращается до 100% процессора. Я пробовал другие инструменты, такие как memwatch и webkit-devtools-agent, но не мог заставить их работать с Meteor.
Ниже приведен вывод strace
strace -c -p 6840
Процесс 6840 прилагается - прерывание для выхода
^ CProcess 6840 отсоединен
% времени секунды ошибки usecs/call calls syscall
77.17 0.073108 1 113701 epoll_wait
11,15 0,010559 0 80106 39908 mmap
6.66 0.006309 0 116907 читать
2.09 0.001982 0 84445 futex
1,49 0,001416 0 45176 написать
0,68 0,000646 0 119975 munmap
0.58 0.000549 0 227402 clock_gettime
0.10 0.000095 0 117617 rt_sigprocmask
0,04 0,000040 0 30471 epoll_ctl
0,03 0,000031 0 71428 gettimeofday
0,00 0,000000 0 36 mprotect
0,00 0,000000 0 4 brk
100,00 0.094735 1007268 39908 всего
Итак, похоже, что процесс Node проводит большую часть своего времени в epoll_wait.
