мы запускаем набор реплик mongodb на трех машинах. Все три машины имеют около 16 ГБ, но только 255 МБ подкачки. Для подкачки оставлено значение по умолчанию 60. На машинах работает CentOS 6.4. Базы данных намного больше, чем 16 ГБ, но для нас это нормально. Реально рабочий набор намного меньше.
Проблема, с которой мы сталкиваемся, заключается в том, что первичное потребление съедает всю доступную память, а затем убивает OOM. Я знаю, что именно так mongodb управляет памятью.
После того, как сервер убивает OOM, кто-то должен вручную перезапустить его.
Есть ли способ предотвратить убийство mongodb OOM? Отрегулировать подкачку? Увеличить пространство подкачки? Я думаю, что эти настройки только увеличат период отсрочки до того, как mongod будет убит.
Убийца OOM не выход кто угодно управляет памятью; это способ ядра Linux справиться с фатальным отказом в последней надежде избежать блокировки системы!
Что вам следует сделать:
убедитесь, что у вас достаточно свопа. Если уверены, все равно добавляйте еще.
реализовать ограничения ресурсов! По крайней мере, для приложений вы ожидаете, что они будут использовать память (и тем более, если вы этого не ожидаете - они обычно становятся проблематичными). См. Команды ulimit -v (или ограничение адресного пространства) в вашей оболочке и поместите их перед запуском приложения в его сценарий инициализации. Вы также должны ограничить другие вещи (например, количество процессов -u и т. Д.). Таким образом, приложение будет получать ошибку ENOMEM, когда недостаточно памяти, вместо того, чтобы ядро предоставляло им несуществующую память, а затем сходит с ума, убивая все вокруг !
скажите ядру, чтобы оно не перегружало память. Вы могли сделать:
эхо "0"> / proc / sys / vm / overcommit_memory
или даже лучше (в зависимости от вашего пространства подкачки)
эхо "2"> / proc / sys / vm / overcommit_memory; эхо "80"> / proc / sys / vm / overcommit_ratio
Видеть Отключение чрезмерной фиксации для получения дополнительной информации об этом.
Это заставит ядро быть более осторожным, предоставляя приложениям память, которой у него на самом деле нет (сходство с мировым глобальным экономическим кризисом поразительно)
в крайнем случае, если все в вашей системе, кроме MangoDB, является расходным материалом (но сначала исправьте два пункта выше!), вы можете уменьшить шансы, что его убьют (или даже убедиться, что он не будет убит - даже если альтернативой является зависшая машина, когда ничего не работает), настроив / proc / $ pid / oom_score_adj и / или / proc / $ pid / oom_score.
echo "-1000"> / proc / `pidof mangod` / oom_score_adj
Видеть Укрощение убийцы OOM для получения дополнительной информации по этому вопросу.