Просто оставлю это здесь: Игра в supertux2 с множественными `tail /dev/zero` в фоне без зависаний

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

Спрашивайте ответы.

Что делает-то код? Просто убивает тейлы? Или?

Да всё понятно, не гони.

я хочу чтобы он описал по человечески. Я требую. Я буду жаловаться в спортлото!

Неужели теперь Linux при нехватке ресурсов будет реагировать нормально, как то же ядро NT?

Через костыли, видимо. Prelock.

Не, ну черьёзно. Это три связанных друг с другом службы спасения десктопа? Или ставить на выбор? Или что?

я видел спидран и получше

А в чем успех?

При чём тут супертукс?

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

Почему он должен зависать?

Потому что запущены несколько потоков tail /dev/zero - быстрых пожирателей памяти, создающих интенсивный своппинг. Без специальных демонов фокус не получится, и гуй зависает.

Это хорошо когда есть треш в фоне, который не жалко прибить, а что делать если все процессы важны в данный момент? Например, компиляция проекта и просмотр видео на ютубе или чтение каких-нибудь мануалов? Что там грохнется, а что сохранит отзывчивость?

Что делает-то код? Просто убивает тейлы?

nohang: убивает тейлы.

memavaild: балансировщик доступной памяти. При исчерпании доступной памяти уменьшает memory.high указанных в конфиге контрольных групп (по умолчанию user.slice и system.slice), тем самым освобождая доступную память и место под файловые кэши.

prelockd:

mlock() на мемори маппленные файлы. Это препятствует не выгрузке в своп, а ОТБРАСЫВАНИЮ КЭША. Обычно при нехватке памяти кэш исполняемого кода отбрасывается, потом снова загружается с диска - возникает колесо thrashing’a и высокий io (чему очень удивлялся А. Ташкинов [1]). При применении prelockd такого не происходит - нет фазы выгрузки кода и зависания - сразу приходит киллер. При наличии свопа просто силно растет отзывчивость гуя и прочего.

[1] https://lkml.org/lkml/2019/8/4/15

Что там грохнется, а что сохранит отзывчивость?

То, у чего больший oom_score. Если запущен хром, то скорее всего вкладка хрома - процессы хрома из коробки имеют увеличенный oom_score_adj (+300).

Юзерспейсный киллер позволяет более гибко регулировать badness процессов.

Если блокировать все - и файлы браузера, и всех приложух - получаем эффект как на видео - приложениям вообще пофиг на своппинг, работают как ни в чем не бывало. Поэтому думаю это вообще хорошая практика - до 5-10% памяти выделять под блок. Получаем всегда отзывчивый гуй (особеннно в сочетании с остальными демонами).

А в чем успех?

Успех в решении проблемы века - неспособности линуксов мягко обрабатывать нехватку памяти, см https://www.opennet.ru/opennews/art.shtml?num=51231

Неужели теперь Linux при нехватке ресурсов будет реагировать нормально

Именно! лок исполняемого кода полностью излечивает киллера - киллер приходит сразу, минуя фазу предООМного дедлока с высоким io.

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

Каждая их них полезна по-своему. Все вместе дают идеал - способность выдержать любой стресс (если своп на zram, а не на HDD).

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

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

Прикольно

Так что, готов для десктопа? Свершилось?

Буду дома потестирую.

Не забудьте потюнить конфиги (описания ключей нет, спрашивате).

а не проще ли просто

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

hatred intelfx pon4ik crypt Lordwind CryNet ValdikSS next_time catap AngryElf RiseOfDeath Pentium02 возможно вам интересно

nohang: убивает тейлы.

memavaild: балансировщик доступной памяти. При исчерпании доступной памяти уменьшает memory.high указанных в конфиге контрольных групп (по умолчанию user.slice и system.slice), тем самым освобождая доступную память и место под файловые кэши.

prelockd: mlock() на мемори маппленные файлы. Это препятствует не выгрузке в своп, а ОТБРАСЫВАНИЮ КЭША. Обычно при нехватке памяти кэш исполняемого кода отбрасывается, потом снова загружается с диска - возникает колесо thrashing’a и высокий io (чему очень удивлялся А. Ташкинов [1]). При применении prelockd такого не происходит - нет фазы выгрузки кода и зависания - сразу приходит киллер. При наличии свопа просто силно растет отзывчивость гуя и прочего.

Какой-то дичайший набор костылей, если честно.

тему еще не читал, спасибо, но в супертукса ты хренова играешь. :) вечером прочитаю топик.

Костыли не виноваты, что ядро кривовато.

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

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

есть решение лучше?

Неужели теперь Linux при нехватке ресурсов будет реагировать нормально, как то же ядро NT?

скорее, как режим эмуляции ядра NT при помощи подпорок=)

на мемори маппленные файлы. Это препятствует не выгрузке в своп, а ОТБРАСЫВАНИЮ КЭША.

т.е. сам по себе меппинг много место не занимает, так? его актуализация - самое затратное место.

Костыли не виноваты, что ядро кривовато.

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

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

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

у меня гугл хром вися месяц исчерпывает 32 озу и 32 свапа. ну примерно. я думаю, что эти подпорки типа стопора. чтобы так сказать не придти и не обнаружить, что все встало колом, а увидеть, что OOM покончил с каким-то вкладками, где сумасшедший JS нагрузил картинок «про запас».

Если ты знаешь про такую су(ч|щ)ность хрома, то чому не урежешь его аппетиты через cgroups? А так, сегодня OOM прибьёт вкладку хрома, завтра прибьёт сборку ОченьВажногоПроекта, которую ты на ночь оставил, а сдавать к 8:00.

ну я лично на десктопе без cgroups вообще... но теоретически настройки хаковлада - это и есть дополнительная логика к этим cgroups. разве нет?

Я не очень понимаю, почему тут кивают на винду, которая при нехватке памяти встаёт колом, так что только хардварный ресет спасает. Линукс хоть обычно можно переключить на консоль и там прибить виновника торжества.

Понятия не имею, не смотрел код. По описанию даже не близко.

Requirements Python 3.3+ systemd with unified cgroup hierarchy

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

как это реализовано в ядре NT известно?

именно поэтому у него игра в демо и не вылетает.

Я не очень понимаю, почему тут киваю на винду, которая при нехватке памяти встаёт колом, так что только хардварный ресет спасает. Линукс хоть обычно можно переключить на консоль и там прибить виновника торжества.

4.2.

Вот специально провёл тест на Windows 10 pro, как в ОП посте с tail /dev/zero:

https://imgur.com/a/D1oCCGN

Я предлагаю ограничить потребление памяти конкретному приложению, про которое конкретно известно, что оно любит тратить память не на дело. Это совсем не то же самое, что кто-то автоматически будет решать.

У тебя 26 гиг доступно, где ты увидел нехватку памяти?

ты разберись сначала, что он делает, а потом предлагай...

tail /dev/zero требует всё больше и больше.

На втором скрине было выделено 32.5 гигабайта памяти из 37 гигабайт (32 оперативы + 5 гигабайт свопа)

После того как я сделал скрин выделение памяти ещё чуток подросло и потом процесс убился.

Смотри третий скрин, на заднем фоне виден график потребления памяти

Значит в 10ку добавили этот oom-killer, семёрки и хрюша 100% умирают напрочь. Кстати, неловкий вопрос — а если процесс называется не tail, а postgres, винда его тоже убъёт?

процессы firefox убивались. VirtualBox тоже убивался, когда слишком много виртуалок запускал сразу.

Наверное и postgres убъётся…

7ера жила спокойно, хрюша тупила но не дохла. 100% способ работающий и по сей день это форк бомба, но не как не мемитер

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