Linux oom что такое

Earlyoom — предотвращаем ситуацию OOM в Linux быстро и просто

Если вы работаете с «тяжелыми» приложениями в условиях нехватки оперативной памяти, вам знакома такая ситуация, как OOM — Out Of Memory, это когда запущенным программам нужно больше оперативной памяти, чем имеется в системе. В такой ситуации система обычно начинает свапиться на диск и при этом тормозить, что неприятно для пользователя. У меня в блоге уже был материал про Nohang, так вот Earlyoom делает всё то же самое, ну кроме отображения уведомлений, но в то же время менее требовательна к конфигурации компьютера.

Earlyoom автоматически завершает программу, если она приводит к исчерпыванию всей свободной ОЗУ в системе, предотвращая ситуацию нехватки оперативной памяти — OOM. Условия срабатывания такие:

Установка, включение автозапуска и запуск Earlyoom в различных дистрибутивах Linux

Earlyoom имеется в репозиториях всех популярных дистрибутивов Linux.

Arch Linux, Manjaro Linux

Debian GNU/Linux, Ubuntu, Linux Mint

Проверка работы

Узнать статус процесса Earlyoom можно с помощью следующей команды:

Если в статусе указано «Active: active (running)» — всё в порядке, Earlyoom запущен и правильно работает. Теперь можно устроить в системе катастрофическую нехватку оперативной памяти для проверки работы Earlyoom. Для этого прежде всего отключим swap на диске, если таковой имеется, чтобы не ждать пока он заполнится.

Ну а теперь забиваем всю доступную в системе оперативную память нулями:

Далее должно произойте следующее: процесс tail должен занять всю доступную ОЗУ в системе, после чего его должен прибить Earlyoom, тем самым освободив оперативную память. Если у вас произошло именно так — поздравляю, всё работает как и должно! Успехов!

Источник

Русские Блоги

Подробный анализ механизма OOM ядра Linux

В ядре Linux есть механизм, называемый OOM killer (Out-Of-Memory killer). Этот механизм отслеживает те процессы, которые занимают слишком много памяти, особенно те процессы, которые быстро потребляют много памяти. Чтобы предотвратить исчерпание памяти , ядро ​​убьет процесс. Типичная ситуация: однажды машина не может удаленно войти в систему через SSH, но ее можно проверить, что указывает на то, что это не сбой сети. Причина в том, что процесс sshd был прерван убийцей OOM (обнаружен такой приостановленный анимация много раз). После перезапуска компьютера проверьте системный журнал / var / log / messages, и вы найдете сообщение об ошибке, подобное «Недостаточно памяти: убить процесс 1865 (sshd)».

Предотвратить уничтожение механизма запуска важных системных процессов (OOM): вы можете установить параметр / proc / PID / oom_adj — -17, что может временно отключить механизм OOM ядра Linux. Ядро будет вычислять оценку для каждого процесса с помощью определенного алгоритма, чтобы определить, какой процесс нужно убить. Оценка oom каждого процесса может быть / proc / PID найдено в / oom_score. В процессе эксплуатации и обслуживания мы обычно защищаем sshd и некоторые агенты управления.

Чтобы защитить процесс от уничтожения ядром, вы можете сделать это:

Щелкните ( Здесь) свернуть или открыть

echo -17 > /proc/$PID/oom_adj

Как предотвратить убийство sshd, вы можете сделать так:

Щелкните ( Здесь) свернуть или открыть

pgrep -f «/usr/sbin/sshd» | while read PID;do echo -17 > /proc/$PID/oom_adj;done

Щелкните ( Здесь) свернуть или открыть

*/1**** root pgrep -f «/usr/sbin/sshd» | while read PID;do echo -17 > /proc/$PID/oom_adj;done

Щелкните ( Здесь) свернуть или открыть

echo -17 > /proc/$(pidof sshd)/oom_adj

Что касается того, почему используется -17 вместо других значений (значение по умолчанию — 0), это определяется ядром Linux. Проверьте исходный код ядра, чтобы узнать:
В качестве примера возьмем исходный код ядра версии linux-3.3.6, путь — linux-3.6.6 / include / linux / oom.h, чтение исходного кода ядра показывает, что регулируемое значение oom_adj составляет от 15 до -16 , из которых 15 — самое большое, а -16 — самое маленькое. -17 означает, что OOM запрещен. Oom_score вычисляется в n-й степени 2, где n — значение oom_adj процесса, поэтому чем выше оценка oom_score, тем больше ядро ​​убьет его первым.

Конечно, вы также можете отключить механизм OOM, изменив параметры ядра.

Щелкните ( Здесь) свернуть или открыть

# sysctl -w vm.panic_on_oom=1
vm.panic_on_oom = 1 // 1 означает выключено, по умолчанию 0 означает, что OOM включен

Во-первых, взгляните на текущий размер памяти моей системы. Да, он превышает 96 ГБ, что физически больше, чем просматриваемое значение.

Давайте посмотрим на самые большие процессы. Вид сверху, я запустил только два Java-процесса, каждый с 4.6G, затем процесс redis занял 21 миллион, сервис iscsi занимает 32 миллиона, gdm занимает 25 миллионов и другие. М.

Теперь я использую C для написания программы с именем bigmem, и я указываю, что программа выделяет 85 ГБ памяти.

Щелкните ( Здесь) свернуть или открыть

1. #include
2. #include
3. #include
4. #define PAGE_SZ (1 >20);
5. getchar();
6. return 0;
7. >

Продолжайте наблюдать, что, когда bigmem остается стабильным на 85G в течение некоторого времени, ядро ​​автоматически завершает свой процесс, и он не будет убит во время процесса роста. Если вы не хотите, чтобы вас убили, вы можете запустить его.

Щелкните ( Здесь) свернуть или открыть

pgrep -f «bigmem» | while read PID; do echo -17 > /proc/$PID/oom_adj;done

Очевидно, что до и после выполнения вышеуказанной команды эффект будет сравниваться, и вы сможете ощутить реальный эффект механизма OOM ядра.

Если вам сложно писать код на языке C, позвольте мне рассказать вам еще об одном простейшем способе тестирования и запуска OOM. Вы можете установить oom_adj процесса равным 15 (максимальное значение), что является наиболее простым для запуска. Затем выполните следующую команду:

Щелкните ( Здесь) свернуть или открыть

1. echo f > /proc/sysrq-trigger // ‘f’ — Will call oom_kill to kill a memory hog process.

Следует отметить, что этот тест только моделирует OOM и не убивает процесс.

Щелкните ( Здесь) свернуть или открыть

1. ps -ef | grep mysqld | grep -v grep

1. Алгоритм oomkiller в Kernel-2.6.26 недостаточно точен, RHEL 6.x версии 2.6.32 может решить эту проблему.

2. Дочерний процесс унаследует oom_adj родительского процесса.

3. OOM не подходит для решения проблемы утечки памяти.

4. Иногда памяти достаточно для свободного просмотра, но OOM все равно запускается, потому что процесс может занимать специальное адресное пространство памяти.

Источник

Настраиваем Out-Of-Memory Killer в Linux для PostgreSQL

Когда в Linux сервер базы данных непредвиденно завершает работу, нужно найти причину. Причин может быть несколько. Например, SIGSEGV — сбой из-за бага в бэкенд-сервере. Но это редкость. Чаще всего просто заканчивается пространство на диске или память. Если закончилось пространство на диске, выход один — освободить место и перезапустить базу данных.

Out-Of-Memory Killer

Когда у сервера или процесса заканчивается память, Linux предлагает 2 пути решения: обрушить всю систему или завершить процесс (приложение), который съедает память. Лучше, конечно, завершить процесс и спасти ОС от аварийного завершения. В двух словах, Out-Of-Memory Killer — это процесс, который завершает приложение, чтобы спасти ядро от сбоя. Он жертвует приложением, чтобы сохранить работу ОС. Давайте сначала обсудим, как работает OOM и как его контролировать, а потом посмотрим, как OOM Killer решает, какое приложение завершить.

Одна из главных задач Linux — выделять память процессам, когда они ее просят. Обычно процесс или приложение запрашивают у ОС память, а сами используют ее не полностью. Если ОС будет выдавать память всем, кто ее просит, но не планирует использовать, очень скоро память закончится, и система откажет. Чтобы этого избежать, ОС резервирует память за процессом, но фактически не выдает ее. Память выделяется, только когда процесс действительно собирается ее использовать. Случается, что у ОС нет свободной памяти, но она закрепляет память за процессом, и когда процессу она нужна, ОС выделяет ее, если может. Минус в том, что иногда ОС резервирует память, но в нужный момент свободной памяти нет, и происходит сбой системы. OOM играет важную роль в этом сценарии и завершает процессы, чтобы уберечь ядро от паники. Когда принудительно завершается процесс PostgreSQL, в логе появляется сообщение:

Если в системе мало памяти и освободить ее невозможно, вызывается функция out_of_memory . На этом этапе ей остается только одно — завершить один или несколько процессов. OOM-killer должен завершать процесс сразу или можно подождать? Очевидно, что, когда вызывается out_of_memory, это связано с ожиданием операции ввода-вывода или подкачкой страницы на диск. Поэтому OOM-killer должен сначала выполнить проверки и на их основе решить, что нужно завершить процесс. Если все приведенные ниже проверки дадут положительный результат, OOM завершит процесс.

Выбор процесса

Когда заканчивается память, вызывается функция out_of_memory() . В ней есть функция select_bad_process() , которая получает оценку от функции badness() . Под раздачу попадет самый «плохой» процесс. Функция badness() выбирает процесс по определенным правилам.

1. Ядру нужен какой-то минимум памяти для себя.
2. Нужно освободить много памяти.
3. Не нужно завершать процессы, которые используют мало памяти.
4. Нужно завершить минимум процессов.
5. Сложные алгоритмы, которые повышают шансы на завершение для тех процессов, которые пользователь сам хочет завершить.

Выполнив все эти проверки, OOM изучает оценку ( oom_score ). OOM назначает oom_score каждому процессу, а потом умножает это значение на объем памяти. У процессов с большими значениями больше шансов стать жертвами OOM Killer. Процессы, связанные с привилегированным пользователем, имеют более низкую оценку и меньше шансов на принудительное завершение.

Идентификатор процесса Postgres — 3813, поэтому в другой оболочке можно получить оценку, используя этот параметр ядра oom_score :

Если вы совсем не хотите, чтобы OOM-Killer завершил процесс, есть еще один параметр ядра: oom_score_adj . Добавьте большое отрицательное значение, чтобы снизить шансы на завершение дорогого вам процесса.

Чтобы задать значение oom_score_adj , установите OOMScoreAdjust в блоке сервиса:

Или используйте oomprotect в команде rcctl .

Принудительное завершение процесса

Когда один или несколько процессов уже выбраны, OOM-Killer вызывает функцию oom_kill_task() . Эта функция отправляет процессу сигнал завершения. В случае нехватки памяти oom_kill() вызывает эту функцию, чтобы отправить процессу сигнал SIGKILL. В лог ядра записывается сообщение.

Как контролировать OOM-Killer

В Linux можно включать и отключать OOM-Killer (хотя последнее не рекомендуется). Для включения и отключения используйте параметр vm.oom-kill . Чтобы включить OOM-Killer в среде выполнения, выполните команду sysctl .

Чтобы отключить OOM-Killer, укажите значение 0 в этой же команде:

Результат этой команды сохранится не навсегда, а только до первой перезагрузки. Если нужно больше постоянства, добавьте эту строку в файл /etc/sysctl.conf :

Еще один способ включения и отключения — написать переменную panic_on_oom . Значение всегда можно проверить в /proc .

Если установить значение 0, то когда закончится память, kernel panic не будет.

Если установить значение 1, то когда закончится память, случится kernel panic.

OOM-Killer можно не только включать и выключать. Мы уже говорили, что Linux может зарезервировать для процессов больше памяти, чем есть, но не выделять ее по факту, и этим поведением управляет параметр ядра Linux. За это отвечает переменная vm.overcommit_memory .

Для нее можно указывать следующие значения:

0: ядро само решает, стоит ли резервировать слишком много памяти. Это значение по умолчанию в большинстве версий Linux.
1: ядро всегда будет резервировать лишнюю память. Это рискованно, ведь память может закончиться, потому что, скорее всего, однажды процессы затребуют положенное.
2: ядро не будет резервировать больше памяти, чем указано в параметре overcommit_ratio .

В этом параметре вы указываете процент памяти, для которого допустимо избыточное резервирование. Если для него нет места, память не выделяется, в резервировании будет отказано. Это самый безопасный вариант, рекомендованный для PostgreSQL. На OOM-Killer влияет еще один элемент — возможность подкачки, которой управляет переменная cat /proc/sys/vm/swappiness . Эти значения указывают ядру, как обрабатывать подкачку страниц. Чем больше значение, тем меньше вероятности, что OOM завершит процесс, но из-за операций ввода-вывода это негативно сказывается на базе данных. И наоборот — чем меньше значение, тем выше вероятность вмешательства OOM-Killer, но и производительность базы данных тоже выше. Значение по умолчанию 60, но если вся база данных помещается в память, лучше установить значение 1.

Источник

Linux Out-Of-Memory Killer

May 26, 2020 · 6 min read

What is this ?

The “OOM Killer” or “Out of Memory Killer” is a process that the Linux kernel employs when the syste m is critically low on memory. This situation occurs because processes on the server are consuming a large amount of memory, and the system requires more memory for its own processes and to allocate to other processes. When a process starts it requests a block of memory from the kernel. This initial request is usually a large request that the process will not immediately or indeed ever use all of. The kernel, aware of this tendency for processes to request redundant memory, over allocates the system memory. This means that when the system has, for example, 8GB of RAM the kernel may allocate 8.5GB to processes. This maximises the use of system memory by ensuring that the memory that is allocated to processes is being actively used.

Normally, this situation does not cause a problem. However, if enough processes begin to use all of their requested memory blocks then there will not be enough physical memory to support them all. This means that the running processes require more memory than is physically available. This situation is critical and must be resolved immediately.

The solution that the Linux kernel employs is to invoke the OOM Killer to review all running processes and kill one or more of them in order to free up system memory and keep the system running.

Process Selection

Whenever out of memory failure occurs, the out_of_memory() function will be called. Within it the select_bad_process() function is used which gets a score from the badness() function. The most ‘bad’ process is the one that will be sacrificed. There are some rules badness() function follows for the selection of the process.

1. The kernel needs to obtain a minimum amount of memory for itself
2. Try to reclaim a large amount of memory
3. Don’t kill a process using a small amount of memory
4. Try to kill the minimum number of processes
5. Some meticulous algorithms that elevate the sacrifice priority on processes the user wants to kill

After all these checklists, the OOM killer checks the score (oom_score). OOM set the “oom_score” to each process and then multiplies that value with memory usage. The processes with bigger values will have a high probability of getting terminated by the OOM killer. The processes that are associated with the privileged user have a lower score value and have fewer chances to be killed by OOM.

postgres=# SELECT pg_backend_pid();
pg_backend_pid
— — — — — — — —
3813
(1 row)

The Postgres process id is 3813, therefore in another shell, you can get the score value by using this oom_score kernel parameter:

$ sudo cat /proc/3813/oom_score
2

If you really want your process not to be killed by OOM-Killer, then there is another kernel parameter oom_score_adj. You can add a big negative value to that to reduce the chance your process gets killed.
sudo echo -100 > /proc/3813/oom_score_adj

To set the value of oom_score_adj you can set that OOMScoreAdjust in the service unit

or rcctl command’s oomprotect can be used to set that.
rcctl set servicename oomprotect -1000

Killing a Process

When one or more processes are selected, then OOM-Killer calls the oom_kill_task() function. This function is responsible to send the terminate/kill signal to the process. In case of out of memory oom_kill() call this function so, it can send the SIGKILL signal to the process. A kernel log message is generated.

Out of Memory: Killed process [pid] [name].

How to control OOM-Killer

Linux provides a way to enable and disable the OOM-Killer, but it is not recommended to disable the OOM-killer. Kernel parameter vm.oom-kill is used to enable and disable the OOM-Killer. If you want to enable OOM-Killer runtime, then use sysctl command to enable that.

sudo -s sysctl -w vm.oom-kill = 1

To disable the OOM-killer use the same command with the value 0:
sudo -s sysctl -w vm.oom-kill = 0

This command does not set that permanently, and a machine reboot resets that. To set it permanently, add this line in /etc/sysctl.conf file:
echo vm.oom-kill = 1 >>/etc/sysctl.conf

The other way to enable or disable is to write the panic_on_oom variable, you can always check the value in /proc.

When you set the value to 0 that means the kernel will not panic when out of memory error occurred.

When you set that value 1 that means the kernel will panic on out of memory error.

There are some more settings for the OOM-Killer other than enabling and disabling. As we already mentioned that Linux can overcommit the memory to processes with allocating it, this behavior can be controlled by the Linux kernel setting. The vm.overcommit_memory is variably used to control this behavior.

The vm_overcommit_memory variable memory can be controlled with the following settings :

0: Setting the variable to 0, where the kernel will decide whether to overcommit or not. This is the default value for most versions of Linux.

1: Setting the variable to 1 means that kernel will always overcommit. This is a risky setting because the kernel will always overcommit the memory to processes. This can lead to kernel running out of memory because there is a good chance that processes can end up using the memory committed by the kernel.

2: Setting the variable to 2 means that kernel is not supposed to overcommit memory greater than the overcommit_ratio. This overcommit_ratio is another kernel setting where you specify the percentage of memory kernel can overcommit. If there is no space for overcommit, the memory allocation function fails and overcommit is denied. This is the safest option and recommended value for PostgreSQL.

The second thing that can affect the OOM-killer is the behavior of swappiness. This behavior can be controlled by variable cat /proc/sys/vm/swappiness. These values specify the kernel setting for handling the swappiness of pages. The bigger the value, the less of the chance OOM kills the process but it affects the database efficiency because of I/O. A smaller value for the variable controlling the swappiness means that there are higher chances for OOM-Killer kicking in, but it also improves the database performance. The default value is 60, but if you entire database fits in memory than it is recommended to set this value to 1.

So why is Apache / MySQL/Postgres always Killed?

The above listed criteria mean that when selecting a process to kill the OOM Killer will choose a process using lots of memory and has lots of child processes and which are not system processes. An application such as Apache, MySQL, Nginx, Clamd (ClamAV), or a mail server will make an good candidate. However, as this situation usually occurs on a busy web servers Apache or MySQL will be the largest in-memory, non-system processes and consequently gets killed.

It must be remembered that although the Web Server or DB Server are very important to you, when the kernel calls the OOM Killer the situation is critical. If memory is not freed by killing a process the server will crash very shortly afterwards. Continuing normal operations at this juncture is impossible.

One of the common causes of Apache / Nginx / MySQL being killed by the OOM Process Killer, is when the site is receiving a large amount of traffic, this could be genuine traffic from a New Promotion, Media Attention or similar, or it could be a Bot crawling the site, or in some cases it can be Botnets, trying to attack of brute force your site. Reviewing the Apache / Nginx logs, is a good place to start to see if this is the case.

Summary

You don’t need to be confused by the name Killer (OOM-Killer). The killer is not always harmful; it is a savior for your system. It kills the most culprit process and saves your system from crashing. To avoid having to use OOM-Killer to kill PostgreSQL, it is recommended to set the vm .overcommit_memory value to 2. It will not 100% avoid the OOM-Killer but will reduce the chance to kill the PostgreSQL process.

Hope you like the tutorial. Please let me know your feedback in the response section.

Источник