MongoDB убивает OOM

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

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

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

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

Источник

1 ответ

OOM killer - это не способ, которым кто-либо управляет памятью; это способ ядра Linux справиться с фатальным сбоем в последней надежде избежать блокировки системы!

Что вы должны сделать, это:

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

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

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

    echo "0"> / proc / sys / vm / overcommit_memory

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

    echo "2"> / proc / sys / vm / overcommit_memory; echo "80"> / proc / sys / vm / overcommit_ratio

    Посмотрите Отключение overcommit для получения дополнительной информации об этом.

    Это заставило бы ядро ​​быть более осторожным, когда предоставляло приложениям память, которой у него на самом деле нет (поразительное сходство с мировым экономическим кризисом в мире)

  • В крайнем случае, если все в вашей системе, кроме MangoDB, является расходным материалом (но, пожалуйста, исправьте два пункта выше первого!), вы можете снизить шансы на его уничтожение (или даже убедиться, что оно не будет убито, даже если альтернатива это зависшая машина, которая ничего не работает) настройкой /proc/$pid/oom_score_adj и / или / proc / $ pid / oom_score.

    echo "-1000"> / proc / `pidof mangod` / oom_score_adj

    Посмотрите Укрощение убийцы OOM для получения дополнительной информации на эту тему.

Источник
Другие вопросы по тегам