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

На винде процессы не убиваются, а сами падают с cannot allocate memory. То же самое происходит в линуксах при ограничении оверкоммита. Доказательство на скринах fsb4000

$ tail /dev/zero
tail: память исчерпана

• в линуксах тоже бывает такой ответ tail. Если прибивается килером, то в терминале увидишь Killed, а не memory exhausted.

А что делать, если не убивать? Если не убивать, то система встанет колом, и ты не сможешь запустить ни один процесс.

Интересно, спасибо.

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

Напоминаю, что в ядре уже есть OOM killer и у него есть своя эвристика. Каждый процесс имеет oom_score от 0 до 1000. Обычно жирные процессы имеют наибольший oom_score. nohang использует те же oom_score. - По умолчанию убивает те же процессы, что и должен был бы убить ядерный килер. Убивается tail, а не игра, потому что tail жирный. nohang позволяет дополнительно гибко регулировать выбор жертвы. Например:

# защищаем от убийства пакетные менеджеры
@BADNESS_ADJ_RE_NAME  -200  ///  ^(dnf|yum|packagekitd)$

# защищаем от убийства иксы и прочее важное
@BADNESS_ADJ_RE_REALPATH -200  ///  ^(/usr/libexec/Xorg|/usr/lib/xorg/Xorg|/usr/lib/Xorg|/usr/bin/X|/usr/bin/Xorg|/usr/bin/Xwayland|/usr/bin/weston|/usr/bin/sway)$
@BADNESS_ADJ_RE_REALPATH -200  ///  ^(/usr/bin/gnome-shell|/usr/bin/metacity|/usr/bin/mutter|/usr/lib/gnome-session/gnome-session-binary|/usr/libexec/gnome-session-binary|/usr/libexec/gnome-session-ctl)$

# убивать стресс в первую очередь
@BADNESS_ADJ_RE_REALPATH  900  ///  ^(/usr/bin/stress|/usr/bin/stress-ng)$

# предпочитать вкладки firefox, вместо убийства всего браузера
@BADNESS_ADJ_RE_NAME   200  ///  ^(Web Content|Privileged Cont)$

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

Спасибо за разъяснение. Доберусь до гроба своего, попробую.

Как опытный фрезеровщик заявляю. Файрфокс, комплияние, что угодно на десктопе может повесить систему наглухо. И не развесить. И на 4 и на 8 и на 16 гигах памяти. И со свапом и без.

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

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

Лок файла - операция считывания с последующим вечным закреплением памяти. Поэтому перечитывание бинарей и либ больше не понадобится, пока жив prelockd - ни при своппинге, ни после оом - все либы всегда в памяти. На самом деле не особо затратное, если не запускать постоянно жирные процессы с последующим их закрытием (владельцы больших обемов памяти могут позволить себе никогда или очень долго не выгружать ничего - все через конфиг настроить можно - частоту опроса и лимиты обемов блокировки). Например, у меня на деб9 со старта всего 180м замапплено. С браузером - до 400М. На федоре с гномом 700М со старта может быть мапплено. Однако для эффекта не обфзательно блокировать все. Можно лочить только файлы меньше 20М, можно будет лочить только процессы с определенными именами (возможность будет добавлена), например иксы и оконные менеджеры.

И со свапом и без

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

Файрфокс, комплияние, что угодно на десктопе может повесить систему наглухо

Компилял vcmi на двухгиговой тачке, на пике ему надо было 1.8 Гб. Поставил на компиляцию, отошёл, вернулся — компиляция завершена. И пофиг на отзывчивость гуя на этот момент. А вот если бы процесс компиляции кто-то пришиб, это было бы обидно.

и на 16 гигах памяти

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

И пофиг на отзывчивость гуя на этот момент

Если есть возможность иметь при этом отзывчивый гуй - почему бы и нет?

Попробуй на той же тачке скомпилить muse (тот который daw). Хотя, может не он, а сопутствующие пакеты из aur. Наглухо вешает говномп с 4 гигами и свапонрамом. Последнее что попадалось.

Повторю, нельзя использовать свап, как дополнительную память. Если на машине с 4гб пытаться компилять софт, которому для сборки нужно 16 гиг, то тут ошибка не в системе, а в днк. У системы тут только два варианта — или бесконечный (почти) свопинг, или убийство процесса. И ни в одном из этих вариантов ты свой софт собранным не увидишь.

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

Например, у меня на деб9 со старта всего 180м замапплено. С браузером - до 400М. На федоре с гномом 700М со старта может быть мапплено.

мне больше интересно, как там у постгресс базы на 700 Гб будет с мепингом. они, видимо, также решили вопрос и делают лок сами, принудительно.

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

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

Очень, очень, очень, бесконечно неправильное и плохое решение.

Постгрес полностью доверяет ядру в плане кеширования (и правильно делает).

постгресс базы на 700 Гб

лочим бинарь субд и либы, а не саму базу - а это не так уж много. Думаю код субд меньше кода браузера. А у браузера объем 200м. +можем не лочить файлы больше определенного размера. Сейчас дефолт лимит 50М на файл и 500М общий. В первую очередь блокируем мелкие файлы. Большинство блокируемых файлов - это мелкие so из /usr/lib

Очень, очень, очень, бесконечно неправильное и плохое решение.

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

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

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

это общее объяснение, но есть внутреняя кухня

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

они, видимо, также решили вопрос и делают лок сами, принудительно

Это можно будет проверить. Интрумент проверки готовится. Думаю ничего они не решили и ничего не лочат. СУБД же работают с обычными правами, а для лока нужен CAP_SYS_LOCK.

у нас проблема с поведением прикладного софта или ядра

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

Бешеный io при нехватке памяти, даже когда ничего не происходит - очевдно, это проблема ядра.

они, видимо, также решили вопрос и делают лок сами

Если имеешь доступ к серверу, то можешь проверить как минимум

cat /proc/meminfo | grep Mlocked

На десктопе обычно околонулевые значения - гуй сам себя не лочит. Думаю с СУБД ситуация такая же.

Для серверов есть memlockd - блокировщик sshd и прочей мелочи. По заявлению автора, memlockd позволяет в три раза ускорять вход в систему по ssh при нехватке памяти. И да, создание prelockd в значительной степени вдохновлено memlockd.

Ты просто плохо представляешь себе работу менеджера памяти. Если страница вытесняется из файлового кэша, значит она не используется. Никто не будет скидывать из памяти страницы кода, если ими активно пользуются (их редких исключений — если кому-то потребуется настолько дофига памяти разом, что других претендентов на освобождение уже не осталось, но это уже я, повторюсь, склонен относить к ошибкам в днк пользователей, ну должен человек понимать, что свап не способен заменить оперативку, и не стоит запускать приложение, которому надо 8 гиг, на машине с 4 гигами оперативы). Условно говоря, если из 100 мегабайтной библиотеки используется одна функция, то умное ядро оставит в памяти только страницы с этой функцией, ты же принудительно держишь весь мёртвый код. Да, когда памяти у тебя 16 гиг, а лочится полгига, то это не сильно заметно, но, фактически, ты заставляешь иметь 16 гиг, когда достаточно 8.

Можно развернуть мысль? Я не понял, что имелось ввиду.

cat /proc/meminfo | grep lock
Mlocked:           23628 kB

free -m
              total        used        free      shared  buff/cache   available
Mem:          48286       10909        7336         687       30040       36131
Swap:          4095         193        3902

Выходные, постгрес расслабился, в пятницу почти 20 жрал.

Никто не будет скидывать из памяти страницы кода, если ими активно пользуются

Это верно, если памяти хватает. При нехватке памяти код выбрасывается, потом снова считывается, и так по кругу - образуется колесо thrashing’a.

ы заставляешь иметь 16 гиг, когда достаточно 8.

Я предлагаю лочить несколько сотен метров важных либ, когда есть возможность.

Можно лочить избирательно. Например, для лока Xorg и xfwm4 на деб 10 xfce достаточно залочить 50м - это уже дает хороший эффект.

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

Неплохо б увидеть /proc/pid/status постгреса, поле VmLck.

Нехватка памяти — ситуация, вообще-то, нештатная

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

Не стоит ломать daily use ради решения проблемы, которая может и не возникнуть

1. daily use не ломается - лок важных либ ограниченного размера ничего не ломает.
2. проблема возникает довольно часто. Если у вас не возникает проблема - то вы и не установите этот демон. Пока его устанавливают добровольно те, кто предпочитают отзывчивость.

человек способен гораздо правильнее разрулить эту ситуацию.

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

Ну вот. СУБД ничего не блокирует.

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

На видео фризы по фпс есть существенные. И лаги

Ваш бряк

Это такая же история успеха, как слака и гента

Ваш бряк

На видео фризы по фпс есть существенные. И лаги

Без демонов - полный фриз на этом же ядре. Просто tail /dev/zero замораживает гуй при начале своппинга.

С демонами - многопоточный стресс с глубоким своппингом не сильно мешает игре.

Лаги у меня и без стрессов с этим медленным HDD и древней видюхой.

Но которая встречается регулярно

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

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

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

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

Ваш бряк

Вот еще supertux2 и 14-поточный стресс stress -m 14 --vm-bytes 1G - https://youtu.be/MzCe-REHcYw

Лаги есть, но потери управления нет. На самом деле лагов меньше, чем на видео - это скрин рекордер при стрессе подтормаживает.

Почему я не встречаюсь с этой проблемой? И на работе у меня никто на это ни разу не жаловался?

Так и мне моих 10гиг + 14гиг свопа на зрам хватает. А вот раньше было 6 гиг - приходилось постоянно посматривать на монитор, ибо полные зависания при утечках бывали.

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

У меня ещё года 4 назад было 4 гига на домашнем компе (а на работе и до сих пор, благо, в связи с коронавирусом, меня держат на удалёнке, и работаю я из дома). Потом 8, теперь 16. Но фризов от нехватки памяти не было. Чудеса. Неужели это как-то связано с тем, что я не запускал сборку файрфокса, не создавал десятки виртуалок, и, вообще, не пытался на машине с 4 гигами жить, как будто там 64 гига?

Я представляю какой объём работы ты сделал! Респект и уважуха!

Бряк

В нормальных условиях должно было бы прекратить компиляцию со словами «памятя концалася», а не вешать колом комп. И не я решаю как использовать свап, это решает линукс. Будешь втирать мне про sysctl-fu? А ну давай свою настройку, заценю у себя.

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

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

Играем в supertux2 при восьми потоках while true; do tail /dev/zero; done в фоне, со звуком.

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

там же oom-score настраивается, чтобы убивался только левый шлак

Я, если честно, совершенно не понял, решением чего это является.

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

идти в магазин за памятью

а что уже начали выпускать плашки памяти на терабайт?

Playing supertux2 with 8 while true; do tail /dev/zero; done in background https://www.youtube.com/watch?v=Kz8_OuDMsuE

С показом top и метрик PSI.

10GB

помогают сохранять отзывчивость несмотря ни на что

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

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

Не дичайший, а прекраснейший, великолепнейший набор!

post-factum можно ли интегрировать эти костыли в linux-pf?