mongodb mystery падает с сигкилом под страйсом

Question

mongodb mystery падает с сигкилом под страйсом

У меня есть экземпляр mongodb, который, кажется, падает примерно один раз в день. Я не вижу никакой полезной информации в файле журнала Монго. Все хорошо, и тогда процесс просто падает без дополнительной информации. Я запустил его под стражей в надежде получить несколько полезных подсказок, пока он не рухнул и не получил такой вывод:

Wed Apr 17 10:56:39.340 [conn172]               M/R: (1/3) Emit Progress: 2800/4351     64%
Wed Apr 17 10:57:16.696 [PeriodicTask::Runner] task: DBConnectionPool-cleaner took: 16ms
Wed Apr 17 10:57:17.035 [PeriodicTask::Runner] task: WriteBackManager::cleaner took: 17ms
Wed Apr 17 10:57:17.429 [PeriodicTask::Runner] task: DBConnectionPool-cleaner took: 79ms
+++ killed by SIGKILL +++

Это происходит только на одной конкретной виртуальной машине, а остальные в порядке. Также проверял почасовую / ежедневную работу cron на случай, если что-то пошло наперекосяк и убило Монгода, но подозреваемых там не было.

ОС: Ubuntu 12.04.2

Монго: 2.4.1

Что-нибудь еще, что я могу сделать для дальнейшего устранения проблем?

1

ubuntu-12.04 mongodb strace

Источник

Peter Lyons 17 апр '13 в 19:04

1 ответ

Другие вопросы по тегам ubuntu-12.04 mongodb strace

Adam C 22 май '13 в 17:40 2013-05-22 17:40 · Answer 1 · 2013-05-22 17:40

Вы выполняете задание Map Reduce во время его уничтожения, всегда ли это так?

Я спрашиваю, потому что это похоже на поведение, которое вы получаете, когда процесс сторожевого типа решает, что вы используете слишком много памяти, и убивает процесс. Задания Map Reduce (в частности, встроенные или те, которые выполняются на больших наборах данных), как правило, быстро увеличивают использование оперативной памяти.

SIGKILL - это не то, что вы получили бы, если бы это ядро решило, что у вас недостаточно памяти, и вызвало убийцу OOM (это похоже на тихий сбой и зарегистрирован в dmesg). Следовательно, это заставило бы меня поверить, что есть что-то еще, делающее убийство, чтобы предотвратить использование памяти выше определенного порога.

Если вы хотите проверить, запустите db.collection.find().explain() на большом наборе данных и посмотреть, вызывает ли это также SIGKILL. Если это так, я не думаю, что этот тип виртуальной машины подходит для работы с базой данных с отображением памяти.