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

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

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

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

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

Тебе задачу в свои 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 - позволяет контрлировать степень сжатия и скорость при потреблении памяти.

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

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

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

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

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

x.append(os.urandom(999)

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

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

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

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

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

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

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

Весёлые у вас приоритеты… Зачем работать, вы смотрите как красиво окна открываютсяи закрываются!

А если в скрипте неконтролируемая утечка памяти, значит он вообще ни на каком железе до финиша не досчитает.

Весёлые у вас приоритеты… Зачем работать, вы смотрите как красиво окна открываютсяи закрываются!

как можно работать, если машина не отвечает на ввод?

А если в скрипте неконтролируемая утечка памяти, значит он вообще ни на каком железе до финиша не досчитает.

Об этом и речь, что такое надо убивать, а не зависать с этим.

Мекжду «не отвечает» и «фризится», «лагает» и даже «подвисла на 5 минут» есть большая разница. Фризы мешают только геймерам и дизайнерам со слабыми нервами, половина лагов тоже не особо то мешает работе.

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

Мекжду «не отвечает» и «фризится», «лагает» и даже «подвисла на 5 минут» есть большая разница. Фризы мешают только геймерам и дизайнерам со слабыми нервами, половина лагов тоже не особо то мешает работе.
и даже «подвисла на 5 минут»

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

Фризы и всё описанное тобой конечно же мешают всем нормальным людям (и ещё программистам и технарям).

Сильные нервы и «терпильность» вот это как раз разные вещи. Ты призываешь к «терпильности» (в худшем и наиболее омерзительном смысле этого слова).

Вот десять DE людям действительно не нужно, а отсутствие лагов и фризов нужно (ну и как видим не помогло обилие DE избежать лагов и фризов).

фига какие травмы мозга оставляют говноплатники

пора их запретить, приравняв к наркоте

терпильности

Линуксоиду без этого ни как - должен терпеть за идею.

Каштан.

Ты призываешь к «терпильности» (в худшем и наиболее омерзительном смысле этого слова).

А ты призываешь похерить рабочий процесс и пытаться выиграть в гонке производительности с маркетологами и дизайнерами, завалив их баблом больше, чем они смогут проглотить. И всё ради того, чтобы не тормозило. Вот только я прожил достаточно и вижу, что завтра всё равно будет тормозить, даже если сегодня ты расшибся в лепёшку и победил тормоза. Не хочу быть хомячком в чьём то колесе. А в особенности в колесе гномосеков, которые стараются исправить всё, что до них было сделано хорошо, БЫСТРО, ПЛАВНО и удобно.

Не хочу быть хомячком в чьём то колесе

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

выученная беспомощность или стокгольмский синдром

А у десантников это называется «похуй как, но я это сделаю». Так вот, когда я могу себе это позволить, то пропихиваю 100+ гигов fullHD видео через одноплатник. Или 2+гига браузера в 942М оперы. А для всего, что надо сделать быстро у меня есть ноут за соседним столом. Только мне реально редко это надо.

ну собственно это многое объясняет, что у тебя примером для подражания выступает быдлодесантник, а не тот же эйнштейн

Я не знаком с Энштейном. Совершенно не представляю, как он решал проблемы и ставил цели.

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

Возможно в твоём идеальном мире менее 90% устройств выпускаются с распаянной на материнке памятью, но в реальности всё не так радужно. А особенно нерадужно становится, когда поднимается вопрос «вменяемый объём - это сколько?»

А у десантников это называется «похуй как, но я это сделаю». Так вот, когда я могу себе это позволить, то пропихиваю 100+ гигов fullHD видео через одноплатник. Или 2+гига браузера в 942М оперы. А для всего, что надо сделать быстро у меня есть ноут за соседним столом. Только мне реально редко это надо.

Верну обсуждение в правильное русло: идея и проблема которую решают скрипты — это зависание системы, которого в 2021 году происходить не должно.
Система в 2021 должна сохранять отзывчивость и работоспособность при исчерпании ОЗУ (не взирая к чему ты там привык и с чем стерпелся на своём одноплатнике воюя с мифическими маркетологами и корпорациями в своей голове).

А ты призываешь похерить рабочий процесс и пытаться выиграть в гонке производительности с маркетологами и дизайнерами, завалив их баблом больше, чем они смогут проглотить. И всё ради того, чтобы не тормозило. Вот только я прожил достаточно и вижу, что завтра всё равно будет тормозить, даже если сегодня ты расшибся в лепёшку и победил тормоза. Не хочу быть хомячком в чьём то колесе. А в особенности в колесе гномосеков, которые стараются исправить всё, что до них было сделано хорошо, БЫСТРО, ПЛАВНО и удобно.

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

я прожил достаточно

Хорошая иллюстрация того, что года не всем прибавляют ума. Рассуждаешь как какой-то пятнадцатилетний максималист.

вменяемый объём - это сколько?

На линукс-десктопе самый минимум сегодня это 16, который можно советовать всем, но лучше 24-32 конечно. Ну и nvme-ssd вместо hdd.

На линукс-десктопе самый минимум сегодня это 16

Толсто. Батя на 2 гигах сёрфит нормально Десктоп бати-пенсионера: Linux Mint 18.3 Mate

Тормоза перпендикулярны объему памяти. С 2 гигами машина может не тормозить. А может тормозить и с 32:

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

самый минимум сегодня это 16 но лучше 24-32

Для выполнения задачи, которая фактически занимает 2-4. 2021 там год или нет, но требовать минимум х4, а лучше х16 запас ресурса это всё ещё бред. Речь ведь не идёт о жизни, здороье или крупных материальных потерях.

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

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

Я про нормальную конфигурацию, а описанная конфигурация показывает лишь крутость патчей.

Ты маленькая невинная девочка живущая в идеальном мире или таки живёшь в реальном мире?

экспоненциальному

Ух какие словечки от академика-теоретизатора, звучит ооочень умно! Солидно!

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

«Как оно должно» быть как раз таки частично напочиняется патчем ленина или сервисом прелокди, zram и т.д.

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

Было бы классно конечно если бы была идеальная ОС в 64кб озу, которую можно вместе с процессором вытравить на кухне — но так нельзя. Очень жаль.
Оченб.
Жалб.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хотя свободно ещё целых 40% оперативной памяти, сотни мегабайт.

Похоже на сосяк cgrops. Предлагаю отключить cgrops для памяти вообще параметром ядра при загрузке и попробовать без него.

А ещё виртуалки могут свопиться внутри себя обращаясь к диску напрямую.

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

Параметром vm.swappiness=10? Нет, это не так работает уже давно.

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

Ноуп как раз НЕ про него.
А про другую фичу ОС которая даёт возможность запретить вытеснять либы из ОЗУ.

Прелоклд посмотри.

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

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

Твоё «повышение отзывчивости на порядок» лишь показывает насколько система и её дефолты отстают от потребностей пользователей и что таким важным компонентом никто не занимается (да и ты сам о данной проблематике стал думать видимо только в этом треде, хоть и в отрицающей пока форме).

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

> если своп на zram

Своп же используется, когда оперативка кончилась. Зачем хранить своп в оперативке?

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

найсы/ренайсы/ионайсы в итоге не спасают от вытеснения.

Конечно не спасают. Речь о том, чтобы сделать вытеснение в более оптимальном порядке.

сам о данной проблематике стал думать видимо только в этом треде

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

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

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

Традиционно на эту тему советуют статью Криса Дауна https://chrisdown.name/2018/01/02/in-defence-of-swap.html, перевод: https://habr.com/ru/company/flant/blog/348324/

Зачем хранить своп в оперативке?

В оперативе можно располагать блочное устройство, которое в среднем в три раза сжимает страницы. Это отлично работавет со свопом. В отличие от HDD устройство zram быстрое и многопоточное. Некоторые дистрибутивы перешли на использование только свопа на zram, например Fedora https://fedoraproject.org/wiki/Changes/SwapOnZRAM.

Документация: https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html

Речь о том, чтобы сделать вытеснение в более оптимальном порядке.

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

Вот почему у меня 2000-я винда использует немного свопа. даже когда свободной памяти ещё много. Спасибо за ликбез

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

Запихиваем туда текстовых файлов с коэффициентом сжатия 96%, и забиваем всю оперативку так, чтобы ничего не осталось. Упихиваем туда в три раза больше текстовых файлов, чем есть оперативки на компе. Допустим, на компе 2 Гб, а в оперативке 6 Гб.

Ага, а теперь начинаем медленно заменять текстовые файлы на сжатое видео с коэффициентом сжатия 0%. Все 6 гигабайт побайтово.

Что будет?

В крайнем случае будет ООМ - даже при SwapFree > 0.

Однако в большинстве случаев сжатие таки 2:1-3:1. Браузеры хорошо жмутся, компиляции неплохо сжимаются. При работе в блендере растягивал память со степенью сжатия 1.4:1. Меньшие значения достигаются синтетикой - наполнением памяти данными из /dev/urandom.

Альтернатива - zswap. Несжимаемые данные при этом будут падать на дисовый своп, а сжимаемые - сжиматься в оперативе.

когда они уже осилят и на диск писать сжатые?

например

https://fedoraproject.org/wiki/Changes/BtrfsTransparentCompression

https://fedoramagazine.org/fedora-workstation-34-feature-focus-btrfs-transparent-compression/

не-не девид блейн, так оно будет сначала разжимаься, а потом сжиматься заново

Ты хочешь чтобы кроме фризов от медленного диска оно сверху ежё сжатие разжатие делало? Пожалуй ещё в PAQ8, чтобы наверняка.

С PAQ не утрируй. Но с современными процессорами, если помещать на hdd диск данные, сжатые lz4 или lzo, будет выигрыш.

Ну вот, опять. А кто эти обязательные компоненты помечать будет? И что обязательно? Скрипты в браузере? Или хранить в дисковом кеше вообще весь код, считанный с диска за пару недель аптайма на всякий случай? А что вытеснять вместо них?

Вот поэтому zram не панецея и ставить его больше 30% оперативки особого смысла нет. И ещё есть zswap который может дать примерно те же преимущества, но без головняков. А zram хорош для блочных устройств в оперативке.

Но тем не менее, он реально работает и временами очень конкретно впихивает невпихуемое.

А кто эти обязательные компоненты помечать будет?

Менеджер памяти ядра через механизм LRU

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

С помощью LRU выбирать наиболее горячий кэш, а наименее используемый можно отбрасывать.

ставить его больше 30% оперативки особого смысла нет

Есть. Ставить zram disksize=2MemTotal это ОК. Позволять сжатым страницам заполнять 80% памяти это ОК.

Тогда очень велик шанс, что ни одной софтине не достанется больше 10-15% памяти.

Но менеджер памяти ядра не знает какие компоненты критические для пользователя.

Это уже работает автоматически (в патче/сервисе).
А кто ведёт wine-database и прочие *-database?
(+ты сам лично можешь прописать, что сохранять в памяти)

Разработчики, мейнтейнеры (благо они любят выполнять тройную работу).
Это вполне выполнимая задача (не так уж много этих компонентов: ssh, dm, de, xorg/wayland).

Вытеснять всё то от чего система не встанет как корова на льду.

ни одной софтине не достанется больше 10-15% памяти

Активная память составляет малую часть общей. Большая часть - неактивная. Рабочий набор обычно не очень большой.

>> Зачем хранить своп в оперативке?

> В оперативе можно располагать блочное устройство, которое в среднем в три раза сжимает страницы. Это отлично работавет со свопом. В отличие от HDD устройство zram быстрое и многопоточное

Разве нельзя сжимать данные в памяти сразу, вместо того, чтобы отправлять их на HDD в своп, но вместо этого обратно в оперативку, но сжимая?

Разве нельзя сжимать данные в памяти сразу

Нельзя. Если можно - отправляй свои патчи в LKML.

Может хоть во Фряхе это сделано?

Обычно, но не тогда, когда возникла нехватка памяти. А всякий своп-треш как раз и начинается при нехватке этого самого рабочего набора. Нехватка дисковых кешей как раз неплохо глотается современными ссд.

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

Этого в принципе нельзя. Не помещать же потоковый компрессор между оперой и кешем цпу.

некие дефолтные списки невытеснения в релиз

https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS

А всякий своп-треш как раз и начинается при нехватке этого самого рабочего набора

Так речь как раз и идет о защите рабочего набора с помошью патча: https://lore.kernel.org/patchwork/patch/222042/

Таким образом, уже сейчас существуют механихзмы защиты

• файлового кэша
• анонимной памяти избранных процессов

Лучше используйте патч https://github.com/hakavlad/le9-patch