Ядро Linux не может мягко обрабатывать ситуации с нехваткой памяти. Как побороть?

vs220	# 1 год, 10 месяцев назад
Темы: 22 Сообщения: 8070 Участник с: 16 августа 2009	vall в чём преимущество его инструментов? Ну - он работает , а срабатывания ядерного у меня не хватало терпения дождаться :)

indeviral	# 1 год, 10 месяцев назад
Темы: 38 Сообщения: 3165 Участник с: 10 августа 2013	а я опасаюсь всех этих автокиллеров, ну их( запись в свап аварийная ситуация, до неё лучше не доводить. vall vm.swappiness до 200 это из разряда, озу рудимент, всем по мега-скоростному ssd)) Ошибки в тексте-неповторимый стиль автора©

indeviral

# 1 год, 10 месяцев назад

Темы: 38

Сообщения: 3165

Участник с: 10 августа 2013

а я опасаюсь всех этих автокиллеров, ну их(
запись в свап аварийная ситуация, до неё лучше не доводить.

vall
vm.swappiness до 200

это из разряда, озу рудимент, всем по мега-скоростному ssd))

Ошибки в тексте-неповторимый стиль автора©

vall	# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	indeviral опасаюсь всех этих автокиллеров, ну их( hakavlad очень интересные видосы выкладывал (по ссылкам в шапке темы). Очень гладко и безопасно (на первый взгляд). Система не убивается под неслабой загрузкой. Да ещё продублированной. `tail /dev/zero`

vall

# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)

Темы: 45

Сообщения: 1786

Участник с: 28 марта 2017

indeviral
опасаюсь всех этих автокиллеров, ну их(

hakavlad очень интересные видосы выкладывал (по ссылкам в шапке темы). Очень гладко и безопасно (на первый взгляд). Система не убивается под неслабой загрузкой. Да ещё продублированной.

tail /dev/zero

vasek	# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	vall, попробуй отключи swap, почувствуешь разницу в отзывчивости ... если swap имеется, то тормоза будут всеравно. У меня дефолтный конфиг earlyoom и vm.swappiness PS - ... vall EARLYOOM_ARGS="-m 15 -s 85 -r 60 -n –avoid '(^\|/)(init\|systemd\|Xorg\|sshd)$' –prefer '(^\|/)(telegram-desktop)$'" у меня `EARLYOOM_ARGS="-r 3600 -n --avoid '(^\|/)(init\|systemd\|Xorg\|sshd)$'"` Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

vall, попробуй отключи swap, почувствуешь разницу в отзывчивости ... если swap имеется, то тормоза будут всеравно.
У меня дефолтный конфиг earlyoom и vm.swappiness

PS - ...

vall
EARLYOOM_ARGS="-m 15 -s 85 -r 60 -n –avoid '(^|/)(init|systemd|Xorg|sshd)$' –prefer '(^|/)(telegram-desktop)$'"

у меня

EARLYOOM_ARGS="-r 3600 -n --avoid '(^|/)(init|systemd|Xorg|sshd)$'"

Ошибки не исчезают с опытом - они просто умнеют

vall	# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	vasek если swap имеется, то тормоза будут всеравно Более того, на практике выходит, что своп ещё более ухудшает ситуацию с нехваткой памяти и применением того же earlyoom. Поскольку при заполнении ОЗУ скажем на 97% oom killer не срабытывает, ожидая заполнения ещё и свопа. Но система подвисает гораздо раньше. И выходит, что толку от свопа -- ноль. Поэтому в конфиге установил, чтобы демон срабатывал при 15% заполнения свопа. А оставил своп (если очень кратко), поскольку многие всё же рекомендуют чтобы был; разными аргументами. И в настройках earlyoom нашёл для себя некий временный компромисс.

vall

# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)

Темы: 45

Сообщения: 1786

Участник с: 28 марта 2017

vasek
если swap имеется, то тормоза будут всеравно

Более того, на практике выходит, что своп ещё более ухудшает ситуацию с нехваткой памяти и применением того же earlyoom. Поскольку при заполнении ОЗУ скажем на 97% oom killer не срабытывает, ожидая заполнения ещё и свопа. Но система подвисает гораздо раньше. И выходит, что толку от свопа -- ноль. Поэтому в конфиге установил, чтобы демон срабатывал при 15% заполнения свопа.

А оставил своп (если очень кратко), поскольку многие всё же рекомендуют чтобы был; разными аргументами. И в настройках earlyoom нашёл для себя некий временный компромисс.

Aivar	# 1 год, 10 месяцев назад
Темы: 4 Сообщения: 6897 Участник с: 17 февраля 2011	vasek попробуй отключи swap, почувствуешь разницу в отзывчивости … если swap имеется, то тормоза будут всеравно. Буквально вчера читал статью, в которой утверждается обратное.

vall	# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	Aivar Буквально вчера читал статью, в которой утверждается обратное. Аналогично) И тоже вчера. Вот этот материал ещё на хабре самый свежий по теме топика, а уже три года пролетело.

vasek	# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Aivar Буквально вчера читал статью, в которой утверждается обратное. все зависит от использования/не использования earlyoom Если earlyoom не используется, то да, swap обязателен. Если используется earlyoom и не хочешь вообще иметь тормозов (даже не больших), то swap лучше отключить вообще. Если посмотреть логи journal, то там будет видно (это сообщает earlyoom) - какой объем памяти имеется `mem avail: 554 of 5875 MiB ( 9.43%), swap free: 0 of 0 MiB ..... и так далее` и далее показано завершение жрущего процесса `sending SIGTERM to process 65879 uid 1000 "mirage" ....` PS - какой смысл в swap, если система держит определенный процент свободного ОЗУ - все что ~~больше~~ меньше мочится ... Если оставите swap, то он будет заполнятся медленно и ... наступят тормоза EDIT 1 - а вообще - каждый решает сам, но прежде чем что то решить, рекомендую проверить (поэкспериментировать), учитывая, что хотите иметь на выходе EDIT 2 - забыл уточнить, что при отсутствии earlyoom и наличии swap - чем больше заполняется swap, тем больше подвисает система ... и в конце все равно все становится колом. Конечно, до такой ситуации в действительности это не доходит, но частичное заполнение swap у меня при определенных видах работ с моими 6G ОЗУ происходит частенько, а тормоза мне не нужны. Так что все это очень индивидуально и каждый должен подбирать режим сам, в зависимости от своих возможностей и запросов. И перепробовав разные способы, типа ulimit, cgroups, nohang, zram, zswap и др., решил, что лично для меня ... моего железа, моих работ ... самое простое это использование earlyoom с отключенным swap .... не спорю, кому то это и не подойдет. PSS - для экспериментов использовал тяжелые карты местности ..... даже nafanja как то дал ссылку на несколько карт Крыма ... Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Aivar
Буквально вчера читал статью, в которой утверждается обратное.

все зависит от использования/не использования earlyoom
Если earlyoom не используется, то да, swap обязателен.
Если используется earlyoom и не хочешь вообще иметь тормозов (даже не больших), то swap лучше отключить вообще.
Если посмотреть логи journal, то там будет видно (это сообщает earlyoom) - какой объем памяти имеется

mem avail:   554 of  5875 MiB ( 9.43%), swap free:    0 of    0 MiB ..... и так далее

и далее показано завершение жрущего процесса

sending SIGTERM to process 65879 uid 1000 "mirage" ....

PS - какой смысл в swap, если система держит определенный процент свободного ОЗУ - все что ~~больше~~ меньше мочится ...
Если оставите swap, то он будет заполнятся медленно и ... наступят тормоза

EDIT 1 - а вообще - каждый решает сам, но прежде чем что то решить, рекомендую проверить (поэкспериментировать), учитывая, что хотите иметь на выходе

EDIT 2 - забыл уточнить, что при отсутствии earlyoom и наличии swap - чем больше заполняется swap, тем больше подвисает система ... и в конце все равно все становится колом. Конечно, до такой ситуации в действительности это не доходит, но частичное заполнение swap у меня при определенных видах работ с моими 6G ОЗУ происходит частенько, а тормоза мне не нужны. Так что все это очень индивидуально и каждый должен подбирать режим сам, в зависимости от своих возможностей и запросов.
И перепробовав разные способы, типа ulimit, cgroups, nohang, zram, zswap и др., решил, что лично для меня ... моего железа, моих работ ... самое простое это использование earlyoom с отключенным swap .... не спорю, кому то это и не подойдет.

PSS - для экспериментов использовал тяжелые карты местности ..... даже nafanja как то дал ссылку на несколько карт Крыма ...

Ошибки не исчезают с опытом - они просто умнеют

vasek	# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)
Темы: 48 Сообщения: 11320 Участник с: 17 февраля 2013	Раз уж тема об обработке ситуации с нехватко памяти, то опишу немного подробнее про OOM Killer (Out Of Memory Killer) и некоторые параметры. OOM Killer - это компонент ядра Linux, призванный решать проблему недостатка памяти (виртуальной памяти всегда может быть очень много, а вот физической - ограниченное количество). Ядро выделяет память процессам "с запасом" в сумме превышающую физическую память системы. В основном, всё разруливается нормально (вся выделенная память одновременно редко требуется), но бывает ситуация когда становится нужно памяти больше, чем ее физически есть. И системе тогда нужно завершить какой-то процесс, чтобы продолжить работу. Вот этим и занимается OOM Killer. Есть разница, как это делается в windows и в linux - windows - действует разумно и не старается доводить систему до зависания - начинает освобождать паямять заранее, начиная со старых запущенных процессов, малопотребляющих памяти. - linux - не спешит освобождать память, но когда приступает к этому, то действует по сложному алгоритму - проводит подсчет балов всех запущенных процессов и процесс набравший более всего балов убивается. Но юзер может влиять на этот алгоритм … и можно будет убить или старые процессы или последний самый жрущий … а определенный процесс можно вообще запретить убивать. Например, имеется параметр vm.oom_kill_allocating_task, по дефолту равен 0 - vm.oom_kill_allocating_task=0 - освобождается память от уже работающих процессов в угоду только что запущенных - vm.oom_kill_allocating_task=1 - тупо мочит любые процессы, которые стали причиной нехватки памяти Кроме того у каждого процесса имеется файл oom_adj, который создается вместе с запуском процесса и вместо с ним и удаляется. Значение этого файла по дефолту равно 0 cat /proc/`pidof palemoon`/oom_adj 0 Это значение участвует в сложном подсчете балов … и если записать в этот файл значение равное -17, то этот процесс не будет убит вообще. Чем меньше это число, тем меньше вероятность того, что процесс будет уничтожен. Диапазон значений от -17 до 15. Плюс к этому, в ядре есть еще два параметра, отвечающих за overcommit памяти: vm.overcommit_memory - отвечает за стратегию overcommit .... по дефолту vm.overcommit_memory=0, vm.overcommit_ratio - отвечает за уровень (в процентах) overcommit .... по дефолту vm.overcommit_ratio=50 vm.overcommit_memory=0 - процессу выделяется столько памяти, сколько он хочет, что, как считают некоторые, не есть хорошо и рекомендуют =2 PS - уточнение в части значени 2 - в этом случае допустимый объем пространства памяти будет total_swap + alowed, где alowed = total_ram * overcommit_ratio / 100). А вот vm.overcommit_ratio в этом случае рекомндуют =300 …. и объясняют это тем, что относительно "вменяемые" приложения при запуске запрашивают не более чем в 3 раза больше памяти, чем им реально требуется, а значит vm.overcommit_ratio=300 должно быть вполне достаточно в большинстве случаев. И последнее уточнение - система всегда резервирует ~3% памяти для процессов пользователя root. Что лучше? - или приложение типа earlyoom или ручное управление - решает каждый сам. Ошибки не исчезают с опытом - они просто умнеют

vasek

# 1 год, 10 месяцев назад (отредактировано 1 год, 10 месяцев назад)

Темы: 48

Сообщения: 11320

Участник с: 17 февраля 2013

Раз уж тема об обработке ситуации с нехватко памяти, то опишу немного подробнее про OOM Killer (Out Of Memory Killer) и некоторые параметры.
OOM Killer - это компонент ядра Linux, призванный решать проблему недостатка памяти (виртуальной памяти всегда может быть очень много, а вот физической - ограниченное количество). Ядро выделяет память процессам "с запасом" в сумме превышающую физическую память системы. В основном, всё разруливается нормально (вся выделенная память одновременно редко требуется), но бывает ситуация когда становится нужно памяти больше, чем ее физически есть. И системе тогда нужно завершить какой-то процесс, чтобы продолжить работу. Вот этим и занимается OOM Killer.
Есть разница, как это делается в windows и в linux
- windows - действует разумно и не старается доводить систему до зависания - начинает освобождать паямять заранее, начиная со старых запущенных процессов, малопотребляющих памяти.
- linux - не спешит освобождать память, но когда приступает к этому, то действует по сложному алгоритму - проводит подсчет балов всех запущенных процессов и процесс набравший более всего балов убивается. Но юзер может влиять на этот алгоритм … и можно будет убить или старые процессы или последний самый жрущий … а определенный процесс можно вообще запретить убивать.
Например, имеется параметр vm.oom_kill_allocating_task, по дефолту равен 0
- vm.oom_kill_allocating_task=0 - освобождается память от уже работающих процессов в угоду только что запущенных
- vm.oom_kill_allocating_task=1 - тупо мочит любые процессы, которые стали причиной нехватки памяти
Кроме того у каждого процесса имеется файл oom_adj, который создается вместе с запуском процесса и вместо с ним и удаляется. Значение этого файла по дефолту равно 0
cat /proc/`pidof palemoon`/oom_adj
0
Это значение участвует в сложном подсчете балов … и если записать в этот файл значение равное -17, то этот процесс не будет убит вообще. Чем меньше это число, тем меньше вероятность того, что процесс будет уничтожен. Диапазон значений от -17 до 15.
Плюс к этому, в ядре есть еще два параметра, отвечающих за overcommit памяти:
vm.overcommit_memory - отвечает за стратегию overcommit .... по дефолту vm.overcommit_memory=0,
vm.overcommit_ratio - отвечает за уровень (в процентах) overcommit .... по дефолту vm.overcommit_ratio=50
vm.overcommit_memory=0 - процессу выделяется столько памяти, сколько он хочет, что, как считают некоторые, не есть хорошо и рекомендуют =2

PS - уточнение в части значени 2 - в этом случае допустимый объем пространства памяти будет total_swap + alowed, где alowed = total_ram * overcommit_ratio / 100). А вот vm.overcommit_ratio в этом случае рекомндуют =300 …. и объясняют это тем, что относительно "вменяемые" приложения при запуске запрашивают не более чем в 3 раза больше памяти, чем им реально требуется, а значит vm.overcommit_ratio=300 должно быть вполне достаточно в большинстве случаев.

И последнее уточнение - система всегда резервирует ~3% памяти для процессов пользователя root.

Что лучше? - или приложение типа earlyoom или ручное управление - решает каждый сам.

Ошибки не исчезают с опытом - они просто умнеют

vall	# 1 год, 9 месяцев назад (отредактировано 1 год, 9 месяцев назад)
Темы: 45 Сообщения: 1786 Участник с: 28 марта 2017	В результате экспериментов, прочтения советов vasek и всего вышеизложенного, на системе $ screenfetch -` .o+` `ooo/ OS: Arch Linux `+oooo: Kernel: x86_64 Linux 5.4.75-1-lts `+oooooo: Uptime: 2h 50m -+oooooo+: Packages: 1381 `/:-:++oooo+: Shell: bash `/++++/+++++++: Resolution: 2560x1440 `/++++++++++++++: DE: KDE 5.75.0 / Plasma 5.20.2 `/+++ooooooooooooo/` WM: KWin ./ooosssso++osssssso+` GTK Theme: Breeze [GTK2/3] .oossssso-````/ossssss+` Icon Theme: Suru++ -osssssso. :ssssssso. Disk: 637G / 2,0T (34%) :osssssss/ osssso+++. CPU: Intel Core i7 920 @ 8x 2.661GHz /ossssssss/ +ssssooo/- GPU: GeForce GTX 1050 Ti `/ossssso+/:- -:/+osssso+- RAM: 4321MiB / 5936MiB `+sso+:-` `.-/+oso: `++:. `-/+/ .` `/ оптимальным решением для десктопа стало: 1. Полное удаление своп-файла (был вместо своп-раздела). 2. Установка earlyoom - автоматически завершает программу, если она приводит к исчерпыванию всей свободной ОЗУ в системе, предотвращая ситуацию нехватки оперативной памяти (изменённая часть конфига приведена чуть ниже). 3. Установка prelockd - улучшает реакцию системы в условиях нехватки памяти. Делает закрытие "тяжёлых" программ практически бесшовным, совершенно незаметным (конфиг по умолчанию). `pikaur -S earlyoom prelockd-git` `sudo vim /etc/default/earlyoom -------------- # Options to pass to earlyoom EARLYOOM_ARGS="-m 10 -r 60 --avoid '(^\|/)(init\|systemd\|Xorg\|sshd\|kwin_x11\|plasmashell\|chromium\|firefox)$' --prefer '(^\|/)(telegram-desktop)$'"` Изменения внесены, поскольку изначально связка earlyoom&prelockd убивала рандомно всё что хотела (kwin_x11, к примеру). Хотя по идее должна была начинать с telegram-desktop. Какое-то время - дня три - система "притиралась". И стало почти хорошо. А когда недавно кеды полностью обновились, всё стало работать как часы. Отзывчивость и скорость работы системы прекрасны для данных условий. Подсказки, что надо застраховать от OOM Killer на других DE, можно посмотреть в файле конфига prelockd. Напомню, что автор демонов в качестве оптимального решения предлагает связку nohang, memavaild и prelockd. Но earlyoom более прост, чем nohang. А сервис memavaild требует свопа.

vall

# 1 год, 9 месяцев назад (отредактировано 1 год, 9 месяцев назад)

Темы: 45

Сообщения: 1786

Участник с: 28 марта 2017

В результате экспериментов, прочтения советов vasek и всего вышеизложенного, на системе

$ screenfetch
                   -`
                  .o+`
                 `ooo/                 OS: Arch Linux
                `+oooo:                Kernel: x86_64 Linux 5.4.75-1-lts
               `+oooooo:               Uptime: 2h 50m
               -+oooooo+:              Packages: 1381
             `/:-:++oooo+:             Shell: bash
            `/++++/+++++++:            Resolution: 2560x1440
           `/++++++++++++++:           DE: KDE 5.75.0 / Plasma 5.20.2
          `/+++ooooooooooooo/`         WM: KWin
         ./ooosssso++osssssso+`        GTK Theme: Breeze [GTK2/3]
        .oossssso-````/ossssss+`       Icon Theme: Suru++
       -osssssso.      :ssssssso.      Disk: 637G / 2,0T (34%)
      :osssssss/        osssso+++.     CPU: Intel Core i7 920 @ 8x 2.661GHz
     /ossssssss/        +ssssooo/-     GPU: GeForce GTX 1050 Ti
   `/ossssso+/:-        -:/+osssso+-   RAM: 4321MiB / 5936MiB
  `+sso+:-`                 `.-/+oso:
 `++:.                           `-/+/
 .`                                 `/

оптимальным решением для десктопа стало:
1. Полное удаление своп-файла (был вместо своп-раздела).
2. Установка earlyoom - автоматически завершает программу, если она приводит к исчерпыванию всей свободной ОЗУ в системе, предотвращая ситуацию нехватки оперативной памяти (изменённая часть конфига приведена чуть ниже).
3. Установка prelockd - улучшает реакцию системы в условиях нехватки памяти. Делает закрытие "тяжёлых" программ практически бесшовным, совершенно незаметным (конфиг по умолчанию).

pikaur -S earlyoom prelockd-git

sudo vim /etc/default/earlyoom
--------------
# Options to pass to earlyoom
EARLYOOM_ARGS="-m 10 -r 60 --avoid '(^|/)(init|systemd|Xorg|sshd|kwin_x11|plasmashell|chromium|firefox)$' --prefer '(^|/)(telegram-desktop)$'"

Изменения внесены, поскольку изначально связка earlyoom&prelockd убивала рандомно всё что хотела (kwin_x11, к примеру). Хотя по идее должна была начинать с telegram-desktop. Какое-то время - дня три - система "притиралась". И стало почти хорошо. А когда недавно кеды полностью обновились, всё стало работать как часы. Отзывчивость и скорость работы системы прекрасны для данных условий.
Подсказки, что надо застраховать от OOM Killer на других DE, можно посмотреть в файле конфига prelockd.

Напомню, что автор демонов в качестве оптимального решения предлагает связку nohang, memavaild и prelockd.
Но earlyoom более прост, чем nohang. А сервис memavaild требует свопа.