forum.opennet.ru - "Выпуск уведомителя о нехватке ресурсов psi-notify 1.0.0" (40)

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

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

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

Оглавление

Я что-то заметил, 5 4 как-то иначе реагирует на кончившуюся память, не как 4 19 , Аноним (1), 21:53 , 17-Май-20, (1) +6

Какой ужас Почему не пользуетесь обработчиком нехватки памяти в пространстве по, tr (?), 22:08 , 17-Май-20, (2) –5

Очень часто случается такое, что ядро реагирует только на sysrq b, тут уж как по, Аноним (1), 22:25 , 17-Май-20, (6) +4

Они спасают от нехватки памяти, что подтверждено многочисленными отзывами Они к, tr (?), 22:32 , 17-Май-20, (8) +1

Так в том и дело, что память будет исчерпана целиком и полностью совершенно внез, Аноним (1), 22:36 , 17-Май-20, (10) +1

Ничего подобного, память исчерпывается с ограниченной скоростью Даже без свопа , tr (?), 22:45 , 17-Май-20, (12) –1

Слишком абстрактно Я когда-то тестировал память в четырёхканальном режиме, там , Аноним (1), 22:58 , 17-Май-20, (14)

Наоброт, предоставлена конкретика обработчик нехватки памяти nohang обрабатывае, tr (?), 23:21 , 17-Май-20, (18)

Синтетика 8230 Видеокарта не используется, опять же, а ведь именно видеокарта , Аноним (1), 23:34 , 17-Май-20, (20)

Синтетика как раз позволяет моделировать нужное поведение, такое как быстрое пог, хз2 (?), 04:11 , 18-Май-20, (23)

Можно замечательно сымитировать создав файл в tmpfs Тоже всё зависнет Но когда, Аноним (1), 05:47 , 18-Май-20, (25)

Всё так Ни ядро, ни юзерспейсные киллеры не разруливают переполение tmpfs Впроч, хзъ (?), 06:40 , 18-Май-20, (26)

Пока сделал вывод, что не нужно пытаться перейти на tty, если иксы залагали по, Аноним (1), 22:34 , 17-Май-20, (9)

Но ведь лучшая практика - избегать убийства сессии, чтоб не убивать все процессы, tr (?), 22:40 , 17-Май-20, (11)

А кто им даст такую возможность Даже если приложение написано в лучшем стиле ре, Аноним (1), 22:48 , 17-Май-20, (13)

1 Автор демона 2 Админ, который установит и запустит демона Реалтайм не обязат, tr (?), 23:01 , 17-Май-20, (15) –3

Пардон, за десятки миллисекунд Это у ядерного счет идет на секунды, минуты и ча, tr (?), 23:05 , 17-Май-20, (16) +1
Очень даже обязателен Реалтайм процессы не выделяют память и ни от чего не зави, Аноним (1), 23:30 , 17-Май-20, (19)

В современном гном3 и циннамоне каждое приложение запускается в отдельной группе, хз2 (?), 03:55 , 18-Май-20, (22)

А если у меня его нет Зачем же так категорично То, что для вас Реалтаймовость , Аноним (1), 05:45 , 18-Май-20, (24)

Тогда ССЗБ Большинство дистров поставляются с ним Зачем вы выбрали дистрибутив, хзъ (?), 07:04 , 18-Май-20, (27) –2
Ну тогда сам создавай все это чем там тебе удобно Ты не искал легких путей Зна, Аноним (38), 13:12 , 23-Май-20, (38)

Alt SysRq F пробовал , null (??), 22:22 , 17-Май-20, (4) +1

Что за кнопка SysRQ, Аноним (17), 23:07 , 17-Май-20, (17)

https static thegeekstuff com wp-content uploads 2008 12 sysrq-key-300x199 jpg, DiabloPC (ok), 00:48 , 18-Май-20, (21)

Спасибо, это заставило меня почитать про kernel signals, я даже не знал что тако, Аноним (17), 10:05 , 18-Май-20, (30)

Ctrl Alt SysRq F - вызовет ядерный OOM-киллер через sysrq, от этого ядру н, ilyafedin (ok), 22:23 , 17-Май-20, (5) +1

Пользуюсь достаточно часто Стараюсь не доводить, конечно, но всякое случается , Аноним (1), 22:27 , 17-Май-20, (7)

Щасливый пользователь нвидий Если ядро на sysrq не реагирует - ему совсем попло, Аноним (-), 13:15 , 23-Май-20, (39)

У счастливого пользователя амд ядро падает в панику при открытии хромиума Упс, , Аноним (1), 13:36 , 23-Май-20, (41)

vm overcommit_ratio 200vm overcommit_memory 2swapoffИ все дела , RNZ (ok), 20:27 , 18-Май-20, (33)

и хром не запустится, яч (?), 04:08 , 19-Май-20, (35)

Не правда Запустится и будет работать, когда попытается аллоцировать больше чем, RNZ (ok), 12:40 , 21-Май-20, (37)

А если памяти мало - можно своп в zram сделать, Аноним (-), 13:18 , 23-Май-20, (40)

Так и делаю где требуется zramctl NAME ALGORITHM DISKSIZE DATA COM, RNZ (ok), 16:53 , 23-Май-20, (42)

Осведомителя выпустили , Повидло19 (?), 22:22 , 17-Май-20, (3) –2
апогей современной софт-индустрии вместо того, чтобы разобраться с текущим прило, СеменСеменыч777 (?), 09:02 , 18-Май-20, (28)

Что сказать-то хотел, умник оверкомммит разрешен для более полной утилизации па, Секция (?), 09:48 , 18-Май-20, (29) +2
Да, до изобретения виртуальной памяти такой проблемы действительно не было Но то, Annoynymous (ok), 19:08 , 18-Май-20, (32) +2

эн, нет - в 78 виртуальная память была swap-backed, смысл ее виртуальности был в, пох. (?), 22:27 , 18-Май-20, (34) +1

Сообщения [Сортировка по ответам | 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.ru/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.ru/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 | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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.ru/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.ru/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