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

аппаратная проблема

Приглядись повнимательнее, на скриншоте типичнейший OOM зависон.

Вопрос риторический, я полагаю?

debian

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

Главный-то вопрос в этом:

Почему такое происходит в 2020? Почему из коробки дистибутивы не научились лечить такое?

а alt+ctrl+f1 чё говорит?

Честно на Армбиане несколько раз вешал, а вот с Gentoo аптаймами на десктопе набираю 40+ суток

а alt+ctrl+f1 чё говорит?

ноль реакции

на Армбиане несколько раз вешал

проблема решилась с началом использования earlyoom, верно?

я даже не знаю, что это

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

какие коробки? каждая фирма разрабатывает свой продукт и они плохо совместимы.
а винда разрабатывается как целостный продукт.
вообще дебиан не для гуи создан.

вообще дебиан не для гуи создан.

Проблема актуальна и для популярных десктопных дистров - Ubuntu, Mint, Manjaro. - Это их задача готовить дистр для комфортного изкоробочного использования. Если ванильное ядро не решает проблему, то задача дистроделов - довести сборку до ума и снабдить необходимыми костылями.

Потому что древний Linux вроде Debian’а до сих пор встаёт раком при нагрузке. Эту проблему начали решать лишь с полгода назад, после того как сам Торвальдс где-то обронил словечко о том, что дистрибутивы Linux сосут бибу при нехватке ресурсов. В Debian глядишь к 2030 году завезут сегодняшние новомодные технологии по обеспечению отзывчивости системы при нагрузке на неё.

Вообще интересно, насколько будут хороши systemd-oomd и oomctl в своей работе в сравнении с earlyroom?

В релизе Fedora 33 как раз earlyroom используется. И что я могу сказать – наконец-то Linux при нагрузке ведёт себя более-менее адекватно, как тот же macOS или Windows. А то прямо стыд и позор был. Как сейчас в этом твоём Debian’е.

Наконец-то дистростроители додумались выделять резерв памяти под системное UI (GNOME Shell) так, чтобы оно не уходило в своп если какое-нибудь приложение начнёт жрать RAM. Не прошло и 20 лет.

По тому что на серверах нет рандомного потребления ОЗУ.

А на десктопах разработчики берут ОЗУ с запасом.

В итоге проблемы нищебродов с малым количеством ОЗУ никого не волнуют.

отсутствие некупленных ТС-ом дополнительных плашек памяти - таки аппаратная проблема

В итоге проблемы нищебродов с малым количеством ОЗУ никого не волнуют.

«Обычный пользователь в Linux» => Нищеброд.

ч. т. д.

отсутствие некупленных ТС-ом дополнительных плашек памяти - таки аппаратная проблема

На самом деле эту же проблему можно воспроизвести и с 64 гиг памяти. Встречались юзеры с зависающими линуксами при 32 гиг памяти:

I have a problem that my system freezes completely when it runs out of memory

My problem is that the program Shotcut 2 consumes loads of memory, which in return crashes everything, despite having 32 GB of memory on the system

https://archived.forum.manjaro.org/t/solved-display-warning-message-or-kill-program-before-system-runs-out-of-memory/147635

Большой объем памяти сам по себе не спасает от зависаний при быстрых неограниченных утечках. С другой строны, корректная обработка нехватки памяти предотвращает зависания на машинах с 2 гиг памяти.

В итоге проблемы нищебродов с малым количеством ОЗУ никого не волнуют.

Вообще-то в Fedora Workstation проблема практически решена.

Да вы офигели господа! Какие плашки памяти? Система должна жить в заданных параматрах и справляться с переборщившими приложениями!

В релизе Fedora 33 как раз earlyroom используется.

Завезли в 32.

Наконец-то дистростроители додумались выделять резерв памяти под системное UI (GNOME Shell) так, чтобы оно не уходило в своп если какое-нибудь приложение начнёт жрать RAM.

Разговор про uresourced?

проблема практически решена

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

Debian 9, Linux 4.9. Внезапно гуй перестал отвечать, курсор мертв много минут.

Gentoo, ZRAM, немного тюнинга sysctl и ядра. 16 ГБ (было 8). Внезапных фризов нет. Своп заполнялся на 8 ГБ. Скорее всего, использование ZRAM минимизирует обращение к свопу (раздел на SSD и файл на HDD), поэтому фризов пока нет.

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

Только по умолчанию. Установкой трех демонов можно вылечить даже Дебиан 8. С работающим prelockd кейс из оп-поста не воспроизводится, киллер приходит быстро.

Эту проблему начали решать лишь с полгода назад

Да уж полтора года как решают в Федоре - с августа 2019 https://pagure.io/fedora-workstation/issue/98 - из этого обсуждения выросло включение по умолчанию swap on zram, earlyoom, uresourced. earlyoom и zram доступны с 2014 - при желании могли бы включить еще тогда.

В Debian глядишь к 2030 году завезут сегодняшние новомодные технологии по обеспечению отзывчивости системы при нагрузке на неё.

По крайней мере systemd-oomd ждем в Debian 12, остальное может так никогда и не включат.

Вообще интересно, насколько будут хороши systemd-oomd и oomctl в своей работе в сравнении с earlyroom?

Что ж, ждем ебилдов. Хотя различия как минимум такие - earlyoom работает уже сейчас и не требует специальных условий, завершает отдельные процессы, не требует свопа. systemd-oomd позволяет завержать отдельные юниты целиком при превышении в них давления, какие юниты позволено завершать нужно указывать явно. Если нужен десктопный демон, реагирующий на PSI, то nohang - неплохой вариант.

В релизе Fedora 33 как раз earlyroom используется. И что я могу сказать – наконец-то Linux при нагрузке ведёт себя более-менее адекватно, как тот же macOS или Windows.

Тестировал лично? Пользуешься Федорой?

Наконец-то дистростроители додумались выделять резерв памяти под системное UI (GNOME Shell) так, чтобы оно не уходило в своп если какое-нибудь приложение начнёт жрать RAM.

prelockd позволяет добиваться похожего эффекта, при этом не привязан к одному DE, cgroup2 и systemd. prelockd может быть запущен даже на Debian 8. В следующем релизе по умолчанию будут блокироваться либы не всех процессов, а только процессов, важных для DE.

Не прошло и 20 лет.

Прошло больше 20 лет. А вот 30 лет - не пошло.

В манджаро форуме вскрывалась тема включения киллера, но ни к чему не пришли: https://archived.forum.manjaro.org/t/include-out-of-memory-warnings-or-protection-by-default-e-g-earlyoom-or-nohang/128398. Одкако своп ставится на zram.

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

Garuda Linux - сборочка арча - включает по умолчанию swap on zram, nohang, prelockd, memavaild.

Все больше дистрибутивов включают swap on zram по умолчанию. Юзерспейсных киллеров включают по умолчанию Fedora, Endless OS, Garuda Linux. Прогресс очевиден, хотя и недостаточно быстр.

Gentoo, ZRAM

В кейсе из оп-поста как раз swap on zram, но в качестве нагрузки - почти несжимаемые данные.

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

Вообще-то текущее положение - небо и земля по сравнению с положением годовой давности, если говорить о дефолтах. Удар нанесен в трех направлениях - zram минимизиует обращение к медленным дискам, earlyoom предотвращает проблему радикальным способом в крайних случаях, а uresourced улучшает отзывчивасть при стрессах путем резервирования ресурсов для DE.

Почему это все еще не окончательное решение? Потому что на подходе systemd-oomd, и еще не рассмотрены prelockd и memavaild.

echo `yes`

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

echo yes

Это какой-то устаревший слабый стресс. bash медленно вырос до 2053 MiB VmRSS, ничего не произошло - https://i.ibb.co/DG9rprC/Screenshot-from-2020-11-29-15-39-48.png.

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

Вот это хохма. Спасибо, 100% так и будет. :)

Надо классику применять

:(){ :|:& };:

Примерно тот же результат. Откушало память, ресурс недоступен. Неограниченного потребления памяти не было, в конце закрыл терминал и бомба умерла. До своппинга даже не дошло.

Можно купить 32, 64, 128 и все равно повиснуть, если какая-нибудь кривая прога все это сожрет.

Я недавно постил пример - вальвовский компилятор шейдеров без задней мысли берет и выделяет по 2Гб на ядро. Очень весело на рузенах получается.

Автор решил посоревноваться с метапрогом в унылом пиаре?

не чё он не скажет – не до консолей в современном десктопе, приоритеты другие.

Автор решил посоревноваться с метапрогом в унылом пиаре?

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

Свопить конечно будет, но помирать не должно, ибо это уже намёк на страое ядро или дефолтные настройки. Но на дебиане такое бывает.

тогда на винфак дорога ему подобным

вообще дебиан не для гуи создан

вообще дебиан - универсальная операционная система, и существуют десктопные редакции, в которых проблему решить таки можно.

Потому что всё убить это не лечение.

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

У меня что то 2+2 не складываются. Почему рост памяти очень и очень плавный, а своп отрабатывает так, как будто ты на флопик или древнюю флешку свопишся? 220М это вообще за сколько времени? На хорошем диске это должны быть последние 2-3 секунды. Где 2-5 минут фризов и 5 гигов в свопе?

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

В Debian

Есть backports, хватит уже 4.2шить.

Почему из коробки дистибутивы не научились лечить такое?

Вы виндузятник? Ну чтоб обьснить проблему было проще.

Потому что всё убить это не лечение.

Всё убить - это то, что делают неподготовленные пользователи на дистрибутивах с плохой обработкой нехватки памяти - делают hard reset. А один из вариантов лечения - это завершить наменее нужный процесс для освобождения памяти для более важных процессов и для сохранения возможности управления системой. Другой вариант - это запрет выбрасывания файлового кэша кода и библиотек - это, что делает prelockd, например. - Это уменьшает I/O и улучшает отзывчивость как со свопом, так и без.

Убить всё - это то, что делают неопытные юзеры с 32 гиг памяти в 2020:

Unbelievable! I have no idea why my system with 32GB of memory is still haunted by this dumb issue. The ssh got completely unresponsive, even with a physical monitor and keyboard attached to the system, when this happens and the only solution to get back control is a hard reset. Man.. if anyone from upstream cares about this issue at least give user a prompt to kill the problematic process manually. Rendering the full system unresponsive like this is unacceptable.

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

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

Задачу я у себя решил, пора и пообсуждать.

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

Это своппинг несжимаемых данных в zram.

Где 2-5 минут фризов и 5 гигов в свопе?

Фриз мгновенно произошел, системный монитор замерз и не показал процесс дальнейшего своппинга.

ситуация похожа на очень и очень мутный тюнинг

Конечно, в качестве стресса здесь синтетика. Что не является оправданием для зависания.

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

Что за синтетика? Я как то гонял одну, знакомый написал. Что то в духе «выделить блок памяти - забить нулями - повторить несколько раз - прочитать всё, гонять пока массив не достигнет 20 гектар». На ноуте с 7,2 гб памяти и ссд оно падало с корректным «ошибка выделения памяти» спустя вполне адекватное время подвешивания системы, не повредив больше ничего. Никакого тюнинга кроме zram.

Что за синтетика?

В данном случае это:

#!/usr/bin/python3

from os import urandom

x = []
while True:
    x.append(os.urandom(999))

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

На самом деле использую скрипт - https://github.com/hakavlad/nohang-extra/blob/master/i-memhog - позволяет контрлировать степень сжатия и скорость при потреблении памяти.

Я бы сказал, что zram по умолчанию на половину-треть RAM гораздо полезней, чем всякие earlyoom.

Конечно, в качестве стресса здесь синтетика. Что не является оправданием для зависания.

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

Лампочка от винчестера мигает?

Если да, то скорее всего у тебя не повисание, а параличь ввиду исчерпания свободного ОЗУ.

Что делать:
Сейчас аппаратно сбрасывать комп.
В будущем:
Повесить на десктоп индикатор свободного ОЗУ и следить чтобы оно не забивалось.
Если приложения начинают проявлять признаки исчерпания ОЗУ то срочно нажимать Ctrl-Alt-F1, запускать htop и прибивать выжирающий память процесс, ну или наиболее объёмный процесс из ненужных процессов.
Ну понятно что так ты несколько раз убьёшь нечто нужное и подвесишь компьютер, но со временем научишся тому, что можно прибивать, а что нет.

П.С. Если ситуация запущена то htop может уже и незагрузится, тогда нажимаешь Alt-F2 и уже во второй консоли набираешь спасительную команду killall -u username_to_desktop

не повисание, а паралич

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

Сейчас аппаратно сбрасывать комп.

К счастью, у меня были включены sysrq magic keys, поэтому в перезагрузке необходимости не возникло.

Повесить на десктоп индикатор свободного ОЗУ и следить чтобы оно не забивалось.

Делал так года три-четыре назад. С тех пор появились варианты получше.