☰

MongoDB убивает OOM

tag-icon • tag-icon mongodb oom-killer
MongoDB убивает OOM

мы запускаем набор реплик mongodb на трех машинах. Все три машины имеют около 16 ГБ, но только 255 МБ подкачки. Подкачка оставлена ​​на значении по умолчанию 60. Машины работают под управлением CentOS 6.4. Базы данных намного больше 16 ГБ, но это нормально для нас. Реально рабочий набор намного меньше.

Проблема, с которой мы сталкиваемся, заключается в том, что первичный потребляет всю доступную память, а затем получает OOM-Killed. Я знаю, что это способ, которым mongodb управляет памятью.

После того, как сервер будет убит из-за OOM, кто-то должен вручную перезапустить его.

Есть ли способ предотвратить mongodb от OOM kill? Отрегулировать swappiness? Увеличить пространство подкачки? Я думаю, что эти настройки только увеличат льготный период перед тем, как mongod kill.

решение1

Убийца ООМ — это не способлюбойуправляет памятью; это способ ядра Linux обрабатывать фатальные сбои в последней надежде избежать блокировки системы!

Что вам следует сделать:

  • убедитесь, что у вас достаточно swap. Если вы уверены, все равно добавьте еще.

  • Реализуйте ограничения ресурсов! ПО КРАЙНЕЙ МЕРЕ для приложений, которые, как вы ожидаете, будут использовать память (и тем более, если вы этого не ожидаете — такие приложения обычно оказываются проблемными). Посмотрите команды ulimit -v (или limit addressspace) в вашей оболочке и поместите их перед запуском приложения в его скрипте инициализации. Вам также следует ограничить другие вещи (например, количество процессов -u и т. д.)... Таким образом, приложение получит ошибку ENOMEM, когда памяти будет недостаточно, вместо того, чтобы ядро ​​выдало им несуществующую память и затем сошло с ума, убив все вокруг!

  • сказать ядру не перераспределять память. Вы можете сделать:

    эхо "0" > /proc/sys/vm/overcommit_memory

    или даже лучше (в зависимости от объема вашего пространства подкачки)

    echo "2" > /proc/sys/vm/overcommit_memory; echo "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для получения более подробной информации по этой теме.

Связанный контент