The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз обработчика нехватки памяти oomd 0.2.0

11.09.2019 21:45

Facebook опубликовал второй выпуск oomd, обработчика нехватки памяти в системе (OOM, Out Of Memory), работающего в пространстве пользователя. Приложение принудительно завершает работу процессов, потребляющих слишком много памяти, на стадии до срабатывания OOM-обработчика ядра Linux. Код oomd написан на языке C++ и поставляется под лицензией GPLv2. Готовые пакеты сформированы для Fedora Linux. С особенностями oomd можно познакомиться в тексте анонса первого выпуска.

Релиз 0.2.0 включает в себя множество обновлений и перестановок файлов, осуществлённых чтобы упростить формирование пакета oomd для дистрибутивов Linux. Добавлен новый флаг "--list-plugins" для вывода списка активных плагинов. Добавлен плагин для определения присутствия определённых cgroups в системе. Добавлен socket server для обработки запросов статистики.

  1. Главная ссылка к новости (https://github.com/facebookinc...)
  2. OpenNews: Выпуск earlyoom 1.3, процесса для раннего реагирования на нехватку памяти
  3. OpenNews: Выпуск Nohang 0.1, предотвращающего OOM в пространстве пользователя
  4. OpenNews: Facebook открыл код для обработки ситуации нехватки памяти в системе
  5. OpenNews: Ядро Linux не может мягко обрабатывать ситуации с нехваткой памяти
  6. OpenNews: Представлен low-memory-monitor, новый обработчик нехватки памяти для GNOME
Автор новости: hakavlad
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51469-oomkiller
Ключевые слова: oomkiller, oomd, memory
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (42) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.16, кек (?), 01:47, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Традиционное сравнение киллеров: паста написана месяц назад:

    https://www.opennet.me/tips/3116_oomkill_memory_earlyoom_nohang_oomd.shtml

     
     
  • 2.42, кек (?), 17:32, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как oomd убивает сессию https://imgur.com/a/FSOtqPm
     

  • 1.1, Аноним (1), 23:28, 11/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Он так же тормозит как сам Facebook?
     
     
  • 2.3, Водитель маршрутки (?), 23:43, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Даже лучше
     

  • 1.2, Аноним (2), 23:42, 11/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    чем оно лучше earlyoom?
     
     
  • 2.4, Аноним (4), 23:44, 11/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    PSI
     
  • 2.8, Аноним (8), 00:11, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Тем что не требует "новейшего" ядра и библиотек с подачей смузи.
     
  • 2.9, Аноним (8), 00:12, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, что есть пакеты.
     

  • 1.5, Грусть (?), 23:51, 11/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Плагины - плохой признак проекта.
     
     
  • 2.10, Аноним (10), 00:21, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Почему?
     
     
  • 3.11, Грусть (?), 00:28, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что авторы не знают, чего хотят, и делают то, что могут, а не то, что надо.
     
     
  • 4.14, Аноним (14), 01:18, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Типо, пока сам не сделаешь — никто не сделает?
     
  • 3.25, Аноним (1), 09:31, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что для таких крохотных утилит это оверинжиниринг и демонстрация непонимания авторами как ими будут пользоваться конечные пользователи. Это как для rm написать плагинную систему - можно, но зачем?
     
     
  • 4.32, кек (?), 10:02, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >для таких крохотных утилит это оверинжиниринг и демонстрация непонимания авторами как ими будут пользоваться конечные пользователи

    Конечными пользователями oomd являются админы крупных компаний с разными потребностями. Это вы нихрена не понимаете.

     
     
  • 5.35, Аноним (35), 11:39, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, вы не понимаете. В крупных компаниях пишут свои oom killer'ы под свои потребности, либо форкают проект и допиливают под себя. В тех полутора тысячах строчек ядра сабжа нет ничего уникального, чего бы не написал обычный программист, зато есть много лишнего, чего не требуется для конкретных узкоспециализированных случаев.
     
  • 2.29, freehck (ok), 09:44, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Плагины - плохой признак проекта.

    Ну конечно. Ведь давать людям возможность допилить продукт под их нужды без изменения базовой функциональности -- это так неправильно.

     
     
  • 3.36, Грусть (?), 13:00, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не передёргивайте. Плагины - причина повнимательнее посмотреть на "продукт". Так же как банку на ИП, который не платит с этого банка налоги.

    Это же относится к развесистой конфигурации.

     

  • 1.17, Аноним (17), 02:45, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    хорошо хоть тут адекватные люди и пишут не на расте
     
  • 1.18, Аноним (18), 03:38, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я думаю, было бы неплохо, если бы у нас был способ заставить пользователей Fedora принимать участие в экспериментах, а затем случайным образом давать им такие вещи, как nohang и earlyoom, oomd и монитор с низким объемом памяти. Нет документации, нет предупреждения, ничего. Они просто получают один из них. Как будто это их установка по умолчанию. И посмотреть, что взрывается, или нет, какие жалобы у них есть, или нет. Если они явно устанавливают что-то, а не случайно, они в конечном итоге оказываются смещенными, что фактически загрязняет данные. Просто мысль.

    https://pagure.io/fedora-workstation/issue/98#comment-597005

    Теперь прошу юзеров Федоры описать свой разрыв.

     
     
  • 2.33, Аноним (33), 10:14, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > способ заставить пользователей Fedora принимать участие в экспериментах

    А они разве чем-то другим занимаются?

     
  • 2.37, Аноним (37), 14:16, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > opt-in
    > заставить

    Больше не занимайся переводами

     

  • 1.19, Аноним (19), 03:50, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Линуксопроблемы
     
  • 1.22, Аноним (22), 08:42, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Граждане эксперты, поясните за OOM.

    Почему в Linux есть memory overcommitment и OOM killer, а в Windows есть другой dynamic memory, и OOM killer отсутствует. Или я вообще всё путаю?

    Насколько я понял, всегда можно попросить 20GB оперативной памяти, и если у тебя её нету, то ты попадаешь в swap. В windows при достижении определённого предела загрузки памяти старые приложения которые пытаются захватить больше памяти, вновь загружаемые приложения и пользователи внутрь своих сессий получат сообщения OOM.
    А в Linux почему-то есть OOM killer, который зачем-то убивает процессы. А в друг там было что-то важное?

    Я понимаю, что Windows API и POSIX это как небо и земля разные вещи. Что поведение очень разное, даже загрузка dll и загрузка so тоже отличается.

    Я просто не понимаю, почему убивать? Или это потому что в Linux опять со свопом проблемы? https://bugzilla.kernel.org/show_bug.cgi?id=196729
    По идее если толстые приложения убить, то в сессии пользователя освободится память, чтобы запустить утилиты и решить что позакрывать. У Windows в связи с этим традиционно проблема, потому что запус того же Task Manager может длится долго в ситуации полного исчерпания памяти.

    Но ведь несмотря на логику memory overcommitment и oom killer графические сессии чувствуют себя намного хуже чем windows, при полном исчерпании свободной памяти. https://lkml.org/lkml/2019/8/4/15

     
     
  • 2.26, exSun (ok), 09:35, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Потому что внезапно стало приемлемым не рассчитывать доступный объём памяти и настраивать приложения соответственно располагаемым объёмам, а надеяться, что оно там само как-то разберётся. Потому что средний десктоп-юзер не понимает не то что нюансов, а даже основ эксплуатации промышленных систем, не хочет и не будет их понимать. Потому что именно средние десктопные пользователи теперь называются девопсами-админами и используют столь привычные им практики администрирования десктопов в промышленных средах. Потому что десктопные приложения достигли такого уровня сложности внутреннего устройства, что их авторы не могут оптимизировать потребление памяти. Потому что RAM теперь стоит недорого и его "всегда можно добавить", но нет понимания, что очередной гигабайт может оказаться последним. Потому что в свопе работать нельзя ни на сервере, ни на десктопе, но очень хочется.
     
     
  • 3.30, freehck (ok), 09:45, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Потому что именно средние десктопные пользователи теперь называются девопсами-админами и используют столь привычные им практики администрирования десктопов в промышленных средах.

    Я вам открою секрет. Ламера понабежали не только в "девопсы" и в "админы". Они понабежали во все сферы IT. И между прочим, уже достаточно давно.

     
     
  • 4.34, exSun (ok), 11:31, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а теперь их узаконили, да.
     
  • 4.38, пох. (?), 14:29, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    да они, блжад, в разработчики понабежали. Ни девопсу, ни админу тут уже ничего не поделать.
    Будь ламером, будь как все!

     
     
  • 5.39, freehck (ok), 14:50, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > да они, блжад, в разработчики понабежали. Ни девопсу, ни админу тут уже ничего не поделать.

    Да я тут где-то уже писал, вроде бы, что работа хорошего девопса заключается в том, что мы берём три решета, и ставим их друг за другом, чтобы все дырки оказались закрыты. Так что кое-что поделать вполне себе можно. Немного неприятно, что система целиком в голове теперь ну совсем уже не помещается. Но это, в принципе, ожидаемо. Мир усложняется. Общество требует всё более высоких технологий, и побыстрее. А столько хороших разработчиков просто не существует. Поэтому общество использует то, что есть. Результат, как обычно: изнутри -- костыль на костыле; но зато решает задачи людей, и потому они готовы платить ещё и ещё.

    > Будь ламером, будь как все!

    Я думаю, что это ложный вывод. Стремиться надо к лучшему.

     
  • 3.40, заминированный тапок (?), 15:52, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    если система не может корректно обработать ситуацию нехватки ресурсов и виснет, bsod'ит, паникует или ведёт себя иным некорректным образом, то есть просто падает - какя она на**й "промышленная" ? вы в своём уме?

    конечно проще сказать: "это не дорожники плохо асфальт постелили, это обувь китайская на ногах его портит"

     
  • 2.41, x (?), 16:24, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    overcommitment в 64 не работает как задумано. а ограничить нельзя просто так н.р.
    те же инструментированные address-sanitizer сборки любого процесса тут же выделяют 20 Тб на старте, и нормально себе работают. Так же маппинг гигабайтных файлов требует больших адресных пространств.

    Теперь имеем что на x64 malloc() всегда завершается удачно, а память жрется по фактическому обращению на страницу в недерминированный момент времени.. как это разрулить пока никто не придумал.

     
     
  • 3.43, Павел Отредиез (?), 19:10, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я сегодня тестировал limits.conf  на Elementary OS 5 64 бита. Ulimit -а показывает установленные лимиты по памяти, а тестовая mem-бомба с malloc в цикле плюёт на них и загоняет систему в swap. Значит вы говорите, что это свойство 64 битных систем? Я правильно понял?
     
     
  • 4.44, Павел Отредиез (?), 20:11, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Я ввожу в заблуждение. Лимиты нормально отрабатывают и на 32 и на 64 бита. И да, malloc возвращает Null при достижении лимитов и на 64 битах.
     
     
  • 5.45, Павел Отредиез (?), 22:03, 13/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В общем я ошибался. По памяти пользователя лимитами и не ограничить.
     
     
  • 6.46, кек (?), 07:00, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Очень даже ограничить.

    В limits.conf ключ as позволяет ограничивать размер ВИРТУАЛЬНОЙ ПАМЯТИ КАЖДОГО ПРОЦЕССА сессии пользователя.

    Ну а в сигруппах memory.max уже устанавливает лимит РЕАЛЬНОЙ ПАМЯТИ для ЦЕЛОЙ ГРУППЫ.

     
     
  • 7.47, Павел Отредиез (?), 10:02, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Очень даже ограничить.
    > В limits.conf ключ as позволяет ограничивать размер ВИРТУАЛЬНОЙ ПАМЯТИ КАЖДОГО ПРОЦЕССА
    > сессии пользователя.

    Да, но у palemoon без вкладок VIRT=2G сразу
    Черново для себя сделал в ядре ключ rss - резидентная память. Было не реализовано:
    man bash:
    -m     The maximum resident set size (many systems do not honor this limit)
    2 строчки патча.

    > Ну а в сигруппах memory.max уже устанавливает лимит РЕАЛЬНОЙ ПАМЯТИ для ЦЕЛОЙ
    > ГРУППЫ.

    Напишите кто-нибудь пожалуйста в советы рабочее на сегодняшний день howto "Ограничение памяти по пользователям с помощью cgroups". У меня лично эта тема не получается :(((.

     
     
  • 8.48, кек (?), 13:52, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https www linux org ru forum general 14991027 тема раскрыта ... текст свёрнут, показать
     
  • 8.49, кек (?), 13:55, 14/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    systemd-run --user -p MemoryMax 1G -p MemorySwapMax 0 foo ... текст свёрнут, показать
     

  • 1.23, Аноним (23), 09:13, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    На самом деле дело обстоит так:

    Нехватка релизов обработчиков памяти!

     
     
  • 2.24, кек (?), 09:29, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Скоро nohang 0.2 выйдет, не беспокойтесь
     

  • 1.27, кек (?), 09:37, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Продублирую тут пасту с лора.

    >Ну и чем ваш костыль лучше костыля cgroups?

    По части предотвращения ООМ юзерспейсные демоны проще и более гибкие.

    Например, если хотите защитить систему от переполнения памяти путем использования earlyoom - достаточно его просто установить, и он будет работать достаточно хорошо, реагируя, если SwapFree < 10% & MemAvailable < 10% (пороги легко изменить через конфиг). Эти пороги будут работать на любой системе с любым размером памяти.

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

    Далее. При ООМ внутри сигруппы (если группа упрется в лимит memory.max) в ней произойдет вызов OOMK и жирный процесс будет убит через SIGKILL: это еще один минус - невозможность кастомизации корректирующего действия (в earlyoom и nohang процесс сначала получит SIGTERM для возможности более корректного завершения).

    Далее, настройка сигруп не позволяет (пока не позволяет, но Лёня обдумывает) реагировать на превышение в системе заданных уровней PSI memory pressure: если в системе интенствный swapping/thrashing/конкуренция за память, да такая, что рабочий стол замерз (это может произойти и при большом свободнос свопе) - сигруппы тут также бессильны.

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

    Ну и да, сигруппы тебе не отправт уведомления на раб стол, если случится убийство (nohang может, если вкючить в кофиге).

     
  • 1.28, Аноним (28), 09:39, 12/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Мы придумали OOM обработчик, который вылезает раньше системного OOM обработчика, и тем решили проблему, что мы не умеем писать софт, влезающий в ОЗУ, а не забивающий, пока ОЗУ не кончится совсем-совсем!

     
     
  • 2.31, кек (?), 09:59, 12/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >мы не умеем писать софт, влезающий в ОЗУ

    Умеют, но это дороже обойдется. А вообще-то у них миллиарды пользователей. Как ты представляешь себе оптимизацию софта для таких нагрузок?

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру