Минусы выставления большого zram и маленького swappiness?

Какие ещё сжатые страницы из zram на диске?

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

Если он кроме zram сделает ещё и дисковый свап - то, в зависимости от приоритета, страницы памяти будут либо класться в него вместо zram, либо класться в него когда zram закончится. Но сам zram никогда на диск не попадёт.

признание америки… москвашвея… москвашвей… примус… пивная, еще парочку…

1)

root@RPi4:~# ./zswap-stat.bash 
/sys/kernel/debug/zswap/stored_pages: 239877
/sys/kernel/debug/zswap/pool_total_size: 371785728
2.64274854574299

Это у меня считающийся сейчас устаревшим z3fold при пуле в 25% от 3,7Гб. Сейчас степень сжатия 2,6, но иногда может падать до 1,6.

2) Конечно отправляются. Можешь рассматривать zswap как аналог дискового кеша перед записью на своп. Страницы формально адресованы блокам на диске, но находятся в сжатом пуле пока или будут дёрнуты обратно, или пул не заполнится на условные 90% и не начнёт «очищаться» сбросом на диск. Метод выбора конкретных страниц по сути не важен, тут главное что горячая страница не улетит на диск слишком быстро, а с огромной вероятностью успеет разжаться обратно до этого.

В zswap не так давно (по версиям ядер) произошла некоторая революция. Старые пулы zbud и z3fold удалены, самый старый и бесполезный пул zsmalloc был переписан на новую реализацию и стал скорее даже лучше двух других. Появилась включаемая опция работать без физического свопа и оптимизированы алгоритмы сбрасывания при заполнении. Так вот, у меня ядро 6.1, все эти последние плюшки в жёстких сценариях я ещё не видел. По идее должно стать только лучше.

Да, обратил внимание что ты говоришь про работу без физического свопа. Это ведь совсем другой сценарий чем с физическим. Для него действительно лучше взять zram не очень большого размера, 30-100% несжатой памяти. zswap должен был научиться работать в таком режиме, но нужно внимательно смотреть та у тебя версия или нет, ну и включить опцию.

Как раз браузеры тот самый сценарий, когда лучше ставить 100-150. Процессы вкладок свопятся прекрасно, а основная нагрузка на диск ложится на работу с кешем страниц на диск и базами данных. Ну и там действительно может запускаться по 10 копий чего нибудь в минуту.

Сколько должен весить оптимальный файловый кэш? У меня кэш даже с сваппинесс 10 2.4 Гб из 8 занимает.

Никто не знает! Кстати, где то с ядра 6.1 началась череда серьёзных изменений в планировщике памяти. Конкретно в 6.1 это приводило к факапам когда 20% оперативки вообще стояло пусто, даже без кеша. Часть настроек поменяли свои значения, появились новые и теперь приходится регулировать малопонятные веса и агресивность чего нибудь. Я даже не стал особо вникать и рекомендую загуглить максимум всяких настроек на тему памяти, прочитать официальную документацию к данной версии ядра, а потом прогнать какие нибудь тесты. Не думаю что поведение ядра прям совсем устаканилось.

В данной проблематике важнее понимать, что даёт наилучшее качество жизни — и это не тюнинг своппинга и даже не сжатие ОЗУ, а именно запрет вытеснения важных библиотек.

Он отойдёт от компьютера, а у него какой-нибудь процесс за 10-15 минут нашарашит полные штаны свопа на диске, хоть ты обнастраивайся этого сваппинеса и наобжимайся zram — в итоге кирпич.

Так, и что, что ты хотел этим сказать?

Еще раз: ты пришел в тред, вбросил что zram лажа и ненужно (почему не нужно, кому не нужно? тебе?). Ты не осилил настроить OOM киллер и поэтому у тебя система «вставала колом», но плохой конечно zram. И в конечном счете заявил, что при достаточном количестве оперативки своп вообще ни к чему, так вот у меня вопрос — ты достаточно понимаешь в том, как работает управление памятью в ядре, чтобы делать такие заявления? Тогда приведи аргументы в пользу своего утверждения.

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

Вот 3,3Гб это дофига? А когда на этой машине используется 10Гб памяти суммарно - это вредно или хорошо что оно работает и даже без серьёзных проблем? Или классические тесты на компиляцию, когда на глаз ничегоне понятно, а время сборки уменьшается?

смотри как это работает: памяти 2 гига - система свопится и тупит потому что памяти мало, в таких случаях использовать zram бесполезно…

Небольшой нюанс: система свопится и тупит потому что памяти мало... но только после того, как ты использовал 4Гб. У тебя всего 2, но ты можешь использовать 4 до появления тормозов. Полная бесполезность!

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

Нет. Не как быстро, а какие именно.

rrr@RPi4:/tmp $ free -m
               total        used        free      shared  buff/cache   available
Mem:            3794        1908         395         946        1489         916
Swap:          38145        1062       37083

С поправкой на то что в shared также прячется виртуальная видеопамяь. Короче «использовано» на самом деле used+shared. Плюс внутри buff/cache ещё валяется знатный кусок кеша браузера в tmpfs.

Я бы не переоценивал. За исключением некоторых сценариев или микроСД вместо диска 60 сваппинес ничем не отличается от 150. В конце концов для ссд может быть проще 5 раз перечитать либу чем пережевать запись разрозненных страниц в своп.

Хз. Включил zram, выделил 90% оперативки, хуже не стало в общем. И swappiness 10 тоже. Ноут скорее как иногда пишущая машинка или серфинг с экраном пошире, иногда компиляция, которая сама имеет свое кэширование и не сказать что долгая (если не андроид). Тут только узнал, что похоже размер zram не относится к максимальному размеру раздела и может быть больше 100% оперативки.

Спасибо! По первому пункту всё понятно, от 2 до 3 раз. Да, в случае 1-2GB машина превращается, за счёт CPU, конечно, в типа 2-6GB. Если CPU не совсем дохлый, то от почти нерабочей до почти рабочей машины.

По второму пункту мне пока не всё очевидно. Страницы из обычной памяти попадают в zram и там хранятся вперемешку. Не ясно, что будет, если применять ту же стратегию, что и для ram, LFU, или что там сейчас модно. Если бы не было сжатия, то да, это просто кэш для диска. А здесь одна страница zram может хранить две-три частичные страницы ram с разной частотностью использования.

Да, интересно!

3,3Гб это дофига

нормально

10Гб памяти суммарно

то есть примерно 7 гигов было пережато и сидело в памяти которой не хватает? а сколько физически занимает места в такой зрам… я пробовал зрам на двух гигах и пришлось свопу вернуться, под зрам отводил 1\2 ram

Такую штуку надо для GPU забабахать. Там память подороже DRAM будет, значит и ROI повыше. Имеет смысл, только боюсь там и так вся память сжатая.

1/2 ram слишком мало для какого-то видимого эффекта Получается 1Г в zram займет порядка 300М в ram итого 2Г - 300И + 1Г 2,7Г, +700М Настрой на 4Г zram, это будет 700М ram + 4Г в zram swap итого 4,7Г, +2,7Г

Swap:          38145        1062       37083

не понимаю что означают эти цифры? у меня зрам был настроен 1\2 ram и это строчка выгдядела как то так

Swap:          1024        0       1024

после того как зрам забился так

Swap:          1024        1024       0

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

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

1/2 ram слишком мало для какого-то видимого эффекта

вот зрам равный 1\2 ram c 4 гигами

$ free -m
               total        used        free      shared  buff/cache   available
Mem:            3915         797        2537          37         830        3118
Swap:           1957           0        1957

а вот инструкция https://www.altlinux.org/ZRAM/ZSWAP где

#COEFF=1024 # Использовать ОЗУ полностью (за счёт сжатия получится меньше половины).

надо попробовать врубить на всю катушку и на 1 гб это обкатать

$ free -m
               total        used        free      shared  buff/cache   available
Mem:             960         583          73          24         462         377
Swap:            960          15         945

это зрам которому выделено 100% ram на 1 гб, запущен браузер, открыта вкладка лора, видно использование уже пошло

$ free -m
               total        used        free      shared  buff/cache   available
Mem:             960         772          64           7         263         187
Swap:            960         462         497

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

Это старые дефолты. В хромомос гугл вообще 200% использует в конфигах в 4гб и 1:1 в конфигах с 8 гб

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

Винчестер тоже можно забить под завязку

то есть примерно 7 гигов было пережато и сидело в памяти которой не хватает?

Я использую зсвоп а не зрам. Без сжатия вообще память распределилась бы так: 3Гб в оперативке 7Гб на диске. С зсвоп при классическом 40% пуле она распределилась так: 1,8 несжатой оперативки, 1,2гб сжатого пула, где хранится 3,12гб. А на диске всего 5,08гб. Причём не всего подряд а наиболее холодных страниц. Так что выигрыш в скорости обращения к данным всего 27%, но вот выигрыш в скорости сброса на диск минимум в 2 раза. С учётом скорости алгоритма lz4 можно смело пренебрегать разницей между обращением к несжатым страницам и тем что в сжатом пуле.

я пробовал зрам на двух гигах и пришлось свопу вернуться, под зрам отводил

А как именно ты его настравал? Ну там же реально можно как много выиграть так и много проиграть.

что означают эти цифры?

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

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

Дай угадаю, ты не поставил физического свопа? Да, разумеется всё резко встаёт и там уже как (не)повезёт. Используя zram ты должен был взять объём х2++ от объёма оперативки, настроить backing_dev с лимитом памяти в 20-50% и возможно ещё и подключить физический своп если нужна гибернация.

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

FYI:

Непонятки с zswap (комментарий)

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

Я использую зсвоп а не зрам

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

Дай угадаю,

не угадал - при использовании зрам своп отключать нужно

Используя zram ты должен был взять объём х2++ от объёма оперативки

это как? я вначале использовал 1/2 ram, а вчера для пробы на 100% ram перешел и оно с 1 гигом опертивы и 1 гигом зрама насрало в зрам 700 мб и все равно колом встало, а с 4 гигами свопа 1 гиг оперативы хоть и свопится постоянно, но колом система не встает, да когда пожрет 4 гига - встанет, но их будет горадо дольше жрать чем зрам расположеный в 1 гб памяти.

не угадал - при использовании зрам своп отключать нужно

Это кто тебе сказал?

Используя zram ты должен был взять объём х2++ от объёма оперативки

это как?

Ну ты палец к носу приложи и посчитай: сколько с твоим средним коэффициентом сжатия в zram будет занято физической памяти.

Вы это точно знаете? Я как раз про это и спрашивал вверху и ответ был однозначен - zram страницы откачиваются в disk swap так же, как и обычные рам страницы. Мне это странно. Вы говорите, что zram страницы вообще не откачиваются. Это имеет больший смысл. Однако тогда возникает вопрос. Получается, что вместо линейной трёх уровневой процедуры рам - zram - disk swap порядок по мере увеличения времени доступа, мы имеем двух уровневую рам - или zram или disk swap. zram не попадает в disk swap никогда.

Вопрос. Что определяет, откачивается ли страница в zram или disk swap? По threshold после попадания в zswap начинает попадать в disk swap и наоборот, если слишком часто мигрирует в disk swap, то начинает попадать в zram?

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

коэффициентом сжатия

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

Главное отличие от zswap , как я понял в том, что после окончания места zram не вытесняет ранее сжатые страницы кэша, а просто скидывает новые данные уже в физический своп. В отличии от zswap, где есть некий алгоритм, для выкидывания на диск наиболее неиспользуемых страниц, а горячие страницы оставляет сжатыми в рам. Да, с версии ядра 7.0 zram может скидывать страницы в сжатом виде, раньше распаковывал.

Ну, исходники я не анализировал.

Дело в том, что zram, сам по себе, про свап ничего не знает. Это просто блочное устройство, хранящееся в сжатой памяти. Можно сделать mkswap /dev/zram0 и swapon /dev/zram0, тогда это блочное устройство, на совершенно общих основаниях, будет использоваться для свапа. То есть вот есть какое-нить /dev/sda2 и есть /dev/zram0 - для свап-движка разницы между ними нет (но есть разница для гибернации - оно как-то их отличает и zram использовать не пытается). Если бы сжатая zram-память могла сама попадать в свап, то она бы и сама в себя могла попадать по второму кругу, что явно приводит к какой-то чуши и такое бы делать не стали.

Что касается трёх уровней, то у zram есть backing_dev - некое ещё одно блочное устройство, которое уже в драйвере zram назначено ещё одним уровнем. Как именно оно работает, я не разбирался, было лень, но вроде там что-то на тему «туда можно положить данные которые плохо сжимаются». Возможно, просто прописать устройство недостаточно и надо ещё что-то настраивать.

Вопрос. Что определяет, откачивается ли страница в zram или disk swap?

Точно так же, как если сделать два свапа на дисках (sda2 + sdb2) - по приоритету. Сначала заполняется тот у кого максимальный приоритет, а когда в нём кончается место - следующий за ним. Приоритет можно задавать ключом -p у swapon или смотреть в /proc/swaps.

после попадания в zswap

zswap - это не zram, это другой драйвер. Я не изучал как он работает.

Никто не запрещает создать своп файл и настроить приоритет в zram, так после окончания места в zram будет использоваться физический своп. И настрой уже ООМ киллер, чтобы он убивал твой говнобраузер в случае чего https://github.com/rfjakob/earlyoom

И настрой уже ООМ киллер

Инженеры: придумали катапульту, чтобы сохранить доступность системы в крайнем случае.

Операторы локалхоста: давайте кататься на ней каждый день!

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

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

Объясни это гражданину @amd_amd, это у него система колом встает от двух вкладок в браузере.

система колом встает от двух вкладок в браузере

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

Собственная память zram не является ни anonymous memory, ни page cache — не может быть вытеснена в swap.

Что определяет, откачивается ли страница в zram или disk swap

zram — просто блочное устройство, поверх которого можно сделать в том числе swap. При наличии физического swap порядок записи определяется приоритетами swap. В случае zram backing device — решать zram.

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

Вот эта часть мне как раз не понятна. Есть три типа страниц. Первый - страница рам находится в рам. Второй - страница рам находится в zswap. Третий - страница рам, принадлежащая zswap, сжатые страницы рам. Вы говорите, что с версии 7.0 страницы третьего типа тоже могут перемещаться в disk swap. Вопрос, алгоритм вытеснения страниц третьего типа оперирует с ними как будто они обычные страницы рам, или там всё сложнее и используется анализ их содержимого и частоты доступа?

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

Вы говорите, что с версии 7.0 страницы третьего типа тоже могут перемещаться в disk swap.

Нет, не в swap. В zram backing device.

Студент вам уже не поможет.

Дело в том, что zram, сам по себе, про свап ничего не знает. Это просто блочное устройство

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

Ещё один очень важный вопрос, а что, если я использую Unified shared memory и хочу иметь доступ к данным в zram из других устройств на PCIe шине, скажем из графического процессора или сетевой карты?

Вопрос. Что определяет, откачивается ли страница в zram или disk swap?

Точно так же, как если сделать два свапа на дисках (sda2 + sdb2) - по приоритету. Сначала заполняется тот у кого максимальный приоритет, а когда в нём кончается место - следующий за ним. Приоритет можно задавать ключом -p у swapon или смотреть в /proc/swaps.

После пояснения про блочное устройство, теперь понятно, спасибо!

после попадания в zswap

zswap - это не zram, это другой драйвер. Я не изучал как он работает.

Это опечатка. Имелось ввиду zram.

Не. То не %. То приоритет, который максимум около 200. Ядро линукса написано криворукими дебилами ни чем не лучше индусских говнокодеров, налаьавших винду в перерывах между поеданием карии молитвами кришне

Собственная память zram не является ни anonymous memory, ни page cache — не может быть вытеснена в swap.

Тогда закономерный вопрос, который я уже задал выше. Что будет, если я работаю в условиях USM, и внешнее устройство запросило доступ к памяти с адресом, который оказался в zram? Будет сначала мигрировать в рам?

zram — просто блочное устройство, поверх которого можно сделать в том числе swap.

Да, спасибо, на это firkax тоже указыает.

Студент вам уже не поможет.

Почему, я не обучаемый?