Опубликован выпуск программы psi-notify 1.0, которая может предупредить при появлении в системе конкуренции за ресурсы (cpu, память, ввод/вывод) для того, чтобы предпринять действия, прежде чем система замедлится. Код открыт под лицензией MIT...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52976
Я что-то заметил, 5.4 как-то иначе реагирует на кончившуюся память, не как 4.19. Иксы больше не зависают, курсор продолжает двигаться (с лагами), но запустить или убить ничего нельзя (хоткей с xkill бы работал, эх). Но в то же время у меня на 5.4 зависла консоль на tty, чего с 4.19 никогда не случалось. В логах после хардресета посмотрел, ядро реагировало на magic key, но этого с хоста было не увидеть никак. Вывод: раньше было лучше -- ядро опять сломали.
>после хардресетаКакой ужас. Почему не пользуетесь обработчиком нехватки памяти в пространстве пользователя?
Вот устаревщий обзор: https://www.opennet.dev/tips/3116_oomkill_memory_earlyoom_noh...
В 2020 некоторые дистрибутивы уже включают их по умолчанию. Завершение процесса по SIGTERM - это лучше, чем hard reset.
Очень часто случается такое, что ядро реагирует только на sysrq+b, тут уж как повезёт. Это очень болезненно, хотя бы потому, что все диски смонтированы с data=writeback. В норме то реагирует на sysrq+f и всё сразу в порядке (не для убитого процесса). В крайнем случае sysrq+e (отправить sigterm всем процессам) должен спасти. Но, если никакие команды кроме b не срабатывают, всё очень плохо. Тут они срабатывали, да видеодрайвер, похоже, завис.Юзерспейсные обработчики ни от чего не спасут, памяти нужно много и внезапно: порядка 80% на линковку, например.
>Юзерспейсные обработчики ни от чего не спасутОни спасают от нехватки памяти, что подтверждено многочисленными отзывами. Они как раз и предотвращают состояние, когда все запущено и реагировать трудно, ибо реагируют тогда, когда память еще не полностью исчерпана.
Так в том и дело, что память будет исчерпана целиком и полностью совершенно внезапно. Когда тут реагировать? Отдельное приключание, если у нас ещё есть своп, который можно невозбранно исчерпать не менее внеазпно.
>целиком и полностью совершенно внезапноНичего подобного, память исчерпывается с ограниченной скоростью. Даже без свопа при запуске многопоточного stress скорость исчерпания ограничена десятком гигабайт в секунду.
Юзерспейсные обработчики проверяют состояние памяти до десяти раз в секунду. Этого вполне достаточно для реакции, даже если память пожирается очень быстро.
Например:
https://youtu.be/UCwZS5uNLu0 – running multiple fast memory hogs at the same time without swap space.
Тем более при наличии свопа нет проблемы вовремя среагировать.
Слишком абстрактно. Я когда-то тестировал память в четырёхканальном режиме, там получалось что-то в районе 60гб/с. Естественно, память очень медленная даже в идеальных условиях, но на вероятность исчерпать последние проценты и повесить систему это не влияет.CONFIG_HZ_PERIODIC=y
CONFIG_HZ_1000=y
CONFIG_HZ=1000С такими параметрами ядро может реагировать достаточно долго даже на magic-key что уж там говорить про какие-то пользовательские приложения. С nohz у меня лаги были, а так там вроде можно и больше 1000 раз (с nohz).
>Слишком абстрактно.Наоброт, предоставлена конкретика: обработчик нехватки памяти nohang обрабатывает нехватку памяти при циклическом запуске трех потоков tail /dev/zero.
Вот еще демо: nohang обрабатывает восьмипоточный stress при наличии свопа: реагирует на конкуренцию за память, тем самым прекращая заморозку десктопа: https://youtu.be/Y6GJqFE_ke4
Синтетика… Видеокарта не используется, опять же, а ведь именно видеокарта (и отображение её памяти в оперативку) основная причина фризов, в том числе и на венде.
Синтетика как раз позволяет моделировать нужное поведение, такое как быстрое поглощение памяти в примере выше. В большинстве же случаев утечки происходят не очень быстро.>Видеокарта не используется
Проблемы с дровами и зависания от проблем с видюхой - ЭТО ДРУГОЕ, это не связано с нехваткой памяти. От проблем с видюхой машины виснут и когда памяти много свободной.
Можно замечательно сымитировать создав файл в tmpfs. Тоже всё зависнет. Но когда это миллионы файлов (практическое применение), всё зависнет гораздо надёжней.
Всё так. Ни ядро, ни юзерспейсные киллеры не разруливают переполение tmpfs.Впрочем, можно научить юзерспейсных обработчиков очищать tmpfs от части крупнейших файлов в избранных директориях.
Впрочем, хорошая практика - это ограничение макс размера tmpfs.
Пока сделал вывод, что не нужно пытаться перейти на tty, если иксы "залагали" подобным образом от нехватки памяти. Если sysrq+f не помогает, лучше жать sysrq+e и молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на диске. Потому что после перехода на tty всё точно окончательно зависнет (баг в kms?). Почему всё зависло в тот раз и без иксов (они даже не были запущены), я не знаю, видимо опять этот баг в kms.
>молиться, чтобы иксы сейчас же умерли -- потеря сессии со всеми документами менее болезнена, чем потеря данных на дискеНо ведь лучшая практика - избегать убийства сессии, чтоб не убивать все процессы сессии. Лучшая практика - завершить минимум процессов, по возможности через SIGTERM. Лучшие из обработчиков нехватки памяти умеют тонко приоретизировать выбор процесса, по возможности избегая убийства всей сессии с потерей несохраненных данных.
> Но ведь лучшая практика - избегать убийства сессии, чтоб не убивать все
> процессы сессии. Лучшая практика - завершить минимум процессов, по возможности через
> SIGTERM. Лучшие из обработчиков нехватки памяти умеют тонко приоретизировать выбор процесса,
> по возможности избегая убийства всей сессии с потерей несохраненных данных.А кто им даст такую возможность? Даже если приложение написано в лучшем стиле реалтайм систем... И никогда не выделяет память динамически (и ничего не запускает -- с чем запустили, с тем и живём), если оно висит в фоне, ему времени может и не перепасть. Тут даже magic key реагирует с задержкой в пару минут. А уж если led-индикаторы на клавиатуре не реагируют, это надёжный признак того, что мы приплыли. На удивление, sysrq+b всё равно работает. Но это ничем не отличается от хардресета.
>А кто им даст такую возможность?1. Автор демона.
2. Админ, который установит и запустит демона.
>приложение написано в лучшем стиле реалтайм систем
Реалтайм не обязателен. Достаточного одного mlockall() - это уже дает фору демону, особенно при своппинге.
>И никогда не выделяет память динамически
Для парсинга значений oom_score процессов нужно совсем немнго памяти, и делается это за десятки миллисекунд.
>ему времени может и не перепасть
Такое возможно, если специально выставить неадекватные пороги - то есть указать демону реагировать лишь когда память совсем исчерпана, близка к нулю. На самом деле время практически всегда всегда перепадает, и проблем с реакцией нет, что и продемонстрировано здесь: https://youtu.be/UCwZS5uNLu0
>даже magic key реагирует с задержкой в пару минут
Правильно, потому что ядерный киллер сломан. Триггеринг киллера зачастую приводит лишь к purging GPU memory вместо убийства жиробаса. В то время как юзерспейсный киллер за десятки секунд находит жертву и отправляет сигнал.
>за десятки секундПардон, за десятки миллисекунд. Это у ядерного счет идет на секунды, минуты и часы: https://www.opennet.dev/opennews/art.shtml?num=51231
Очень даже обязателен. Реалтайм процессы не выделяют память и ни от чего не зависят. Ведь именно с этим и возникает проблемы -- памяти не выделить, если её уже нет.>указать демону реагировать лишь когда память совсем исчерпана, близка к нулю
В целом, обычная ситуация -- 95% занятой памяти вовсе не означает, что нам когда-нибудь потребуются оставшиеся 5%. Я проверял, через 20+ часов работы памяти оставалось 4%.
Лучше заставить остальные приложения реагировать подобно хромиуму: ронять свои лишние зажравшиеся процессы самостоятельно. У файрфокса с этим большие проблемы. Но я не понимаю, как заставить ядро грохать фф (весь его неймспейс). И даже не вижу штатного способа запускать браузер в другой контрольной группе (все иксовые приложения в группе /xdm). Только почему хромиум справляется и без костылей? Сам себе выставляет процессам вкладок повышенный вес для oom-killer (фф этого не делает) и без задержек прибивает лишних? Но правда хромиум идёт с суидной рутовой песочницей, что тоже не очень приятно. Может быть в этом дело?
>штатного способа запускать браузер в другой контрольной группеВ современном гном3 и циннамоне каждое приложение запускается в отдельной группе.
В прочих окружениях: `systemd-run --user --scope foo` запуск в отдельной группе.
>Реалтайм процессы не выделяют память
Это ложь. Реалтаймовость процесса - это лишь приоритет по ЦПУ. Любому процессу можно дать реалтаймовость - и это не приведет к прекращению выделений памяти.
>суидной рутовой песочницей, что тоже не очень приятно. Может быть в этом дело?
Разумеется, для изменения oom_score_adj нужен рут.
>Но я не понимаю, как заставить ядро грохать фф (весь его неймспейс)
Зачем же весь? Лучше отдельные вкладки прибивать, то есть повышать приоритет убийства для процессов Web Content - с этим как раз отлично справляются юзерспейсные обработчики.
>и без задержек прибивает лишних?
Ядерный киллер не может прибивать без задержек, юзерспейсные киллеры - могут.
>systemdА если у меня его нет?
>Это ложь. Реалтаймовость процесса - это лишь приоритет по ЦПУ. Любому процессу можно дать реалтаймовость - и это не приведет к прекращению выделений памяти.
Зачем же так категорично? То, что для вас "Реалтаймовость процесса - это лишь приоритет по ЦПУ." вовсе не значит, что так и есть.
>повышать приоритет убийства для процессов Web Content - с этим как раз отлично
Почему он не может это делать сам?
>Ядерный киллер не может прибивать без задержек, юзерспейсные киллеры - могут.
Ну, хорошо, если так. Я ещё не видел ни одного юзерспейсного приложения, остававшегося живым и отвечающим в таких условиях.
>А если у меня его нет?Тогда ССЗБ. Большинство дистров поставляются с ним. Зачем вы выбрали дистрибутив без системного менеджера?
>Почему он не может это делать сам?
Почему же не может? Может, но не хочет. Или его разработчики не хотят этого.
>Я ещё не видел ни одного юзерспейсного приложения, остававшегося живым и отвечающим в таких условиях.
В каких таких? Чтобы такие условия не наступали как раз и существуют юзерспейсные обработчики - они пытаются предотвратить livelock своевременно, до того, как станет поздно, пока доступная память не исчерпана полностью и еще есть пространство для маневра.
> А если у меня его нет?Ну тогда сам создавай все это чем там тебе удобно. Ты не искал легких путей? Значит ломись через заросли или наслаждайся работой в стиле BSD386.
Alt+SysRq+F пробовал ?
Что за кнопка SysRQ
https://static.thegeekstuff.com/wp-content/uploads/2008/12/s...
Спасибо, это заставило меня почитать про kernel signals, я даже не знал что такое есть.
Ctrl + Alt + SysRq + F - вызовет ядерный OOM-киллер через sysrq, от этого ядру не отвертеться. Разумеется, если включен kernel.sysrq.
Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6 пояснил, далеко не всегда работает.
> Пользуюсь достаточно часто. Стараюсь не доводить, конечно, но всякое случается. В #6
> пояснил, далеко не всегда работает.Щасливый пользователь нвидий? Если ядро на sysrq не реагирует - ему совсем поплохело. Или соотв. реакция запрещена, это настраивается.
У счастливого пользователя амд ядро падает в панику при открытии хромиума. Упс, ещё хуже.
vm.overcommit_ratio = 200
vm.overcommit_memory = 2
swapoffИ все дела.
и хром не запустится
> и хром не запуститсяНе правда.
Запустится и будет работать, когда попытается аллоцировать больше чем есть - просто сразу сдохнет.
Проверь сам.
А если памяти мало - можно своп в zram сделать
> А если памяти мало - можно своп в 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
Осведомителя выпустили?
апогей современной софт-индустрии.
вместо того, чтобы разобраться с текущим приложением (например ограничить его аппетит. или прекратить его использование. или свопнуть), давайте сперва отстрелим самое жирное через ядро, потом сделаем то же от юзера, потом заведем спец.подсистему в ядре !
Что сказать-то хотел, умник? оверкомммит разрешен для более полной утилизации памяти. однако киллер оказался слабоват, проблема вскрыта и решается средствами юзерспейса.>апогей современной софт-индустрии.
Не апогей, а обычное средство мониторинга доступности ресурсов.
Да, до изобретения виртуальной памяти такой проблемы действительно не было.Но тогда, в 1977-м, были другие.
эн, нет - в 78 виртуальная память была swap-backed, смысл ее виртуальности был в том чтобы дать программам память в рамках разделения ресурсов - "если ты все равно не занимаешь процессор, полежи на диске...зачеркнуто, для этого использовали барабан, заодно и память пригодится другим". В те времена такого катастрофического разрыва по скорости между оперативной памятью и внешним носителем не было.Чудеса с виртуальной памятью в /dev/zero, которой не соответствует никакое место ни на диске ни в памяти - это изобретение 90х, когда памяти стало уже много, а диски изрядно от нее отстали.