Как арчеводы живут с /tmp в tmpfs?

Лично у меня - 4 Гб, tmp в оперативе, своп в оперативе, запущена виртуалка с виндой с 2 Гб оперативы, браузер, Spotify, Viber всякий - и ничего не тормозит.

Но есть несколько ноу-хау как добиться.

NIXon, ты? :) Давай, рассказывай про свой NIX, тебя я послушаю.

Кстати. Приехала рама16 гигов. Вставил, ощущаю, думаю. Может сразу ставить что-то хорошее?

Конкретно тут дело не в Nix.

Я накладываю патч от hakavlad на ядро, подбираю его настройки, делаю минимальный swappiness. Плюс к свопу в оперативе, у меня включен настоящий своп раздел. Модных OOM киллеров нет, потому что эта зараза убивает программы.

Как выяснилось внезапно (это очередное откровение почти как тот тред с ядрами), чтобы не тормозила виртуалка qemu - надо ее запускать с минимальным приоритетом. Невероятно но факт. Начинает намного лучше работать как сама виртуалка, так и хостовая система.

Модного киллера я завёл в надежде, что убьётся фокс, но он убивает всех ради фокса :)

Вообще, сижу и думаю, ставить систему наново, или не ставить?

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

Ктати! а как zram и zswap уживается с программами реального времени? Накладные расходы всё-таки. Как оно?

Вроде без свопа чуть лучше, но это на уровне плацебо.

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

К чему это я, пара банков и мы в свопе. А нужен рилтайм.

С банками я пока не пробовал. Как-то забросил это, sf2 с general midi мне достаточно. Я же только бас и ударку синтезирую.

свопа должно быть дважды от оперативной памяти

Зачем?

Чтобы можно было употребить 2х памяти и хватило на hibernate. Или 3х в пике.

Достаточно и половины объема, если ОЗУ большое

Зависит от задач. Своп на zram не занимает места, так что не проблема делать его 1.5x MemTotal.

Как арчеводы живут с /tmp в tmpfs?

Прекрасно!

Модных OOM киллеров нет, потому что эта зараза убивает программы.

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

Модного киллера я завёл в надежде, что убьётся фокс, но он убивает всех ради фокса :)

настроить кто мешает? гибкость не ограничена. 50 ключей конфига у nohang (документации, конечно, нет).

завёл в надежде, что убьётся фокс, но он убивает всех ради фокса

nohang.service или nohang-desktop.service запускал? У второго лиса в приоритете при убийствах.

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

Своп есть. То есть, всякие early oom убивают не когда своп исчерпан, а когда они по своим понятиям решили что приложение скоро все сожрет. А оно просто много памяти выделяло, только и всего.

Все настраивается. Можно убивать когда своп фри 1% и доступной 1%, например.

Я говорил о конкретном размере свап раздела на диске.

Что это меняет? При любом размере памяти можно найти задачи, которым понадобится размер 3x MemTotal свопа.

Меня мучает такой вопрос - неужели я единственный кому это не нравится?

Что конкрентно? Отсутствие 12309?

Купи уже себе планку на 4 гига, нищеброд

Ну так мы и не говорим о любых задачах. Говорим о стандартном значении. Раньше стандартным значением была 2x объема ОЗУ. Это было связано с поддержкой гибернации, с тем что памяти было на порядки меньше, чем диска. Если озу 1 гб, то диск минимум 50 гб. Сейчас же с повлением ssd нормаой стало 2/32 4/64 8/128 и два размера ОЗУ на таком диске стало слишком накладно, а объем ОЗУ достаточно велик, чтобы технологии zram давали свой эффект.

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

malloc() должен начать возвращать NULL.

Проги не продолжат волшебным образом работать - проги замёрзнут.

Чиво?

malloc() должен начать возвращать NULL.

Бессмыслица. Даже неловко стало за твои звезды.

Бессмыслица это твой пост. Если есть какая-то конкретная мысль, её и пиши, а не на звёзды смотри.

И часто тебе приходится использовать 2x памяти? И часто тебе приходится при этом делать hibernate?

Нет, не часто. Полный привод тоже приходится использовать не часто. Это не делает его менее ценным.

маллок должен быть успешным. Зачем фейлить его, если еще есть свободный своп?

маллок должен быть успешным.

Не должен.

Зачем фейлить его, если еще есть свободный своп?

По условиям задачи «памяти нет».

Некорректное сравнение. Полный привод не рекомендуют в качестве единственно верного варианта. Там, где он есть, он может быть отключаем. Да и нужен он куда чаще, чем интенсивное использование swap и одновременная гибернация. Мне кажется, зависнет гораздо раньше, чем ты успеешь залезть в swap на объём ОЗУ. Да и выделение под swap 32-128 ГиБ места звучит бредово.

Так память как раз есть. Виртуальня память и физическая - немного разные вещи. Сравни в /proc/pid/status значения VmRSS и VmSize. Size - виртуальная память процесса, она может быть в тысячи раз больше реально занимаемой процессом.

Твоя идея с фейлящимся маллком была бы неплохой, если б эти значения были одинаковы, причем у всех процессов. Однако на практике у некоторых процессов размер виртуальной близок размеру физической, однако в большинстве случаев процессы выделяют дохрена виртуальной (например, браузеры и java процессы). В таком случае в одних случаях маллок сфейлится преждевременно, когда свободного свопа или памяти еще много, в других случаях может произойти противоположное - ООМ киллер или зависание случатся раньше, чем фейл маллока.

Проверил сейчас, malloc возвращает NULL только когда размер запрашиваемого объёма больше, чем (размер_ФП + размер_свопа + 1 сраница - 1 байт).

Цитата из man malloc:

By default, Linux follows an optimistic memory allocation strategy. This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. In case it turns out that the system is out of memory, one or more processes will be killed by the OOM killer.

Поведение зависит от overcommit_memory: https://www.kernel.org/doc/html/v5.1/vm/overcommit-accounting.html

Поведение зависит от overcommit_memory

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

А почему только арчеводы? Я в своей генте так же делаю. А вот почему ты не ограничиваешь размер /tmp/ до разумного значения — вопрос

В винде оверкоммита нет и это не мешает там работать ни браузеру, ни жаве. Значит все эти трюки с выделением ста терабайтов не нужны.

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

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

Я бы пошёл дальше, присвоить ограничение видимой памяти группе cgroups в которой работает файрфокс. Можно ли ограничивать видимое доступное пространство памяти? Чтобы приложение N (в соответствующей cgroup) думало, что у меня гиг памяти? Или все эти ухищрения невозымеют силы, потому что ещё больше ухищрений использует браузер?

В винде оверкоммита нет и это не мешает там работать ни браузеру, ни жаве.

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

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

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

Можно ли ограничивать видимое доступное пространство памяти?

Я не знаю как сделать фейковый /proc/meminfo. Вряд ли это возможно.

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

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

ограничение видимой памяти группе cgroups

В сигруппе можно ограничить реальную память (memory.max), но не видимую.

Еще минус фейла при неудачном маллоке: невозможность выбора приложения, которое упадет. В случае с неограниченным оверкоммитом выбирать жертву можно путем настройки oom_score_adj. Если мы полагаемся на фейл маллока, то упадет случайное приложение, которому не повезло выделять память тогда, когда ее объем упёрся в искусственные лимиты.

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

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

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

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

Еще минус фейла при неудачном маллоке: невозможность выбора приложения, которое упадет. В случае с неограниченным оверкоммитом выбирать жертву можно путем настройки oom_score_adj. Если мы полагаемся на фейл маллока, то упадет случайное приложение, которому не повезло выделять память тогда, когда ее объем упёрся в искусственные лимиты.

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

В винде оверкоммита нет

как это нет?!
я вот смотрю свойства процесса Teams.exe:
Private bytes = 265 mb
Virtual size = 2 tb (!)
Working set = 55 mb

(!) - это не оверкоммит?

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

Имеет, но кодеры об этом не думают. Это то, что мы имеем фактически: большинство процессов либо падают на фейле, либо начинают работать некорректно.

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

своп = 3 гига
два диска, 120 гиг под систему и 1 тб под хлам.

Получается, что единственное что я могу регулировать - когда убить браузер. И это пипец как расстраивает, потому что комп может или делать кучу всего, или запустить браузер.

Кстати, даже на 16ти гигах рамы nohang продолжает убивать приложения ради фокса. Браузер зажрался.

Не пробовал настраивать nohang? Как он настроен, какой юнит запущен - nohang или nohang-desktop?

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

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

даже на 16ти гигах рамы nohang продолжает убивать приложения

Своп маленький?