LINUX.ORG.RU

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

 


14

2

Собственно: https://youtu.be/fPnbnNX9CPE

Система на HDD, Debian 9 Mate, MemTotal=10GB, swap on zram (disksize=14GB). memavaild, prelockd и nohang-desktop работают в фоне и помогают сохранять отзывчивость несмотря ни на что.

https://github.com/hakavlad/nohang

https://github.com/hakavlad/prelockd

https://github.com/hakavlad/memavaild

Кратко: prelockd - новейшее оружие в борьбе за отзывчивость при нехватке памяти.

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

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

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

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

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

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

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

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

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

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

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

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

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

prelockd:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Requirements Python 3.3+ systemd with unified cgroup hierarchy

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

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

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

4.2.

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

https://imgur.com/a/D1oCCGN

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

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

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

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

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

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

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

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

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

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

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