The OpenNET Project / Index page

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

Выпуск уведомителя о нехватке ресурсов psi-notify 1.0.0

17.05.2020 18:17

Опубликован выпуск программы psi-notify 1.0, которая может предупредить при появлении в системе конкуренции за ресурсы (cpu, память, ввод/вывод) для того, чтобы предпринять действия, прежде чем система замедлится. Код открыт под лицензией MIT.

Приложение работает на уровне непривилегированного пользователя, а для оценки нехватки ресурсов в масштабе всей системы использует подсистему ядра PSI (Pressure Stall Information), которая позволяет проанализировать информацию о времени ожидания получения различных ресурсов (CPU, память, ввод/вывод) для определённых задач или наборов процессов в cgroup.

В отличие от MemAvailable, графиков ЦП, графиков использования ввода-вывода и других показателей, Psi-notify даёт возможность идентифицировать неправильно работающие приложения на компьютере до того, как они начнут серьёзно влиять на быстродействие. Для работы требуется поддержка PSI ядром (Linux 4.20+ c настройкой CONFIG_PSI=y). Для отправки уведомлений на рабочий стол при нехватке ресурсов применяется libnotify.

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


Обсуждение (35) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 21:53, 17/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Я что-то заметил, 5.4 как-то иначе реагирует на кончившуюся память, не как 4.19. Иксы больше не зависают, курсор продолжает двигаться (с лагами), но запустить или убить ничего нельзя (хоткей с xkill бы работал, эх). Но в то же время у меня на 5.4 зависла консоль на tty, чего с 4.19 никогда не случалось. В логах после хардресета посмотрел, ядро реагировало на magic key, но этого с хоста было не увидеть никак. Вывод: раньше было лучше -- ядро опять сломали.
     
     
  • 2.2, tr (?), 22:08, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    >после хардресета

    Какой ужас. Почему не пользуетесь обработчиком нехватки памяти в пространстве пользователя?

    Вот устаревщий обзор: https://www.opennet.me/tips/3116_oomkill_memory_earlyoom_nohang_oomd.shtml

    В 2020 некоторые дистрибутивы уже включают их по умолчанию. Завершение процесса по SIGTERM - это лучше, чем hard reset.

     
     
  • 3.6, Аноним (1), 22:25, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Очень часто случается такое, что ядро реагирует только на sysrq+b, тут уж как повезёт. Это очень болезненно, хотя бы потому, что все диски смонтированы с data=writeback. В норме то реагирует на sysrq+f и всё сразу в порядке (не для убитого процесса). В крайнем случае sysrq+e (отправить sigterm всем процессам) должен спасти. Но, если никакие команды кроме b не срабатывают, всё очень плохо. Тут они срабатывали, да видеодрайвер, похоже, завис.

    Юзерспейсные обработчики ни от чего не спасут, памяти нужно много и внезапно: порядка 80% на линковку, например.

     
     
  • 4.8, tr (?), 22:32, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Юзерспейсные обработчики ни от чего не спасут

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

     
     
  • 5.10, Аноним (1), 22:36, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так в том и дело, что память будет исчерпана целиком и полностью совершенно внезапно. Когда тут реагировать? Отдельное приключание, если у нас ещё есть своп, который можно невозбранно исчерпать не менее внеазпно.
     
     
  • 6.12, tr (?), 22:45, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >целиком и полностью совершенно внезапно

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

    Юзерспейсные обработчики проверяют состояние памяти до десяти раз в секунду. Этого вполне достаточно для реакции, даже если память пожирается очень быстро.

    Например:

    https://youtu.be/UCwZS5uNLu0 – running multiple fast memory hogs at the same time without swap space.

    Тем более при наличии свопа нет проблемы вовремя среагировать.

     
     
  • 7.14, Аноним (1), 22:58, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Слишком абстрактно. Я когда-то тестировал память в четырёхканальном режиме, там получалось что-то в районе 60гб/с. Естественно, память очень медленная даже в идеальных условиях, но на вероятность исчерпать последние проценты и повесить систему это не влияет.

    CONFIG_HZ_PERIODIC=y
    CONFIG_HZ_1000=y
    CONFIG_HZ=1000

    С такими параметрами ядро может реагировать достаточно долго даже на magic-key что уж там говорить про какие-то пользовательские приложения. С nohz у меня лаги были, а так там вроде можно и больше 1000 раз (с nohz).

     
     
  • 8.18, tr (?), 23:21, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Наоброт, предоставлена конкретика обработчик нехватки памяти nohang обрабатывае... текст свёрнут, показать
     
     
  • 9.20, Аноним (1), 23:34, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Синтетика 8230 Видеокарта не используется, опять же, а ведь именно видеокарта ... текст свёрнут, показать
     
     
  • 10.23, хз2 (?), 04:11, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Синтетика как раз позволяет моделировать нужное поведение, такое как быстрое пог... текст свёрнут, показать
     
     
  • 11.25, Аноним (1), 05:47, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Можно замечательно сымитировать создав файл в tmpfs Тоже всё зависнет Но когда... текст свёрнут, показать
     
     
  • 12.26, хзъ (?), 06:40, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Всё так Ни ядро, ни юзерспейсные киллеры не разруливают переполение tmpfs Впро... текст свёрнут, показать
     
  • 4.9, Аноним (1), 22:34, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пока сделал вывод, что не нужно пытаться перейти на tty, если иксы "залагали" подобным образом от нехватки памяти. Если sysrq+f не помогает, лучше жать sysrq+e и молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на диске. Потому что после перехода на tty всё точно окончательно зависнет (баг в kms?). Почему всё зависло в тот раз и без иксов (они даже не были запущены), я не знаю, видимо опять этот баг в kms.
     
     
  • 5.11, tr (?), 22:40, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на диске

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

     
     
  • 6.13, Аноним (1), 22:48, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Но ведь лучшая практика - избегать убийства сессии, чтоб не убивать все
    > процессы сессии. Лучшая практика - завершить минимум процессов, по возможности через
    > SIGTERM. Лучшие из обработчиков нехватки памяти умеют тонко приоретизировать выбор процесса,
    > по возможности избегая убийства всей сессии с потерей несохраненных данных.

    А кто им даст такую возможность? Даже если приложение написано в лучшем стиле реалтайм систем... И никогда не выделяет память динамически (и ничего не запускает -- с чем запустили, с тем и живём), если оно висит в фоне, ему времени может и не перепасть. Тут даже magic key реагирует с задержкой в пару минут. А уж если led-индикаторы на клавиатуре не реагируют, это надёжный признак того, что мы приплыли. На удивление, sysrq+b всё равно работает. Но это ничем не отличается от хардресета.

     
     
  • 7.15, tr (?), 23:01, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >А кто им даст такую возможность?

    1. Автор демона.

    2. Админ, который установит и запустит демона.

    >приложение написано в лучшем стиле реалтайм систем

    Реалтайм не обязателен. Достаточного одного mlockall() - это уже дает фору демону, особенно при своппинге.

    >И никогда не выделяет память динамически

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

    >ему времени может и не перепасть

    Такое возможно, если специально выставить неадекватные пороги - то есть указать демону реагировать лишь когда память  совсем исчерпана, близка к нулю. На самом деле время практически всегда всегда перепадает, и проблем с реакцией нет, что и продемонстрировано здесь: https://youtu.be/UCwZS5uNLu0

    >даже magic key реагирует с задержкой в пару минут

    Правильно, потому что ядерный киллер сломан. Триггеринг киллера зачастую приводит лишь к purging GPU memory вместо убийства жиробаса. В то время как юзерспейсный киллер за десятки секунд находит жертву и отправляет сигнал.

     
     
  • 8.16, tr (?), 23:05, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пардон, за десятки миллисекунд Это у ядерного счет идет на секунды, минуты и ча... текст свёрнут, показать
     
  • 8.19, Аноним (1), 23:30, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Очень даже обязателен Реалтайм процессы не выделяют память и ни от чего не зави... текст свёрнут, показать
     
     
  • 9.22, хз2 (?), 03:55, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В современном гном3 и циннамоне каждое приложение запускается в отдельной группе... текст свёрнут, показать
     
     
  • 10.24, Аноним (1), 05:45, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А если у меня его нет Зачем же так категорично То, что для вас Реалтаймовость... текст свёрнут, показать
     
     
  • 11.27, хзъ (?), 07:04, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тогда ССЗБ Большинство дистров поставляются с ним Зачем вы выбрали дистрибутив... текст свёрнут, показать
     
  • 11.38, Аноним (38), 13:12, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тогда сам создавай все это чем там тебе удобно Ты не искал легких путей Зна... текст свёрнут, показать
     
  • 2.4, null (??), 22:22, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Alt+SysRq+F пробовал ?
     
     
  • 3.17, Аноним (17), 23:07, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Что за кнопка SysRQ
     
     
  • 4.21, DiabloPC (ok), 00:48, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    https://static.thegeekstuff.com/wp-content/uploads/2008/12/sysrq-key-300x199.j
     
     
  • 5.30, Аноним (17), 10:05, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо, это заставило меня почитать про kernel signals, я даже не знал что такое есть.
     
  • 2.5, ilyafedin (ok), 22:23, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ctrl + Alt + SysRq + F - вызовет ядерный OOM-киллер через sysrq, от этого ядру не отвертеться. Разумеется, если включен kernel.sysrq.
     
     
  • 3.7, Аноним (1), 22:27, 17/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6 пояснил, далеко не всегда работает.
     
     
  • 4.39, Аноним (-), 13:15, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6
    > пояснил, далеко не всегда работает.

    Щасливый пользователь нвидий? Если ядро на sysrq не реагирует - ему совсем поплохело. Или соотв. реакция запрещена, это настраивается.

     
     
  • 5.41, Аноним (1), 13:36, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У счастливого пользователя амд ядро падает в панику при открытии хромиума. Упс, ещё хуже.
     
  • 2.33, RNZ (ok), 20:27, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    vm.overcommit_ratio = 200
    vm.overcommit_memory = 2
    swapoff

    И все дела.

     
     
  • 3.35, яч (?), 04:08, 19/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    и хром не запустится
     
     
  • 4.37, RNZ (ok), 12:40, 21/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > и хром не запустится

    Не правда.

    Запустится и будет работать, когда попытается аллоцировать больше чем есть - просто сразу сдохнет.
    Проверь сам.

     
     
  • 5.40, Аноним (-), 13:18, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А если памяти мало - можно своп в zram сделать
     
     
  • 6.42, RNZ (ok), 16:53, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А если памяти мало - можно своп в zram сделать

    Так и делаю где требуется:

       # zramctl
       NAME       ALGORITHM DISKSIZE  DATA COMPR TOTAL STREAMS MOUNTPOINT
       /dev/zram0 lz4          75,6G 15,6G  3,9G 11,2G      50 [SWAP]

       # free -g
                     total        used        free      shared  buff/cache   available
       Mem:            251          76         130          24          45         149
       Swap:            75          16          58

     

  • 1.3, Повидло19 (?), 22:22, 17/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Осведомителя выпустили?
     
  • 1.28, СеменСеменыч777 (?), 09:02, 18/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    апогей современной софт-индустрии.
    вместо того, чтобы разобраться с текущим приложением (например ограничить его аппетит. или прекратить его использование. или свопнуть), давайте сперва отстрелим самое жирное через ядро, потом сделаем то же от юзера, потом заведем спец.подсистему в ядре !
     
     
  • 2.29, Секция (?), 09:48, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что сказать-то хотел, умник? оверкомммит разрешен для более полной утилизации памяти. однако киллер оказался слабоват, проблема вскрыта и решается средствами юзерспейса.

    >апогей современной софт-индустрии.

    Не апогей, а обычное средство мониторинга доступности ресурсов.

     
  • 2.32, Annoynymous (ok), 19:08, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да, до изобретения виртуальной памяти такой проблемы действительно не было.

    Но тогда, в 1977-м, были другие.

     
     
  • 3.34, пох. (?), 22:27, 18/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    эн, нет - в 78 виртуальная память была swap-backed, смысл ее виртуальности был в том чтобы дать программам память в рамках разделения ресурсов - "если ты все равно не занимаешь процессор, полежи на диске...зачеркнуто, для этого использовали барабан, заодно и память пригодится другим". В те времена такого катастрофического разрыва по скорости между оперативной памятью и внешним носителем не было.

    Чудеса с виртуальной памятью в /dev/zero, которой не соответствует никакое место ни на диске ни в памяти - это изобретение 90х, когда памяти стало уже много, а диски изрядно от нее отстали.

     

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



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

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