quemu - kvm как оптимизировать использованием памяти и buff cache?

Так это же ты нищеброд раз вместо 128ГБ памяти купил 64ГБ и добавил ещё 60ГБ свапа.

Так это же ты нищеброд раз вместо 128ГБ памяти купил 64ГБ

Так мне больше на текущий момент и не надо. И слово «купил» тут мимо, это не я покупал, а компания, я только попросил мне (именно мне, это домашний поддиванный) купить, попросил бы 128Гб купили бы и 128, но мне оно нэ надо.
Было бы 128ГБ, то и свопа на 128 накинул бы.

Так мне больше на текущий момент и не надо.

Вроде так говорят нищеброды обычно, не? Что им больше не надо.

И зачем ты пытаешься обманывать пацанов, если у тете «не надо», то откуда у тебя оом? Ты запутался в показаниях.

это не я покупал

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

попросил бы 128Гб купили бы и 128, но мне оно нэ надо.

Выше про показания было. А так да. И 128, и 256, и 1024 купили бы. И вообще что угодно купили бы. Прохладные истории.

то откуда у тебя оом
оом

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

Хорошие у тебя спонсоры, но к чему тогда разговоры про нищебродство и дешёвые понты казённым?

Было бы 128ГБ, то и свопа на 128 накинул бы.

Печально. Тебе пора на курсы повышения квалификации.

Ну т.е. про поняти оом мы не в курсе, но осуждаем... так и запишем за вами.

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

Расскажи мне. Кстати, в удивительное время живём. Нынче эникеи тебе расскажут про оом/память.

quemu - kvm как оптимизировать использованием памяти и buff cache? (комментарий)

«Глупо» это когда у вас система колом встанет из-за out of memory

Это твои показания за то зачем ты вкорячил туда своп. Опять запутался? Ну бывает.

Если у тебя нет оом - зачем тебе своп? И зачем ты об этом писал?

Мда... поколение ПИ....

Осуждаем каргокультные подходы. Почему ты выделил под 60ГБ, а не 128? Ну OOM же. Давай сразу терабайт чтобы наверняка, железо же всё равно казённое!

Ладно, блажен верующий.

Для альтернативно одаренных поясняю, система не должна ставать «какой» из-за нехватки памяти. Вот когда становится понятно, что памяти реально не хватает тогда мы её докинем, а пока «ненужно» можно в на диск «складировать». Так доступнее ?

Я тебя ещё раз спросил зачем тебе 60ГБ?

можно в на диск «складировать».

А здесь ты гордо хвалился что у тебя всего ~241МБ в свап улетело.

Дак памяти хватает, либо нет? Ты уж определись. Если её хватает - не может «не хватать», а если может, то её не хватает. И нужно докинуть.

И как «ненужно» можно докидывать на диск, если памяти хватает? На диск получается нужно докидывать то, что родилось сверх «хватает»?

Тут явные противоречия в показаниях.

Когда ещё 60Гб улетит в swap это уже не будет речи про oom, это речь про полный ПИ. Значит или разбиратся кто сожрал и разбираться с ним или если сожрано легитимно докупать мозгов.
ЗЫ Точнее когда 64Гб мозгов станет не хватать, тогда и будем думать, пока как видите хватает.

cat /proc/sys/vm/swappiness
Так понятнее? По умолчанию там цифирка 60, сами догадаетесь что она значит?

К чему это? Что это? То, что ты в гугле нашёл. Мне то что с этого.

Есть базовая логика -памяти либо хватает, либо нет. Если её хватает - ей ненужен свап-костыль. Если её «не хватает» - то уже есть варианты.

Поэтому аксиома - есть свап «памяти не хватает». Другое либо дыры в показаниях, либо некомпетентность.

Поэтому тебе нужно определиться. Либо оом есть - значит памяти мало. Либо его нет - значит объяснения о том зачем тебе свап несостоятельны.

То, что ты в гугле нашёл.

Ясно. Вам мама на ДР подарила «это ваш компутер» и теперь вы Ъ линуксоид. Ну удачи с такими начинаниями, хотя могли бы и загуглить «нафига оно нужно».

А у тебя сколько стоит?

default - 60

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

Ты даже не смог конкретику сообщить, а начал «Ну сам знаешь» - почему? Если знаешь - сообщи. Зачем прятаться за подобными мусорными фразами? Или ты не знаешь и не хочешь сказать что-то неправильно, не уверен в своём «знаешь»?

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

Зачем? Вот я у многих здесь это замечаю. Судя по всему звёзды давят. Не делай так.

Понятненько. Значит ты начинаешь какать в свап когда у тебя начинает жрать больше 38433МБ памяти. Чтож, весьма разумный выбор!

У онтопика реально разумно реализовано, вытесняются неактивные страницы, а не рандом как в офтопике, когда активно используемые страницы памяти «внезапно» улетают в своп и привет пошаговуха.

Доказать сможешь? Про онтопик.

KSM sharing ?

Что значит доказать?

vm.vfs_cache_pressure - его в какую сторону крутить? В разных источниках разные вещи говорят.

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

Есть ли какой то параметр системы который уменьшает приоритет свопа перед кэшом? Т.е. в случае нехватки памяти система пытается выгрузить весь кэш который только можно и уже только после этого свопится. Ибо 60ГБ кэша стопроцентов можно зафлушить.. Т.е. идея в том что бы жертвовать кэшем в первую очередь использовать своп только тогда когда уже вообще никаких вариантов не осталось.

vm.dirty_ratio - я так понимаю может привести к фризам? И в чем отличиается от vm.dirty_background_ratio?

Типа vm.dirty_background_ratio - если стоит 10% то вообще данные не будут флушится если кэш меньше 10 процентов от всего объема памяти?

Просто моя проблема решается с вызовом - echo 3 > /proc/sys/vm/drop_caches Но есть шанс потери данных.

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

У тебя своп на медленном диске, а ты в двух своих темах докопался до buff/cache. Все это выглядит как борьба ветряными мельницами.
Выше упоминались zswap/zram, как простой способ нивелировать эту проблему.

p.s. И да, не хотелось бы нарваться на продолжение треда, что своп не нужен. :)

p.p.s. Ох уж эти современные прожорливые приложения (!! uksm/ksm):

total 125G used 62g free 12 gb shared 1.3g buff/cache 50G avaiable 59 swap 3.11

vm.vfs_cache_pressure - его в какую сторону крутить? В разных источниках разные вещи говорят.

Я прямо в сообщении написал, в вашем случае хорошо увеличить, с дефолта 100 увеличить например до 200. Нужно читать не «в разных источниках» а в документации. https://sysctl-explorer.net/vm/vfs_cache_pressure/

Вы уже написали что у вас сидит swappiness=1 и это правильно.

vm.dirty_ratio - я так понимаю может привести к фризам? И в чем отличиается от vm.dirty_background_ratio? Типа vm.dirty_background_ratio - если стоит 10% то вообще данные не будут флушится если кэш меньше 10 процентов от всего объема памяти?

dirty_background_ratio это процент памяти занятый грязными страницами файлового кеша, после достижения которого система медленно начинает их вытеснять обратно на диск и освобождать память В ФОНЕ. При этом обычное IO идет параллельно. Тем не менее грязный файловой кеш может превысить этот процент (если вытеснение идет медленнее чем кеширование новых грязных страниц), и когда достигнет до процента dirty_ratio система ОСТАНАВЛИВАЕТ ВЕСь IO кроме тот который скидывает грязный кеш обратно на диск, пока не очистит достаточно кеша.

Разумеется, dirty_background_ratio должно быть меньше чем dirty_ratio; чтобы в начале оно начало вытеснять в фоне, и только если это не поможет вступает в силу жесткий лимит из dirty_ratio.

И да, при над 100GB RAM вам нужно уменьшить их чтобы не были фризы из-за этого. Вам не нужно чтобы система встала колом, пытаясь скинуть 10GB грязный файловой кеш на диски.

Есть ли какой то параметр системы который уменьшает приоритет свопа перед кэшом? Т.е. в случае нехватки памяти система пытается выгрузить весь кэш который только можно и уже только после этого свопится. Ибо 60ГБ кэша стопроцентов можно зафлушить.. Т.е. идея в том что бы жертвовать кэшем в первую очередь использовать своп только тогда когда уже вообще никаких вариантов не осталось.

Как раз об этом и относятся все параметры выше, однако они (кроме swapiness) затрагивают только грязный кеш файловой системы (файлы или директории которые изменены, но еще не скинуты на диск в файловую систему).

Однако, проблему с файлового кеша на чтение это НЕ РЕШАЕТ. Линукс любит все прочитанное с диска оставлять в памяти для повышения производительности read IO. И если вся память забита файловыми кешами на чтение, тем не менее начинает использоваться какое-то малое количество swap-a (пока идет процесс освобождения памяти); после этого swap не очищается автоматически.

Чтобы не забивать память кешами на чтение, единственный выход я вам написал: на все те процессы которые у вас читают большие объемы данных данных с дисков (вплоть до 50-60GB поскольку они забивают память), нужно ограничить память через cgroups. Чтобы они считали что у них память например не более чем 2-4GB, и умещали свои read IO кеши в них.