Обработка нехватки памяти в *BSD (vs Linux без оверкоммита)

https://www.freebsd.org/cgi/man.cgi?query=tuning&apropos=0&sektion=7&manpath=FreeBSD+12.1-RELEASE&arch=default&format=html

В FreeBSD оверкоммит настраивается. В целом похоже на Linux.

В NetBSD и OpenBSD раньше OMM killer был невменяемый. Не знаю, как сейчас.

не знаю, но в Debian при нехватке памяти в Firefox у меня Debian вешается намертво, а в OpenBSD - просто грохается Firefox

просто грохается Firefox

В линукс будет то же самое после отключения оверкоммита. Однако падать процессы будут не обязательно при исчерпании памяти - могут упасть и раньше, при полупустом свопе (это зависит от overcommit ratio). И не обязательно упадет самый жирный процесс. Пример: https://imgur.com/a/p9j67KA

В 2020 лучшей практикой считается разрешение оверкоммита в сочетании c включением обработчиков нехватки памяти, таких как nohang или oomd. - Они позволяют при желании почти полностью утилизировать память, не доводя систему до зависания, а также прерывать зависание при длительном интесивном своппинге (киллер активируется на основе метрик PSI).

у меня своп вообще не используется

Тогда вам достаточно простого earlyoom. (в репах дебиан 10 лежит устаревшая версия 1.2 с багом, используйте последнюю версию)

А в ядре что-то подобное имеется?

Подобное - это дефолтный OOM killer, и он может не работать: https://www.opennet.ru/opennews/art.shtml?num=51231 (именно поэтому и создан earlyoom и другие подобные демоны).

У самого уже около полугода стоит earlyoom, убивает иногда совсем непредсказуемые вещи, такие как setxkbmap. Думал может альтернативы какие-то завезли.

я месяц назад поставил earlyoom на федоре, через 10 минут система повисла. И это при отключенном свопе и 8 гигах памяти, из которых минимум половина была свободна. Без него федора у меня еще ни разу не падала с момента установки

зы в принципе поведение было как выше у Artamudo

Подобное - это дефолтный OOM killer, и он может не работать: https://www.opennet.ru/opennews/art.shtml?num=51231 (именно поэтому и создан earlyoom и другие подобные демоны).

Я вот думаю, может проще в ядре логику обработки нехватки памяти допилить раз и навсегда, чем плодить 3 юзерспейсных обработчика (или сколько их теперь уже)?

Это какой-то косяк, когда ядерный OOM-killer не срабатывает вовремя, и система виснет. Это надо чинить надёжно на уровне ядра, а не подпирать костылями.

я месяц назад поставил earlyoom на федоре, через 10 минут система повисла.

Надо ж было еще запустить, а не просто установить.

через 10 минут система повисла.

Это могло быть не связано с нехваткой памяти, например. earlyoom действует, когда доступной памяти меньше 10%.

так я его конечно запустил. Федора видимо и сдохла от удивления

Я вот думаю, может проще в ядре логику обработки нехватки памяти допилить раз и навсегда

Раз не допилили, значит не легче. Ребята очень стараются, но изменений почему-то так и нет. Вот как трудно ядро исправлять!

плодить 3 юзерспейсных обработчика

Штук 10, если считать все. Как мимиум еще: earlyoom, nohang, oomd (от Фейсбука), low-memory-monitor, peacemaker, lmkd (в Андроиде) и еще множество васянских скриптов.

Ах да, Леннарт собирается еще сделать systemd-oomd. И это не шутка.

сейчас наткнулся на статью где говорится что федора его уже имеет

https://www.reddit.com/r/openSUSE/comments/elbqge/fedora_proposes_including_earlyoom_by_default_to/

Может система поэтому и висла, что на федоре уже он есть. Беру свои слова обратно

Раз не допилили, значит не легче. Ребята очень стараются, но изменений почему-то так и нет. Вот как трудно ядро исправлять!

Кстати еще на смежную тему. Нужна универсальная логика в ядре, которая бы не позволяла завесить в свопе важные сервисы, такие как sshd или bash от рута.

Я как-то уже создавал обсуждение на ЛОРе, и на локалхосте делал прототип патча для ядра, но у меня знаний по устройству ядра не хватает для правильной реализации с учётом всех особенностей. К сожалению, сейчас времени нет, чтобы вернуться к этому вопросу.

earlyoom как раз будет включен в Fedora 32 Workstation по умолчанию: https://fedoraproject.org/wiki/Changes/EnableEarlyoom

Но без логов по единичному случаю трудно сделать выводы. earlyoom широко используется, и готов принимать багрепорты. Присылайте логи, если что-то идет не так. А пока жалоб нет, юзеры довольны, многим помогает. Ну и вот пример работы nohang - https://youtu.be/PLVWgNrVNlc - никаких проблем нет.

Нужна универсальная логика в ядре, которая бы не позволяла завесить в свопе важные сервисы, такие как sshd или bash от рута.

MemorySwapMax=0 в системд юнитах или memory.swap.max=0 в cgroup2.

# systemctl status earlyoom

Ждем репортов с логами. Он включен недавно в F32, если я все правильно понимаю, и начинается широкое тестирование на ничего не подозревающих юзерах.

MemorySwapMax=0 в системд юнитах или memory.swap.max в cgroup2.

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

Так же как ядерный OOM-killer по умолчанию имеет неплохие эвристики: не убивает процессы рута и не убивает процессы с малым потреблением памяти.

Я делал прототип, не требующий настройки юзерспейса, в котором разожравшийся firefox зависал в свопе, при этом можно было нажать Ctrl+Alt+F1 и залогиниться в консоль, или войти удаленно без тормозов. (Да даже графический сеанс можно было не покидать, он подтормаживал, но работал.)

То есть решалась как раз ситуация, описанная по ссылке на опеннет, когда система становится неотзывчивой из-за кривого OOM-killer или слишком загруженного свопа.

Леннарт собирается еще сделать systemd-oomd.

Было бы прекрасно.

OOM-killer по умолчанию имеет неплохие эвристики: не убивает процессы рута

Он прекрасно убивает процессы рута, рутовость не сильно влияет на oom_score. Например:

$ oom-sort -l0
oom_score oom_score_adj  UID   PID Name            VmRSS   VmSwap
--------- ------------- ---- ----- --------------- ------- --------
      246             0 1000  2851 firefox-esr      2407 M      0 M 
       71             0 1000  7220 Web Content       694 M      0 M 
       15             0    0  1037 Xorg              147 M      0 M 
        9             0 1000 10830 kate               95 M      0 M 
        6             0 1000  1832 caja               58 M      0 M 
        5             0 1000 10843 kate               52 M      0 M 
        4             0 1000  1842 mate-panel         47 M      0 M 
        4             0 1000  1857 mate-screensave    43 M      0 M 
        4             0 1000  2221 kactivitymanage    41 M      0 M 

• здесь рутовые Иксы имеют положительный скор. И бывали жалобы юзеров, что киллер убивает именно Иксы.

Ёпта, ну ты же знаешь, что процессы рута в эвристике получают сниженный oom_score, по сравнению с таким же процессом, если бы он был не рутовый.

Знаю, но на практике это не особо заметно. Я вижу, что рутовые могут также иметь высокий скор, если много кушают.

рутовые могут также иметь высокий скор, если много кушают.

Это вполне разумно для эвристики, которая ничего не знает о назначении каждого процесса, имхо.

$ oom-sort -l0
oom_score oom_score_adj  UID   PID Name            VmRSS   VmSwap
--------- ------------- ---- ----- --------------- ------- --------
      241             0 1000  2851 firefox-esr      2360 M      0 M 
      105             0 1000 18499 python3          1030 M      0 M 
      105             0    0 18508 python3          1030 M      0 M 
       70             0 1000  7220 Web Content       690 M      0 M 
       13             0    0  1037 Xorg              132 M      0 M 

Два процесса съели по гигабайту. Один рутовый, другой нет. Скор одинаков.

Нужна универсальная логика в ядре, которая бы не позволяла завесить в свопе важные сервисы, такие как sshd или bash от рута.

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

Один рутовый, другой нет. Скор одинаков.

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

Linux PC 5.4.0-trunk-amd64 #1 SMP Debian 5.4.2-1~exp1 (2019-12-05) x86_64 GNU/Linux. Поставьте аналогичные опыты, если не верите.

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

Я тебе говорю, что у меня был рабочий прототип, а ты говоришь про телепатию. %) Надо найти сорцы, где-то на другом компе лежали.

Эвристика конечно не покроет 100% случаев, но хорошая эвристика может покрыть 95% случаев для типичного десктопа и существенную часть случаев для сервера.

В моём случае я ориентировался на количество занятой процессом физической памяти, интенсивность страничных исключений и UID (рут vs не рут).

можно закопать или нельзя

Это не OOM-killer, он не закапывает. Просто не даёт жирным процессам много IO, когда более важные процессы ждут в страничных обработчиках готовности страницы.

Верю, почему не верить. Говорю же, мог неправильно запомнить, либо там алгоритм сменили. Почитаю, если время будет.

кроме того что он запущен ничего сказать не могу. Даже в journalctl никаких записей, но у меня почти всегда больше 2 гигов памяти свободно. Так что подождем

[jtad@localhost ~]$ systemctl status earlyoom.service
● earlyoom.service - Early OOM Daemon
   Loaded: loaded (/usr/lib/systemd/system/earlyoom.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-03-01 10:19:30 CET; 4h 5min ago
     Docs: man:earlyoom(1)
           https://github.com/rfjakob/earlyoom
 Main PID: 36787 (earlyoom)
    Tasks: 1 (limit: 8244)
   Memory: 808.0K
      CPU: 45ms
   CGroup: /system.slice/earlyoom.service
           └─36787 /usr/bin/earlyoom -r 60

https://pagure.io/fedora-workstation/issue/119 Здесь обсуждается включение этого демона. Будут проблемы - дайте знать. Несите журналы, если что.

Нашел: https://github.com/torvalds/linux/commit/a63d83f427fbce97a6cea0db2e64b0eb8435cd10

Оказывается, 10 лет назад убрали снижение oom_score для процессов рута, а я как-то пропустил это изменение.

Да, отличается.