LINUX.ORG.RU

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

 , , ,


0

2

Расскажите, пожалуйста, отличается ли обработка нехватки памяти в *BSD от обработки нехватки памяти в Linux при отключении оверкоммита? Как именно *BSD обрабатывает нехватку памяти? Как Linux с отключенным оверкоммитом, или принципиально иначе?

Ответ на: комментарий от buratino

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

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

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

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от buratino

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

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 2)
Ответ на: комментарий от Artamudo

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

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от hakavlad

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

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

jtad ()
Последнее исправление: jtad (всего исправлений: 1)
Ответ на: комментарий от hakavlad

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

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

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)
Ответ на: комментарий от jtad

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

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

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

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

hakavlad ★★ ()
Ответ на: комментарий от Deleted

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

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

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

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

hakavlad ★★ ()
Ответ на: комментарий от hakavlad

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

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

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

jtad ()
Ответ на: комментарий от hakavlad

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

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

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

Deleted ()
Ответ на: комментарий от jtad

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

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

hakavlad ★★ ()
Ответ на: комментарий от Deleted

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

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

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от hakavlad

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

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

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

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

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

Deleted ()
Ответ на: комментарий от Deleted

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 
  • здесь рутовые Иксы имеют положительный скор. И бывали жалобы юзеров, что киллер убивает именно Иксы.
hakavlad ★★ ()
Ответ на: комментарий от hakavlad

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

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

Deleted ()
Ответ на: комментарий от Deleted
$ 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 

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

hakavlad ★★ ()
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от Deleted

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

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

olelookoe ()
Ответ на: комментарий от hakavlad

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

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

Deleted ()
Ответ на: комментарий от olelookoe

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

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

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

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

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

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

Deleted ()
Ответ на: комментарий от hakavlad

кроме того что он запущен ничего сказать не могу. Даже в 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
jtad ()