Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск уведомителя о нехватке ресурсов psi-notify 1.0.0"	+/–
Сообщение от opennews (??), 17-Май-20, 21:53
Опубликован выпуск программы psi-notify 1.0, которая  может предупредить при появлении в  системе конкуренции за ресурсы (cpu, память, ввод/вывод) для того, чтобы предпринять действия, прежде чем система замедлится. Код открыт под лицензией MIT... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52976
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 17-Май-20, 21:53	+6 +/–
Я что-то заметил, 5.4 как-то иначе реагирует на кончившуюся память, не как 4.19. Иксы больше не зависают, курсор продолжает двигаться (с лагами), но запустить или убить ничего нельзя (хоткей с xkill бы работал, эх). Но в то же время у меня на 5.4 зависла консоль на tty, чего с 4.19 никогда не случалось. В логах после хардресета посмотрел, ядро реагировало на magic key, но этого с хоста было не увидеть никак. Вывод: раньше было лучше -- ядро опять сломали.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #4, #5, #33

2. Сообщение от tr (?), 17-Май-20, 22:08	–5 +/–
>после хардресета Какой ужас. Почему не пользуетесь обработчиком нехватки памяти в пространстве пользователя? Вот устаревщий обзор: https://www.opennet.dev/tips/3116_oomkill_memory_earlyoom_noh... В 2020 некоторые дистрибутивы уже включают их по умолчанию. Завершение процесса по SIGTERM - это лучше, чем hard reset.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #6

3. Сообщение от Повидло19 (?), 17-Май-20, 22:22	–2 +/–
Осведомителя выпустили?
Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от null (??), 17-Май-20, 22:22	+1 +/–
Alt+SysRq+F пробовал ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #17

5. Сообщение от ilyafedin (ok), 17-Май-20, 22:23	+1 +/–
Ctrl + Alt + SysRq + F - вызовет ядерный OOM-киллер через sysrq, от этого ядру не отвертеться. Разумеется, если включен kernel.sysrq.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7

6. Сообщение от Аноним (1), 17-Май-20, 22:25	+4 +/–
Очень часто случается такое, что ядро реагирует только на sysrq+b, тут уж как повезёт. Это очень болезненно, хотя бы потому, что все диски смонтированы с data=writeback. В норме то реагирует на sysrq+f и всё сразу в порядке (не для убитого процесса). В крайнем случае sysrq+e (отправить sigterm всем процессам) должен спасти. Но, если никакие команды кроме b не срабатывают, всё очень плохо. Тут они срабатывали, да видеодрайвер, похоже, завис. Юзерспейсные обработчики ни от чего не спасут, памяти нужно много и внезапно: порядка 80% на линковку, например.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8, #9

7. Сообщение от Аноним (1), 17-Май-20, 22:27	+/–
Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6 пояснил, далеко не всегда работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #39

8. Сообщение от tr (?), 17-Май-20, 22:32	+1 +/–
>Юзерспейсные обработчики ни от чего не спасут Они спасают от нехватки памяти, что подтверждено многочисленными отзывами. Они как раз и предотвращают состояние, когда все запущено и реагировать трудно, ибо реагируют тогда, когда память еще не полностью исчерпана.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #10

9. Сообщение от Аноним (1), 17-Май-20, 22:34	+/–
Пока сделал вывод, что не нужно пытаться перейти на tty, если иксы "залагали" подобным образом от нехватки памяти. Если sysrq+f не помогает, лучше жать sysrq+e и молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на диске. Потому что после перехода на tty всё точно окончательно зависнет (баг в kms?). Почему всё зависло в тот раз и без иксов (они даже не были запущены), я не знаю, видимо опять этот баг в kms.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11

10. Сообщение от Аноним (1), 17-Май-20, 22:36	+1 +/–
Так в том и дело, что память будет исчерпана целиком и полностью совершенно внезапно. Когда тут реагировать? Отдельное приключание, если у нас ещё есть своп, который можно невозбранно исчерпать не менее внеазпно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #12

11. Сообщение от tr (?), 17-Май-20, 22:40	+/–
>молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на диске Но ведь лучшая практика - избегать убийства сессии, чтоб не убивать все процессы сессии. Лучшая практика - завершить минимум процессов, по возможности через SIGTERM. Лучшие из обработчиков нехватки памяти умеют тонко приоретизировать выбор процесса, по возможности избегая убийства всей сессии с потерей несохраненных данных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #13

12. Сообщение от tr (?), 17-Май-20, 22:45	–1 +/–
>целиком и полностью совершенно внезапно Ничего подобного, память исчерпывается с ограниченной скоростью. Даже без свопа при запуске многопоточного stress скорость исчерпания ограничена десятком гигабайт в секунду. Юзерспейсные обработчики проверяют состояние памяти до десяти раз в секунду. Этого вполне достаточно для реакции, даже если память пожирается очень быстро. Например: https://youtu.be/UCwZS5uNLu0 – running multiple fast memory hogs at the same time without swap space. Тем более при наличии свопа нет проблемы вовремя среагировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #14

13. Сообщение от Аноним (1), 17-Май-20, 22:48	+/–
> Но ведь лучшая практика - избегать убийства сессии, чтоб не убивать все > процессы сессии. Лучшая практика - завершить минимум процессов, по возможности через > SIGTERM. Лучшие из обработчиков нехватки памяти умеют тонко приоретизировать выбор процесса, > по возможности избегая убийства всей сессии с потерей несохраненных данных. А кто им даст такую возможность? Даже если приложение написано в лучшем стиле реалтайм систем... И никогда не выделяет память динамически (и ничего не запускает -- с чем запустили, с тем и живём), если оно висит в фоне, ему времени может и не перепасть. Тут даже magic key реагирует с задержкой в пару минут. А уж если led-индикаторы на клавиатуре не реагируют, это надёжный признак того, что мы приплыли. На удивление, sysrq+b всё равно работает. Но это ничем не отличается от хардресета.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #15

14. Сообщение от Аноним (1), 17-Май-20, 22:58	+/–
Слишком абстрактно. Я когда-то тестировал память в четырёхканальном режиме, там получалось что-то в районе 60гб/с. Естественно, память очень медленная даже в идеальных условиях, но на вероятность исчерпать последние проценты и повесить систему это не влияет. CONFIG_HZ_PERIODIC=y CONFIG_HZ_1000=y CONFIG_HZ=1000 С такими параметрами ядро может реагировать достаточно долго даже на magic-key что уж там говорить про какие-то пользовательские приложения. С nohz у меня лаги были, а так там вроде можно и больше 1000 раз (с nohz).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18

15. Сообщение от tr (?), 17-Май-20, 23:01	–3 +/–
>А кто им даст такую возможность? 1. Автор демона. 2. Админ, который установит и запустит демона. >приложение написано в лучшем стиле реалтайм систем Реалтайм не обязателен. Достаточного одного mlockall() - это уже дает фору демону, особенно при своппинге. >И никогда не выделяет память динамически Для парсинга значений oom_score процессов нужно совсем немнго памяти, и делается это за десятки миллисекунд. >ему времени может и не перепасть Такое возможно, если специально выставить неадекватные пороги - то есть указать демону реагировать лишь когда память  совсем исчерпана, близка к нулю. На самом деле время практически всегда всегда перепадает, и проблем с реакцией нет, что и продемонстрировано здесь: https://youtu.be/UCwZS5uNLu0 >даже magic key реагирует с задержкой в пару минут Правильно, потому что ядерный киллер сломан. Триггеринг киллера зачастую приводит лишь к purging GPU memory вместо убийства жиробаса. В то время как юзерспейсный киллер за десятки секунд находит жертву и отправляет сигнал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #16, #19

16. Сообщение от tr (?), 17-Май-20, 23:05	+1 +/–
>за десятки секунд Пардон, за десятки миллисекунд. Это у ядерного счет идет на секунды, минуты и часы: https://www.opennet.dev/opennews/art.shtml?num=51231
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

17. Сообщение от Аноним (17), 17-Май-20, 23:07	+/–
Что за кнопка SysRQ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #21

18. Сообщение от tr (?), 17-Май-20, 23:21	+/–
>Слишком абстрактно. Наоброт, предоставлена конкретика: обработчик нехватки памяти nohang обрабатывает нехватку памяти при циклическом запуске трех потоков tail /dev/zero. Вот еще демо: nohang обрабатывает восьмипоточный stress при наличии свопа: реагирует на конкуренцию за память, тем самым прекращая заморозку десктопа: https://youtu.be/Y6GJqFE_ke4
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #20

19. Сообщение от Аноним (1), 17-Май-20, 23:30	+/–
Очень даже обязателен. Реалтайм процессы не выделяют память и ни от чего не зависят. Ведь именно с этим и возникает проблемы -- памяти не выделить, если её уже нет. >указать демону реагировать лишь когда память  совсем исчерпана, близка к нулю В целом, обычная ситуация -- 95% занятой памяти вовсе не означает, что нам когда-нибудь потребуются оставшиеся 5%. Я проверял, через 20+ часов работы памяти оставалось 4%. Лучше заставить остальные приложения реагировать подобно хромиуму: ронять свои лишние зажравшиеся процессы самостоятельно. У файрфокса с этим большие проблемы. Но я не понимаю, как заставить ядро грохать фф (весь его неймспейс). И даже не вижу штатного способа запускать браузер в другой контрольной группе (все иксовые приложения в группе /xdm). Только почему хромиум справляется и без костылей? Сам себе выставляет процессам вкладок повышенный вес для oom-killer (фф этого не делает) и без задержек прибивает лишних? Но правда хромиум идёт с суидной рутовой песочницей, что тоже не очень приятно. Может быть в этом дело?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #22

20. Сообщение от Аноним (1), 17-Май-20, 23:34	+/–
Синтетика… Видеокарта не используется, опять же, а ведь именно видеокарта (и отображение её памяти в оперативку) основная причина фризов, в том числе и на венде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #23

21. Сообщение от DiabloPC (ok), 18-Май-20, 00:48	+/–
https://static.thegeekstuff.com/wp-content/uploads/2008/12/s...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #30

22. Сообщение от хз2 (?), 18-Май-20, 03:55	+/–
>штатного способа запускать браузер в другой контрольной группе В современном гном3 и циннамоне каждое приложение запускается в отдельной группе. В прочих окружениях: `systemd-run --user --scope foo` запуск в отдельной группе. >Реалтайм процессы не выделяют память Это ложь. Реалтаймовость процесса - это лишь приоритет по ЦПУ. Любому процессу можно дать реалтаймовость - и это не приведет к прекращению выделений памяти. >суидной рутовой песочницей, что тоже не очень приятно. Может быть в этом дело? Разумеется, для изменения oom_score_adj нужен рут. >Но я не понимаю, как заставить ядро грохать фф (весь его неймспейс) Зачем же весь? Лучше отдельные вкладки прибивать, то есть повышать приоритет убийства для процессов Web Content - с этим как раз отлично справляются юзерспейсные обработчики. >и без задержек прибивает лишних? Ядерный киллер не может прибивать без задержек, юзерспейсные киллеры - могут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #24

23. Сообщение от хз2 (?), 18-Май-20, 04:11	+/–
Синтетика как раз позволяет моделировать нужное поведение, такое как быстрое поглощение памяти в примере выше. В большинстве же случаев утечки происходят не очень быстро. >Видеокарта не используется Проблемы с дровами и зависания от проблем с видюхой - ЭТО ДРУГОЕ, это не связано с нехваткой памяти. От проблем с видюхой машины виснут и когда памяти много свободной.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #25

24. Сообщение от Аноним (1), 18-Май-20, 05:45	+/–
>systemd А если у меня его нет? >Это ложь. Реалтаймовость процесса - это лишь приоритет по ЦПУ. Любому процессу можно дать реалтаймовость - и это не приведет к прекращению выделений памяти. Зачем же так категорично? То, что для вас "Реалтаймовость процесса - это лишь приоритет по ЦПУ." вовсе не значит, что так и есть. >повышать приоритет убийства для процессов Web Content - с этим как раз отлично Почему он не может это делать сам? >Ядерный киллер не может прибивать без задержек, юзерспейсные киллеры - могут. Ну, хорошо, если так. Я ещё не видел ни одного юзерспейсного приложения, остававшегося живым и отвечающим в таких условиях.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #27, #38

25. Сообщение от Аноним (1), 18-Май-20, 05:47	+/–
Можно замечательно сымитировать создав файл в tmpfs. Тоже всё зависнет. Но когда это миллионы файлов (практическое применение), всё зависнет гораздо надёжней.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #26

26. Сообщение от хзъ (?), 18-Май-20, 06:40	+/–
Всё так. Ни ядро, ни юзерспейсные киллеры не разруливают переполение tmpfs. Впрочем, можно научить юзерспейсных обработчиков очищать tmpfs от части крупнейших файлов в избранных директориях. Впрочем, хорошая практика - это ограничение макс размера tmpfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

27. Сообщение от хзъ (?), 18-Май-20, 07:04	–2 +/–
>А если у меня его нет? Тогда ССЗБ. Большинство дистров поставляются с ним. Зачем вы выбрали дистрибутив без системного менеджера? >Почему он не может это делать сам? Почему же не может? Может, но не хочет. Или его разработчики не хотят этого. >Я ещё не видел ни одного юзерспейсного приложения, остававшегося живым и отвечающим в таких условиях. В каких таких? Чтобы такие условия не наступали как раз и существуют юзерспейсные обработчики - они пытаются предотвратить livelock своевременно, до того, как станет поздно, пока доступная память не исчерпана полностью и еще есть пространство для маневра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

28. Сообщение от СеменСеменыч777 (?), 18-Май-20, 09:02	+/–
апогей современной софт-индустрии. вместо того, чтобы разобраться с текущим приложением (например ограничить его аппетит. или прекратить его использование. или свопнуть), давайте сперва отстрелим самое жирное через ядро, потом сделаем то же от юзера, потом заведем спец.подсистему в ядре !
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #29, #32

29. Сообщение от Секция (?), 18-Май-20, 09:48	+2 +/–
Что сказать-то хотел, умник? оверкомммит разрешен для более полной утилизации памяти. однако киллер оказался слабоват, проблема вскрыта и решается средствами юзерспейса. >апогей современной софт-индустрии. Не апогей, а обычное средство мониторинга доступности ресурсов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

30. Сообщение от Аноним (17), 18-Май-20, 10:05	+/–
Спасибо, это заставило меня почитать про kernel signals, я даже не знал что такое есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

32. Сообщение от Annoynymous (ok), 18-Май-20, 19:08	+2 +/–
Да, до изобретения виртуальной памяти такой проблемы действительно не было. Но тогда, в 1977-м, были другие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #34

33. Сообщение от RNZ (ok), 18-Май-20, 20:27	+/–
vm.overcommit_ratio = 200 vm.overcommit_memory = 2 swapoff И все дела.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #35

34. Сообщение от пох. (?), 18-Май-20, 22:27	+1 +/–
эн, нет - в 78 виртуальная память была swap-backed, смысл ее виртуальности был в том чтобы дать программам память в рамках разделения ресурсов - "если ты все равно не занимаешь процессор, полежи на диске...зачеркнуто, для этого использовали барабан, заодно и память пригодится другим". В те времена такого катастрофического разрыва по скорости между оперативной памятью и внешним носителем не было. Чудеса с виртуальной памятью в /dev/zero, которой не соответствует никакое место ни на диске ни в памяти - это изобретение 90х, когда памяти стало уже много, а диски изрядно от нее отстали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

35. Сообщение от яч (?), 19-Май-20, 04:08	+/–
и хром не запустится
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #37

37. Сообщение от RNZ (ok), 21-Май-20, 12:40	+/–
> и хром не запустится Не правда. Запустится и будет работать, когда попытается аллоцировать больше чем есть - просто сразу сдохнет. Проверь сам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #40

38. Сообщение от Аноним (38), 23-Май-20, 13:12	+/–
> А если у меня его нет? Ну тогда сам создавай все это чем там тебе удобно. Ты не искал легких путей? Значит ломись через заросли или наслаждайся работой в стиле BSD386.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

39. Сообщение от Аноним (-), 23-Май-20, 13:15	+/–
> Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6 > пояснил, далеко не всегда работает. Щасливый пользователь нвидий? Если ядро на sysrq не реагирует - ему совсем поплохело. Или соотв. реакция запрещена, это настраивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #41

40. Сообщение от Аноним (-), 23-Май-20, 13:18	+/–
А если памяти мало - можно своп в zram сделать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #42

41. Сообщение от Аноним (1), 23-Май-20, 13:36	+/–
У счастливого пользователя амд ядро падает в панику при открытии хромиума. Упс, ещё хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

42. Сообщение от RNZ (ok), 23-Май-20, 16:53	+/–
> А если памяти мало - можно своп в 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема