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

Этот умник небось тоже своп отключил. А зачем своп, когда у меня 32 гига, да? Со свопом и нормальным оом килером систему подвесить невозможно.

так это не 12309, оп ничего не копирует

12309 - это при копировании на медленный носитель

Со свопом и нормальным оом килером систему подвесить невозможно.

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

while true; do setsid tail /dev/zero; done

Внимание, запускаю на малинке 3!

$ while true; do setsid tail /dev/zero; done
[1]    5351 killed     systemd-run --scope --user zsh -i

Это может таки быть и аппаратной проблемой. Проявлялись рандомные фризы системы на Ryzen 1700. На двух машинах. Пофиксилось после гарантийной замены процессоров на более новую ревизию и запрет в BIOS какого-то из последних энергоэффективных режимов.

https://wiki.gentoo.org/wiki/Ryzen#Segmentation_faults_during_compilation

Баг может проявляться не только при компиляции, но и просто рандомно от 5 раз в день до 1 раза в месяц.

Насчет Intel не знаю, но возможно и там что-то такое встречалось.

tail /dev/zero
fish: Job 1, 'tail /dev/zero' terminated by signal SIGKILL (Forced quit)

Думало оно при этом минуту или две. В это время компьютером нельзя было пользоватся, индикатор нагрузки на диск все время горел. Свап есть, ядро 5.12.14

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

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

Никакая, смиритесь. Возможно мак про на максималках под макосью и смог бы теоретически, но там проблемы с софтом и дизайном.

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

Да вся это тема нытьё «ну дайте мне уже идеальную систему, которая лучше меня разберётся с управлением задачами, ну 2021 год же уже, что вам, сложно угадать чего я хочу?»

Полагаю значимого опыта использования мака ты не имеешь?

Если бы на макоси можно было свободно конфигурировать панели рабочего стола, то даже я бы увидел это на скриншотах.

Аксиома «борцун — это не только ценный мех, но ещё и БАЛАБОЛ» опять подтвердилась.

А сам то… Ну покажи мне прилично настроенный стол в макоси. Нет? Тогда не надо говорить о комфорте.

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

Ну купи себе мак да настрой, в чём проблема-то?
(Ну и смешивать отсутствие лагов и прокрастинацию путём настройки панелей в i3/openbox под одним термином «комфорт» не нужно)

Нет нужно. Кто то упарывается в плавность и отзывчивость до неадекватности и называет это «комфортом», а о других составляющих почему то забыл. Так что мне мешает завялять, что комфорт на этом мусоре невозможен пока панели не приведены в удобный для меня вид? И почему я должен терпеть такие тупые косяки?

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

Неть, не нужно.

Любой взрослый и адекватный человек понимает, что возня с панельками это именно прокрастинация.

А вот плавность и отзывчивость это настоящая характеристика комфорта.

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

Нужно иметь очень неслабую коррапцию в своём сознании и модели мира, если тебе не нравится сохранение отзывчивости системы даже в сложных условиях нехватки ОЗУ.

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

У вас просто юзерспейсного киллера нормального не было.

Нехватка оперативной памяти — это аппаратная проблема. Решается походом в магазин.

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

Закидывать неправильно работающий код мощным железом — неправильно.

Любой взрослый и адекватный человек понимает, что возня с панельками это именно прокрастинация

Нет. Если настройка панельки реально улучшает эргономику, то это не прокрастинация.

Даже если твои маки вешаются на ура, не означает, что в линуксе не надо обеспечивать отзывчивость хотя бы

С этим согласен.

Нет. Если настройка панельки реально улучшает эргономику, то это не прокрастинация.

Прокрастинация. Ментальная мастурбация.

Alt-SysRq-F

У меня всё нормально. У тебя кривой оом киллер.

какие лимиты используешь? сколько памяти на машине?

systemd-oomd, как у тебя.

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

Какой именно своп? только на zram? каков swappiness? какая ос и де? Каковы объемы памяти и свопа?

               total        used        free      shared  buff/cache   available
Mem:           7,7Gi       1,2Gi       5,4Gi       290Mi       1,1Gi       6,0Gi
Swap:           19Gi          0B        19Gi

swapon
NAME       TYPE      SIZE USED  PRIO
/dev/sda3  partition 3,7G   0B    -2
/dev/zram0 partition 3,9G   0B 32767
/dev/zram1 partition 3,9G   0B 32767
/dev/zram2 partition 3,9G   0B 32767
/dev/zram3 partition 3,9G   0B 32767

vm.dirty_background_bytes=2048000
vm.dirty_bytes=4096000
vm.swappiness=10
vm.overcommit_memory=1
vm.vfs_cache_pressure=300

Система — арч, DE — пятые кеды.

vm.swappiness=10

Это одна из проблем. Если своп на быстром устройстве, то рекомендуется высокий swappiness. Взгляните сюда https://github.com/hakavlad/le9-patch/issues/4#issuecomment-880720329 и прочитайте новейшую документацию к swappiness.

/dev/sda3 partition 3,7G 0B -2

Это вторая проблема. Зачем сочетать zram с подкачкой на более медленном устройстве?

Я когда-то пробовал отключать свап на диске, когда был активирован zram. Зависания случались чаще. И по идее, у zram сейчас выше приоритет, разве нет?

Сейчас попробую увеличить.

После увеличения swappiness система тоже зависла. Но не сразу, как со старым значением.

что возня с панельками это именно прокрастинация.

А вот плавность и отзывчивость это настоящая характеристика комфорта.

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

достигается очень просто при этом.

Да, очень просто. Всего лишь надо убить всё, что требует ресурсов и времени. Желательно превентивно, ещё до того как оно что то потребует.

не нравится сохранение отзывчивости

Мне не нравится не сохранение отзывчивости, а цена и методы которыми это предлагается достичь.

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

для несуществующей проблемы

Толсто.

убить всё, что требует ресурсов и времени. Желательно превентивно

Толсто.

почему для этого никто не пытается воспользоваться механизмом изоляции и лимитов?

Толсто.

Толсто.

Да, есть такое. Но тонкий подход требует слишком много времени.

Почему название темы похоже на вступление из песни БГ?

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

Как и 12309 или например мой фаворит последних месяцев это подвисание самба-шары при обрыве впн-соединения, которое не даёт системд нормально выключить систему. (но это конечно несуществующие проблемы, ведь у тебя их не было; вот панельку подвинуть на пару пикселей это да пробелема проблем).

Один из типовых случаев в моей практике это жирный запрос к БД. И это на системах с 16-32+ ОЗУ.

Всего лишь надо убить всё, что требует ресурсов и времени

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

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

Совершенно банальное разспидолбайство.
Причём много где уже sshd как раз под этими лимитами и живёт.
И, внезапно, мы вот тут берём и пользуемся этими механизмами.

Т ак может надо починить, а не городить костыль?

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

+100500

Это явный косяк в поведении системы, важные для отзывчивости компоненты вытесняться не должны никогда.

При этом ядро вовсе не обязано гарантировать адекватное поведение каждого кривого приложения. Система должна быть гарантированно защищена от такого.

Я поражаюсь людям которые этого не понимают.

Как и 12309 или например мой фаворит последних месяцев это подвисание самба-шары при обрыве впн-соединения, которое не даёт системд нормально выключить систему.

Свой 12309 я уже побеждал года 3-4 назад, на 70% сменой диска, на 25% тюнингом и на 5% просто забив на незначительные лаги. Можно было и дальше бодаться, выигрывая с каждым новым потраченным днём всё меньше секунд на час работы.

Где ты там убивание нашёл?

Вся эта тема про oomd.

и пользуемся этими механизмами.

Другими, я что то тут не видел ничего про cgrops и дисковые приоритеты.

«важные компоненты» это расплывчато. Виджет погоды на панели это важный, или можно вытеснить? А кто будет их определять и помечать как невыгружаемые?

Даже в лютом своп-трешинге вполне можно переключиться в консоль, залогиниться и запустить пару команд типа killall или htop, причём без всякого дополнительного тюнинга. Проблема скорее в том, что они получат жутко маленькую долю диска на свой запуск, а уж пару метров оперы ядро им выделит легко.

Однако, я накатил этот патч на федорино ядро (5.12.17-200.fc33.x86_64). Это был небольшой квест, так как инструкции по сборке ядра у них или устарелые или просто кривые. Но в конце концов все ядрёные пакеты собрались и установились. Я сделал vm.clean_low_kbytes=524288 и vm.clean_min_kbytes=0 по-умолчанию. Перезагрузился в это ядро, запустил обычный тест tail /dev/zero, и моя система повисла намертво. Даже SysRq не работал. На непропатченом ядре tail /dev/zero, как и ожидается, не зависает.

Что я заметил, на непропатченом ядре занятая память растёт до 100% (16G), и потом начинает заполнять swap до 90%, после чего earlyoom прибивает процесс. На пропатченом ядре, занятая память растёт до 100%, и система зависает.

линуксы зависли и никакой реакции от сообщества, куда смотрит власть

сделал vm.clean_low_kbytes=524288 и vm.clean_min_kbytes=0 по-умолчанию. Перезагрузился в это ядро, запустил обычный тест tail /dev/zero, и моя система повисла намертво

УМВР

https://www.youtube.com/watch?v=c5bAOJkX_uc

https://youtu.be/1uhcZwuvXLI

>> vm.swappiness=10
> Это одна из проблем. Если своп на быстром устройстве, то рекомендуется высокий swappiness.

У меня - крайне медленный WD Blue из 2009 года. И пока я не поставил vm.swappiness=10, система очень плохо себя чувствовала, стоило занять более 60% оперативной памяти.

Это было легче всего проверить при помощи VirtualBox. Когда пытаешься отдать виртуальной машине больше половины системной памяти, программа предупреждает, что это делать не рекомендуется. И если проигнорировать предупреждение и запустить виртуальную машину - система начинает сильно своппиться и жутко тормозить. Хотя свободно ещё целых 40% оперативной памяти, сотни мегабайт.

С этим же параметром, своппинг начинается только тогда, когда занято 90% памяти, а свободно менее 10%. Это здорово улучшило юзабельность системы в целом.

Понятно, что для SSD можно начинать своппинг хоть при 1% занятой оперативки.

запустил обычный тест tail /dev/zero, и моя система повисла намертво.

Даже SysRq не работал.

На непропатченом ядре tail /dev/zero, как и ожидается, не зависает

Вообще похоже на толстоту.

У меня - крайне медленный WD Blue из 2009 года

Тем более свопинес надо повышать, если своп на zram.

Я когда IC-1200 с шины 100 на 133 вот прямо так себя и ведет дебиан 9…

Кстати, об отзывчивости и тюнинге. Попробовал повысить /proc/sys/vm/min_free_kbytes до 10% от оперативки и это в пару раз повысило отзывчивость под tail /dev/zero. А потом выставил ему приоритет ionice -c3, и это дало ещё пару раз. В сумме повышение отзывчивости почтии на порядок и смена ситуации «скорее висит» на «можно выполнить простейшие действия».