Избегайте разрыва приложений linux-out-of-memory

Я обнаружил, что иногда в моем Linux-устройстве не хватает памяти, и он начинает срывать случайные процессы, чтобы справиться с этим.

Мне интересно, что администраторы делают, чтобы избежать этого? Является ли единственное реальное решение для увеличения объема памяти (поможет ли только подкачка?), Или есть более эффективные способы установки программного обеспечения, чтобы избежать этого? (т.е. квоты или что-то такое?).

По умолчанию в Linux реализована концепция управления памятью, которая несколько повреждена мозгом: она позволяет вам выделять больше памяти, чем у вашей системы, а затем случайным образом снимать процесс с головы при возникновении проблем. (Фактическая семантика того, что убивают, более сложна, чем Google - Linux OOM Killer для Linux, где много деталей и аргументов о том, хорошо это или плохо).

Чтобы восстановить некое подобие здравомыслия в управлении вашей памятью:

1. Отключите OOM Killer (поместите vm.oom-kill = 0в /etc/sysctl.conf)
2. Отключить переполнение памяти (укажите vm.overcommit_memory = 2в /etc/sysctl.conf).
   Обратите внимание, что это триное значение: 0 = "оцените, если у нас достаточно ОЗУ", 1 = "всегда говорите", 2 = "говорите" нет ", если мы этого не сделаем иметь память ")

Эти настройки приведут к тому, что Linux будет вести себя традиционным образом (если процесс запрашивает больше памяти, чем доступно, malloc () завершится с ошибкой, и ожидается, что процесс, запрашивающий память, справится с этой ошибкой).

Перезагрузите компьютер, чтобы перезагрузить его /etc/sysctl.conf, или procсразу включите файловую систему без перезагрузки:

echo 2 > /proc/sys/vm/overcommit_memory 

Вы можете отключить overcommit, см. Http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514.

Краткий ответ для сервера - купить и установить больше оперативной памяти.

Сервер, который обычно испытывает ошибки OOM (Out-Of-Memory), а затем, помимо опции sysctl менеджера VM (виртуальной памяти) в ядрах Linux, это не очень хорошая вещь.

Увеличение объема подкачки (виртуальной памяти, которая была выгружена на диск диспетчером памяти ядра) поможет, если текущие значения будут низкими, и использование включает в себя множество задач, каждый из которых имеет такой большой объем памяти, а не одну или несколько обрабатывает каждый запрос огромного объема доступной виртуальной памяти (RAM + swap).

Для многих приложений, выделяющих более двух раз (в 2 раза) объем оперативной памяти в качестве подкачки, снижается отдача от улучшений. В некоторых больших вычислительных симуляциях это может быть приемлемо, если замедление скорости терпимо.

С оперативной памятью (ECC или нет), которая должна быть достаточно доступной для скромных объемов, например, 4-16 ГБ, я должен признать, что я не испытывал этой проблемы сам в течение длительного времени

Основы рассмотрения потребления памяти, включая использование freeи top, отсортированные по использованию памяти, как две наиболее распространенные быстрые оценки моделей использования памяти. Поэтому убедитесь, что вы понимаете значение каждого поля в выводе этих команд как минимум.

Без специфики приложений (например, базы данных, сервера сетевых услуг, обработки видео в реальном времени) и использования сервера (мало опытных пользователей, 100–1000 соединений пользователя / клиента), я не могу придумать какие-либо общие рекомендации в отношении работы с проблема ООМ.

Увеличение объема физической памяти не может быть эффективным ответом при любых обстоятельствах.

Один из способов проверить это - команда «поверх». Особенно эти две строки.

Это наш сервер, когда он был здоров:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Когда он работал плохо (и до того, как мы настроили overcommit_memory с 50 на 90, мы увидели бы поведение с vmcom, работающим более 50G, процессы взрыва oom-killer каждые несколько секунд, и нагрузка продолжала радикально подпрыгивать из-за взрыва дочерних процессов NFSd и воссоздан на постоянной основе.

Недавно мы дублировали случаи, когда многопользовательские терминальные серверы Linux чрезмерно перерасходовали выделение виртуальной памяти, но на самом деле очень мало запрашиваемых страниц используется.

Хотя не рекомендуется следовать этому точному маршруту, мы изменили overcommit-memory со значения по умолчанию от 50 до 90, что уменьшило некоторые проблемы. Нам пришлось переместить всех пользователей на другой сервер терминалов и перезапустить, чтобы увидеть все преимущества.

Вы можете использовать ulimit, чтобы уменьшить объем памяти, на который процесс может претендовать до того, как его уничтожат. Это очень полезно, если ваша проблема - один или несколько запущенных процессов, которые приводят к сбою вашего сервера.

Если ваша проблема в том, что вам просто не хватает памяти для запуска необходимых вам сервисов, есть только три решения:

1. Уменьшите объем памяти, используемой вашими службами, ограничив кэширование и тому подобное

2. Создайте большую область обмена. Это будет стоить вам производительности, но может выиграть время.

3. Купить больше памяти

У меня была похожая проблема, связанная с этой ошибкой, и я решил использовать старое / более новое (исправленное) ядро.

Однако в то время я не мог перезагрузить свой компьютер, поэтому какой-то уродливый обходной путь состоял в том, чтобы войти в систему как root и очистить системные кэши с помощью этой команды:

echo 3 > /proc/sys/vm/drop_caches

@ voretaq7 linux не имеет поврежденной концепции управления памятью, по умолчанию vm.overcommit_ratio равно 0,

0       -   Heuristic overcommit handling. Obvious overcommits of
            address space are refused. Used for a typical system. It
            ensures a seriously wild allocation fails while allowing
            overcommit to reduce swap usage.  root is allowed to
            allocate slightly more memory in this mode. This is the
            default.

Таким образом, если у вас есть 4 ГБ оперативной памяти, и вы пытаетесь выделить 4,2 ГБ с помощью malloc виртуальной памяти, ваше распределение завершится неудачно.

С vm.overcommit_ratio = 1

            1    -   Always overcommit. Appropriate for some scientific
            applications. Classic example is code using sparse arrays
            and just relying on the virtual memory consisting almost
            entirely of zero pages.

С vm.overcommit_ratio = 2

           2    -   Don't overcommit. The total address space commit
            for the system is not permitted to exceed swap + a
            configurable percentage (default is 50) of physical RAM.
            Depending on the percentage you use, in most situations
            this means a process will not be killed while accessing
            pages but will receive errors on memory allocation as
            appropriate.

            Useful for applications that want to guarantee their
            memory allocations will be available in the future
            without having to initialize every page.

Таким образом, по умолчанию Linux не перегружается, если у вашего приложения больше памяти, чем у вас, возможно, ваш код содержит ошибки