我有一个似乎每天大概崩溃一次的mongodb实例。 我在mongo日志文件中没有看到任何有用的信息。 一切都很好，然后这个过程只是坠毁，没有附加的信息logging。 我在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
Mongo ：2.4.1
还有什么我可以做进一步的疑难解答？
你正在运行一个Map Reduce工作，在那个时候遇害，情况总是如此？
我问，因为这听起来像一个看门狗types的进程决定你使用太多的内存并杀死进程时的行为。 Map Reduce作业（内联或特别是在大型数据集上运行的作业）往往会迅速提高RAM的使用率。
如果这是内核决定你是内存不足，并调用OOM杀手（看起来像一个沉默的崩溃，并在dmesglogin），SIGKILL是不是你会得到什么。 因此，这将使我相信还有其他的事情正在进行，以防止内存使用超过一定的阈值。
如果你想validation，在一个大的数据集上运行db.collection.find().explain() ，看看是否也触发了一个SIGKILL。 如果是这样，我不认为这种types的虚拟机适合运行内存映射数据库。