У меня есть экземпляр mongodb, который, кажется, вылетает примерно раз в день. Я не вижу никакой полезной информации в файле журнала mongo. Все хорошо, а затем процесс просто прекращается без регистрации дополнительной информации. Я запускал его под strace в надежде получить полезные подсказки, пока он не вылетел и не получил такой результат:
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 на случай, если что-то пошло не так и убило mongod, но подозреваемых там нет.
Операционные системы: Ubuntu 12.04.2
Монго: 2.4.1
Что еще я могу сделать для дальнейшего устранения неполадок?
Вы выполняете задание «Сокращение карты» в момент, когда оно прекращается, всегда ли это так?
Я спрашиваю, потому что это похоже на поведение, которое вы получаете, когда процесс типа сторожевого пса решает, что вы используете слишком много памяти, и завершает процесс. Задания Map Reduce (встроенные или те, которые выполняются, в частности, с большими наборами данных), как правило, быстро увеличивают использование ОЗУ.
SIGKILL - это не то, что вы получили бы, если бы это ядро решило, что вам не хватило памяти и вызвало убийцу OOM (это выглядит как тихий сбой и регистрируется в dmesg). Следовательно, это заставило бы меня поверить, что есть что-то еще, что убивает, чтобы предотвратить использование памяти сверх определенного порога.
Если вы хотите проверить, запустите db.collection.find().explain() на большом наборе данных и посмотрите, вызывает ли это также SIGKILL. Если да, то я не думаю, что этот тип ВМ подходит для работы с базой данных с отображением памяти.