LINUX.ORG.RU

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

 


1

1

Debian 9, Linux 4.9. Внезапно гуй перестал отвечать, курсор мертв много минут. Почему такое происходит в 2020? Почему из коробки дистибутивы не научились лечить такое?

Фото стола: https://i.ibb.co/8MzTJzq/P-20201129-072410.png

★★★

Ответ на: комментарий от Midael

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

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

hakavlad ★★★
() автор топика

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

burato ★★★★★
()
Ответ на: комментарий от burato

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

ноль реакции

hakavlad ★★★
() автор топика

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

bhfq ★★★★★
()

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

jura12
()
Ответ на: комментарий от jura12

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

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

hakavlad ★★★
() автор топика

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

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

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

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

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)

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

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

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

fornlr ★★★★★
()
Ответ на: комментарий от fornlr

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

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

ч. т. д.

anonymous
()
Ответ на: комментарий от Harald

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

На самом деле эту же проблему можно воспроизвести и с 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 гиг памяти.

hakavlad ★★★
() автор топика
Ответ на: комментарий от fornlr

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

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

hakavlad ★★★
() автор топика
Ответ на: комментарий от Harald

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

ChekPuk ★★★
()
Ответ на: комментарий от EXL

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

Завезли в 32.

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

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

papin-aziat ★★★★★
()

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

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

RedEyedMan666
()
Ответ на: комментарий от EXL

Потому что древний 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. Прогресс очевиден, хотя и недостаточно быстр.

hakavlad ★★★
() автор топика
Ответ на: комментарий от RedEyedMan666

Gentoo, ZRAM

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

hakavlad ★★★
() автор топика
Ответ на: комментарий от fornlr

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

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

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

hakavlad ★★★
() автор топика
Ответ на: комментарий от fornlr

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

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

anonymous
()
Ответ на: комментарий от fornlr

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

hakavlad ★★★
() автор топика
Ответ на: комментарий от Harald

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

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

Midael ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

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

anonymous
()
Ответ на: комментарий от hakavlad

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

RedEyedMan666
()
Ответ на: комментарий от jura12

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

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

anonymous
()
Ответ на: комментарий от hakavlad

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

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

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

kirill_rrr ★★★★★
()

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

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

Bootmen ☆☆☆
()
Ответ на: комментарий от kirill_rrr

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

Всё убить - это то, что делают неподготовленные пользователи на дистрибутивах с плохой обработкой нехватки памяти - делают 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

hakavlad ★★★
() автор топика
Ответ на: комментарий от kirill_rrr

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

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

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

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

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

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

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

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

hakavlad ★★★
() автор топика
Ответ на: комментарий от RazrFalcon

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

WitcherGeralt ★★
()
Ответ на: комментарий от hakavlad

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

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

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

#!/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 - позволяет контрлировать степень сжатия и скорость при потреблении памяти.

hakavlad ★★★
() автор топика
Последнее исправление: hakavlad (всего исправлений: 1)
Ответ на: комментарий от EXL

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

Im_not_a_robot ★★★★★
()
Ответ на: комментарий от hakavlad

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

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

ya-betmen ★★★★★
()

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

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

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

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

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 2)
Ответ на: комментарий от torvn77

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

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

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

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

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

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

hakavlad ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.