Линуксы зависли, реакции нет

отсутствие реакции на ввод и называют зависанием

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

Ещё ты можешь ударить по компу топором а потом жаловаться что оно не работает.

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

https://i.ibb.co/8MzTJzq/P-20201129-072410.png

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

echo yes
и смотри что дудет с федориным горем.

Процесс zsh сожрал 2 гига памяти, моргнула надпись out of memory что-то там и он был убит. Все это время гном работал без лагов, музыка тоже. Последняя федора.

и он был убит.

ИМХО убивать процессы автоматом не правильно,надо было все процессы отправить в сон и запустить окошко с приглашением администратора решить что дальше делать.

Все так. В каком дистрибутиве это есть из коробки?

Пока ни в каком, я это сейчас придумал.
Если никто не напишет патч, то это так и останется фантазией.

В принципе можно запускать не гуевое окно, а созданный админом скрипт, который сделает что админ в нём записал и отменит засыпание процессов, такой функционал реализовать проще чем вызов админа окошком, да и универсальнее это.

x.append(os.urandom(999) что именно делает? В питоне я полный ноль, но прежде чем отправить малину в жёсткий ребут, охота оценить насколько эта операция вообще в принципе может быть выполнена в почти гиге оперативки.

Почему такое происходит в 2020?

Ты сам ответил. Ковид, Карабах, негробунт. Линукс виснет. Год такой, високосный.

echo yes

RPi3, ядро 4.4, 400М zram, своп на ссд. Пережевал до своего двухгигового предела за 1,5 минуты, мышка фризилась, музыка ни разу не лаганула.

x.append(os.urandom(999)

добавляет в список 999 байт из /dev/urandom

и смотри что дудет с федориным горем.

Лучше делай так:

$ time tail /dev/zero
[2]    52736 terminated  tail /dev/zero
tail /dev/zero  0.69s user 4.27s system 97% cpu 5.111 total

И как только администратор придет с обеда, он решит все ваши проблемы.

Потому что не осталось свободной памяти для кэширования доступа к файлам. Используемые программами файлы обычно замаплены в память, даже разделяемые библиотеки. Фактически при отсутствии памяти для кэширования программы начинают выполняться прямо с накопителя, скорость выполнения уменьшается в 100500 раз.

Кстати, без свопа даже systemd-oomd может не помочь, см. https://man7.org/linux/man-pages/man8/systemd-oomd.8.html https://chrisdown.name/2018/01/02/in-defence-of-swap.html

Потому что не осталось свободной памяти для кэширования доступа к файлам при отсутствии памяти для кэширования программы начинают выполняться прямо с накопителя, скорость выполнения уменьшается в 100500 раз.

Все так, и этому есть подтверждение:

1. le9h.patch и его вариации: запртещает уменьшение Active(file) ниже заданного порога. Результат:

The attached kernel patch (applied on top of 4.18.5) that I’ve tried, almost completely eliminates the disk thrashing(the constant reading of executable(and .so) files on every context switch) associated with freezing the OS and so, with this patch, the OOM-killer is triggered within a maxium of 1 second when it is needed, rather than, without this patch, freeze the OS for minutes

– https://bugs.launchpad.net/ubuntu/+source/linux/+bug/159356/comments/89

2. prelockd блокирует библиотеки в памяти. Эффект аналогичен эффекту от вышеуказанного патча - ядерный киллер приходит быстро, восстановление после оом быстрое, отзывчивость при своппинге улучшается, см https://github.com/hakavlad/prelockd

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

Не даже, а прежде всего!

без свопа даже systemd-oomd может не помочь

На самом деле может, но для этого придется сильно снизить пороги для реакции. Впрочем, без свопа можно использовать earlyoom или nohang.

Они с инитами не могут разобраться до сих пор, не то что cutting-edge оом киллеры внедрять

cutting-edge system manager они же все-таки внедрили. То, что луддиты пытаются в реванш, не имеет большого значения. Да и вяленый с гномом по дефолту в Деб 10.

Детский сад.

rrr@raspberrypi:~$ time tail /dev/zero
tail: memory exhausted

real    1m7.889s
user    0m9.830s
sys     0m11.110s

arm7l, это 32 бита.

В это же время, самый длинный фриз длился 2 секунды. Теоретический предел производительности 130фпс.

rrr@raspberrypi:~$ glxgears 
144 frames in 5.0 seconds = 28.742 FPS
263 frames in 5.0 seconds = 52.084 FPS
390 frames in 5.0 seconds = 77.840 FPS
446 frames in 5.0 seconds = 89.009 FPS
256 frames in 5.5 seconds = 46.374 FPS
120 frames in 5.0 seconds = 23.987 FPS
218 frames in 5.0 seconds = 43.592 FPS
198 frames in 5.0 seconds = 39.514 FPS
169 frames in 5.0 seconds = 33.764 FPS
118 frames in 5.0 seconds = 23.575 FPS
110 frames in 5.1 seconds = 21.626 FPS
140 frames in 5.4 seconds = 26.010 FPS
150 frames in 5.0 seconds = 29.943 FPS
226 frames in 5.1 seconds = 44.638 FPS
137 frames in 5.4 seconds = 25.151 FPS
91 frames in 5.3 seconds = 17.151 FPS
283 frames in 5.0 seconds = 56.495 FPS
536 frames in 5.0 seconds = 107.111 FPS
439 frames in 5.0 seconds = 87.581 FPS
^C

rrr@raspberrypi:~$ ./test.py      
Traceback (most recent call last):
  File "./test.py", line 7, in <module>
    x.append(os.urandom(999))
NameError: name 'os' is not defined

Заменил os.urandom() на urandom(), работа пошла.

rrr@raspberrypi:~$ time ./test.py 
Traceback (most recent call last):
  File "./test.py", line 7, in <module>
MemoryError

real    26m5.570s
user    0m23.415s
sys     15m44.270s

Это был вообще шоколадный сценарий, потому что urandom у меня даёт что то около 4Мб/ сек, т.е. заполнение 4гб лимита за ~16,6 минуты. С такой медленной утечкой памяти, да ещё и без считывания уже записаных данных никаких заметных тормозов не возникло, память процесса стабилизировалась на 270-320М. Минут через 5 мне надоело смотреть на шестерёночки и я пошёл сёрфить дальше. Вытеснение половины памяти, доступной файерфоксу разумеется сделало процесс менее приятным, но ничего такого заоблачного.

Косяк возник когда был достигнут лимит, выдана ошибка и понадобилось вычистить процесс из памяти и свопа. Вот тогда система начала серьёзно тормозить и сёрфить уже стало нереально. Но вот уйти в консоль и прибить всё через htop я однозначно смог бы. Похоже разница между временем real и user+sys и является временим самовыпиливания питона. На момент начала теста в свопе лежало 1,3Гб, при обработке ошибки 3,75Гб. Т.е. далеко не 4Гб на питон, а всего 2,5-3. Почему? Хз. zram 2 диска по 200М при 942М доступной. Т.е. 42,5% или тот самый

Худший эффект (для системы и отзывчивости) достигается при больших объемах zram disksize.

Да, и вывод: если малина с гигом памяти ведёт себя лучше вашего 10гб ПК, то у вас определённо лютый косяк подсистемы свопа.

prelockd

Ух ты. Я так понял, ты автор? Респектище. Тоже хотел сделать, но не осилил. Попробую прикрутить к никсоси. Должно быть проще, учитывая, что у нас в одной директории находятся все файлы всех пакетов и только они)

Почему такое происходит в 2020?

Задай лучше вопрос, почему такое у тебя происходит. Тыж твой протухший дебиан не покупал.

Попробую прикрутить к никсоси. Должно быть проще

Дай знать если получится. Вопрос еще в регулярке в конфиге, чтоб захватывать в основном только исполняемые и либы.

У тебя неправильные пчёлы линукс.

И не говори. Не виснет, собака!

Сижу на Ubuntu 20.10 Ядро 5.8 Оперативку мой рабочий процесс выжирает под 98%, часто используется swap. Вроде не зависает намертво.

До этого на ноуте сидел 2012 года, там да, как только оперативка под 99% расхода, подтормаживал курсор, оно и ясно, активно писать/читать из swap там быстро не получалось.

Сейчас вылечилось установкой 16Gb Ram и диск NVME со скоростью чтения 3100/записи 1500 и когда система активно свапирует - тормозов практически нет

А так, если система задыхается по ram, работает со swap, а диск медленный - то тут наверное два выхода - вовсе зависнуть, подтормаживать или сразу уйти в ребут.

Наверное этим можно управлять выбрав соответствующий планировщик в ядре.

Так и будет решаться каждый выпуск… окончательно.

окончательным решением будет прием в mainline патча le9*.patch https://github.com/hakavlad/le9-patch

Потому что древний Linux вроде Debian’а до сих пор встаёт раком при нагрузке

Вот тут не встает - как раз дебиан олдстейбл используется - https://github.com/hakavlad/le9-patch

Можешь попробовать, а также можешь помочь ребейснуть для новых ядер.

Потому что древний Linux вроде Debian’а до сих пор встаёт раком при нагрузке

Дебиан с ядром linux-xanmod не встает колом, если выставить vm.clean_min_kbytes=200000 (le9 патч принят недавно в это ядро).

https://forum.xanmod.org/thread-4102.html

Не то железо, не те дрова, не тот дистр.

У меня такое было, когда начал сыпаться диск.

Зуб даю, это не просто «утечка» из-за 100+ вкладок в Файрфоксе — это фэйл подсистемы освобождения памяти в ядре. Они там что-то сломали в районе 5.9 или даже раньше. Ловил такое на 32 гигах памяти. В последних 5.10 по ходу, начали чинить - полных фризов давно не было, если пролетает «BUG:» в syslog’е, то хоть работать продолжает.

тест был с 4.9

Честно говоря, у меня система адекватней всего ведет себя с memory_overcommit=2, увеличенным cache_pressure и уменьшенным swappiness.

Это — фигня, если можно по ssh зайти и прибить иксы. А вот иногда реально бывает бесящая история, когда намертво зависает система — даже по ssh не войдешь (естественно, софтовый вотчдог при этом тоже зависает, а аппаратных на попсовых материнках, к сожалению, не завезли).

А, еще меня напрягает то, как отваливается система при высокой дисковой активности, причем, пофиг, что активен совершенно левый диск! Не спасает даже то, что система стоит на SSD, помойка на отдельном винте, а distfiles — на другом!

В общем, уже 2021 год, а 12309 так и не победили (говорят, в pf-ядре все ОК, но как-то не хочется кастомное ядро проверять).

А разве в мастдайке работает ctrl+alt+Fx и ctrl+alt+backspace? ЕМНИП, в бубунте по умолчанию это отключено. В дебиане тоже запросто может быть. Кто вообще предскажет, что там в этих мастдайках творится?

Хотя, только что решил провести эксперимент. Таки завис. Ядро 5.12.

Какой эксперимент?

tail /dev/zero. Система зависла. До этого я пытался перекодировать в ffmpeg тяжелое видео. С overcommit_memory=1 и cache_pressure = 50(или около того) система зависала и early-oom никак не помогал. После того, как я поднял cache_pressure, уменьшил swappiness и выставил overcommit_memory в 2 система зависать перестала. А с tail /dev/zero это не сработало. Правда, эксперименты с ffmpeg я проводил на ядре 4.19 с rt патчем. А сейчас я загрузился с ядром 5.12.

Теперь, на этом же ядре, я установил overcommit_memory в 1 и запустил earlyoom. Система подвисла на несколько секунд, но потом earlyoom прибил процесс.

Кстати, почему не приходит или запаздывает oom-killer (хоть ядерный, хоть юзерспейсный)? Из-за того, что некоторые страницы памяти можно выгрузить только записави их предварительно на диск?

У тебя забита битком память и своп. А виноват кто-то?

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

Отличный вопрос. Об этом можно написать статью - с теорией и пруфами.

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

В норме либы кэшированы, и тормозов нет.

Как решить проблему?

• prelockd - демон, блокирующий в памяти либы и бинари
• le9 patch - может вызывать киллера при невозможности сохранить кэш путем своппинга анонимки.

почему не приходит или запаздывает oom-killer (хоть ядерный, хоть юзерспейсный)?

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

Как решить проблему?

systemd-oomd

Тебе задачу в свои 10 гигов пропихнуть, или юзерспейс-оом пообсуждать?

1. сохранять отзывчивость гуя несмотря ни на что - гуй критически важен, задержки недопустимы
2. задачу выполнить желательно, но не тогда, когда в скрипте неконтролируемая утечка

Проблему systemd-oomd убьет вашу сессию (внимание пользователям спинов Fedora 34) уже исправили?

Высокое использовние цп исправили?

ВСЁ ВЕРНО

By design. Неосиляторы systemd-run должны страдать.

потому что в 2020 ехал докер через докер, а на твой десктоп всем положить.

На моей малинке 3, systemd-oomd ест 0.3% CPU.