Выделение оперативной памяти для приложения/процесса

Есть ли эквивалент для cgroup2? Эпоха v1 уходит в небытие.

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

overcommit - это полезная абстракция.

Можно подробнее? Я всегда считал overcommit костылём для запуска говнокода. С удовольствием посмотрю на разумные аргументы в пользу.

Было бы неплохо, но реализации этого я пока не видел.

https://gitlab.freedesktop.org/hadess/low-memory-monitor

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

все мои 16 гигов оперативки?

Наложить патч

-echo PENIS
+tail /dev/zero

fork() — это говнокод?

CoW-маппинг — это говнокод?

программа сможет это корректно обработать

Но делать этого, конечно, не будет.

4.2

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

Весь вопрос в радиусе рук и рукочасах, вложенных в разработку.

В опсосе с этим грустно, да.

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

Проверь венду. На ХР/7 таксменеджер по трём кнопкам всегда приходит. Может даже прйти без иконок, но обязательно придёт, и даст возможность убить кого-то.

Настройки файла подкачки дефолтные.

ССЗБ. «Дефолтные настройки» - жрать всё свободное место на диске. Надо или ограничивать или отключать.

fork() — это говнокод?

Да. Надо использовать posix_spawn или exec() сразу после fork(). fork() опасен тем, что объём памяти может потенциально разрасти до размера родительского процесса без явного выделения памяти.

CoW-маппинг — это говнокод?

Зависит от ситуации.

Он стоит размером в 4 с лишним гига.

https://gitlab.freedesktop.org/hadess/low-memory-monitor

Спасибо.

В федоре включен, но проблема в том, что на посылаемые им сигналы ни одна прога пока не реагирует

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

10-очка поди или восьмёрка.

Они там, вроде, сменили стратегию на «размер свопа = размер памяти».

Но это не точно.

Да десятка, но не моя.

И нет, памяти там стоит 32 гига.

Можно подробнее? Я всегда считал overcommit костылём для запуска говнокода.

Концепция оверкоммита неразрывно связана с концепцией виртуальной памяти. См

All this makes dealing directly with physical memory quite complex and to avoid this complexity a concept of virtual memory was developed.

The virtual memory abstracts the details of physical memory from the application software

И далее https://www.kernel.org/doc/html/latest/admin-guide/mm/concepts.html#virtual-memory-primer

exec() сразу после fork()

Как же сделать exec(), если fork() запрещен воображаемой нехваткой памяти?

Надо использовать posix_spawn

А потом придумывать костыли для работы shell, как в винде?

fork() опасен тем, что объём памяти может потенциально разрасти до размера родительского процесса без явного выделения памяти.

Это не баг, это фича.

Клон процесса — полнофункциональный процесс, внезапно.

Как же сделать exec(), если fork() запрещен воображаемой нехваткой памяти?

Можно предусмотреть частный случай вызова exec() сразу после fork(). Видел урезанную реализацию fork() которая вообще не создаёт процесса и ожидает вызова exec(), который собственно создаёт процесс.

Это не баг, это фича.

Рост памяти дочернего fork процесса непредсказуем и трудноуправляем так что приходится считать потребляемый объём равным родительскому процессу. После долгой работы дочернего процесса оно скорее всего так и станет.

Концепция оверкоммита неразрывно связана с концепцией виртуальной памяти.

Я, конечно, очень извиняюсь, но это полная чушь.

«Виртуальная память» = виртуальное адресное пространство. Ещё это технически не верное, но исторически сложившееся наименование свопа в среде непрограммистов.

Я даже нафантазировать не могу неразрывность связи этого механизма с оверкоммитом.

К оверкоммиту можно притянуть общие страницы памяти из разных процессов, но это уже никак не «неразрывно», а очень даже наоборот.

А потом придумывать костыли

Да, потому что нет ничего хуже, чем передача неизвестного количества дескрипторов (файловых , сетевых, баз данных) в неизвестное количество процессов с неизвестным поведением.

Лицорука.

Ну напиши мне интерпретатор команд без форка, ага.

Рост памяти дочернего fork процесса непредсказуем и трудноуправляем так что приходится считать потребляемый объём равным родительскому процессу. После долгой работы дочернего процесса оно скорее всего так и станет.

Ужас-то какой, и как мы такое могли допустить!

А вам зачем «предсказывать» потребление памяти?

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

А то дойдёте до того, что exec() надо запретить, ведь запускаемый процесс имеет непредсказуемое потребление.

exec() надо запретить, ведь запускаемый процесс имеет непредсказуемое потребление.

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

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

Ты ни за что не угадаешь, что увидишь, если ты откроешь ман на fork()…

Ну напиши мне интерпретатор команд без форка, ага.

Через posix_spawn()? Там есть возможность задать environ и наследование файловых дескрипторов.

И как в Windows умудрились cmd.exe сделать…

Ты ни за что не угадаешь, что увидишь, если ты откроешь ман на fork()…

Для процесса созданного через posix_spawn() или fork() & exec() проще проконтролировать и гарантировать потребление памяти, чем для fork(). В результате для процессов, созданных через fork() выше вероятность быть прибитыми OOM-killer’ом. Например процесс выделил много памяти на куче, сделал fork(), освободил память, а память дочернего процесса начала сильно расти из-за записи в сильно фрагменированные небольшие объекты кучи. С posix_spawn() таких проблем нет, фрагментация кучи не наследуется.

Избранные теги: asm, assembly, c, c++, kvm, win32, wine

Виндузятники прочно поселились на ЛОРе и учат нас, как виртуальная память должна работать.

Я даже нафантазировать не могу неразрывность связи этого механизма с оверкоммитом.

Это печально, что вам не хватает соображалки и образования.

«Виртуальная память» = виртуальное адресное пространство.

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

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

Под капотом эту память можно отображать на файлы, выгружать в своп, сжимать, делать CoW или наоборот дедупликацию идентичных страниц — всё это остаётся «за горизонтом событий».

Вот только его и умудрились.

Для процесса созданного через posix_spawn() или fork() & exec() проще проконтролировать и гарантировать потребление памяти, чем для fork().

Контролировать и гарантировать с какой целью? Это нужно чтобы что?

Виндузятники прочно поселились на ЛОРе

Признаюсь, я проорал.

Контролировать и гарантировать с какой целью?

Чтобы не быть убитыми OOM-killer’ом и не повесить систему.

Чтобы не быть убитыми OOM-killer’ом

А это нужно чтобы что? «Птичку жалко»?

и не повесить систему.

1. Это бага ванильного ядра. К ядру от гугла претензии есть?
2. Она не лечится выключением оверкоммита. Я вам предлагал проверить.

А это нужно чтобы что?

Чтобы программа успешно выполняла свою работу. Убитые программы по понятным причинам этого делать не могут.

Чтобы программа успешно выполняла свою работу.

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

Убитые программы по понятным причинам этого делать не могут.

Незапущенные этого тем более не могут.

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

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

Пошла писать губерния.

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

Hint: это не ОСРВ, рабочая среда и задачи меняются в каждый момент времени.

watermark_scale_factor

О, любопытная штука, а почему о нём в man procfs до сих пор нет?

хз, в ядерном vm.rst всё есть

На ХР/7 таксменеджер по трём кнопкам всегда приходит

Ага, попробуйте жручему процессу реалтайм-приоритет задать и любоваться, как таскменеджер мммммэдленно приходит ;)

tty удобнее, можно отдать команду и пойти минут 20 пить чай, пока она выполняется, а не вступать с ЭВМ в ммммэдленный изнурительный диалог ;)

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

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

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

Хз. Я ловил случаи, когда десятка не могла отрисовать его UI, а семёрка в похожих ситуациях — могла.

Может уже пофиксили…

реалтайм-приоритет задать

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

А ещё графическая сессия

Нет никакой «сессии», кроме пользовательской и хз какой мультикс её пророк. Есть графическая подсистема.

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

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

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

Только на этом «МММ» уже завязан GigaCage, например.

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

А откуда юзверю знать, что так делать нельзя? Мы вот не знали ;)

кроме пользовательской

А пользовательская консольной и графической не бывает? ;) Ну у виндузятников только графическая, да.

Это если у тебя видеодрайвер чёт приуныл

Речь не о видеодрайвере, а о том, что фулскрин кривой программы перекрывает всё остальное. А диспетчер в XP/7 уж точно открывался в той же графической сессии.

уже завязан GigaCage, например.

Например, не завязан. И да, я только что прочитал, что это.

А пользовательская консольной и графической не бывает?

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

Речь не о видеодрайвере, а о том, что фулскрин кривой программы перекрывает всё остальное.

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

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

А диспетчер в XP/7 уж точно открывался в той же графической сессии.

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

не завязан

Ну и как, позвольте-с, без оверкоммита выделять стопицот гигабайт виртуальной памяти? ;)

я только что прочитал, что это

Потому что раб попсовых хромолисов?

режимы работы видеоподсистемы в эмуляции текстового вывода

До NT6 имелся доступ к настоящему текстовому режиму видеокарты ;) Вот с внедрением WDDM он сдох, да, теперь винда — чисто графическая ОС.

зависшая видеоподсистема будет показывать мусор / последнее состояние видеобуфера перед сбоем

Ну так и при чём здесь это, когда речь о случае, когда видеоподсистема работает, только кривая программа перекрыла собой нафиг другие окна, даже always-on-top? ;)

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

не «графической», чурбак ты неотёсанный, а «пользовательской»

Ещё раз повторяем: графическая — вид пользовательской :P А пользовательская может быть ещё и текстовой. В контексте онтопика последние также подразделяются на tty и pty. Почему горите? ;)

У меня 8 лет назад была проблема в openSUSE. Я использовал легковесное DE KDE3, с которым система занимала всего лишь 200 Мб в ОЗУ. Я создавал виртуальную машину и отдавал под неё 1 Гб ОЗУ. И система начинала активно своппиться, хотя памяти было свободно ещё 800 Мб!

Выяснилось вот что. Когда ОЗУ заполняется а 60%, то система начинала своппиться. Оказалось что виноват параметр vm.swappiness. Задал ему значение 10 - проблема исчезла. Вроде как теперь своппится, когда 10% памяти осталось свободно.

И ещё конкретно в openSUSE нашёл баг, которого не видел в Debian. По какой-то причине на 2 Гб ОЗУ параметр -v в ulimit был задан слишком маленький. Я увеличил этот параметр, и починилось много проблем.

Когда я тестировал эти патчи, они больше вредили.

Ты тестировал древний сырой le9d https://github.com/hakavlad/le9-patch/blob/main/original_le9_patches/le9d.patch, у которого даже sysctl ручек не было:

For me thrashing is much worse with patchset than without it. With the patchset, it seems that resource unloading happens very often, much more often than it should be performed, and everything swaps for some reason. With 2 GB RAM, the kernel tries to swap everything it has, and used RAM is usually 400-700 MB (1+ G free) with 1 GB SWAP occupied.

– https://web.archive.org/web/20191018023405/https://gist.github.com/constantoverride/84eba764f487049ed642eb2111a20830#gistcomment-2779445

В современных версиях (le9bb) есть мягкие и жесткие ограничения, и таких проблем нет. Резервируется не больше, чем указано через vm.file_min_kbytes или vm.file_low_kbytes. Так что приглашаю к повторному тестированию, и жду отзывов.

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

Вот мой шаблон

Как им пользоваться?