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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, что уменьшило некоторые проблемы. Нам пришлось переместить всех пользователей на другой сервер терминалов и перезапустить, чтобы увидеть все преимущества.

Несмотря на множество ответов здесь, лучшее, что вы можете сделать как администратор, - это изучить все в отчетах oom killer и четко понять, почему это срабатывает. Тогда это должно дать вам представление о следующих шагах. Это может быть связано с конфигурацией ОС или проблемой с определенным программным обеспечением.

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

Однако в то время я не мог перезагрузить свой компьютер, поэтому какой-то уродливый обходной путь состоял в том, чтобы войти в систему как 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 не перегружается, если у вашего приложения больше памяти, чем у вас, возможно, ваш код содержит ошибки