ZRam против ZSwap — что лучше и где взять?

Разные решаемые проблемы, разные принципы работы. ZSwap улучшает производительность систем, упирающихся в I/O диска, а не в объём свопа, и в силу тривиальности задачи делает это почти без побочных эффектов. ZRam же пытается «срезать углы» и снизить использование свопа, сжимая память, что в силу непредсказуемой сжимаемости данных работает, ну, непредсказуемо. К тому же, если мя ничего не пропустил, реализация ZRam в Linux всё ещё подвержена проблеме LRU inversion (вкратце: если своп всё-таки пришлось использовать, производительность будет сильно хуже, чем без ZRam совсем).

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

А разве ZSwap не занимается тем же самым - сжатием данных?

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

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

Для ZSwap худший случай - несжимаемые данные, он на них будет впустую жрать процессор, не принося пользы. Для ZRam худший случай - исчерпание места в сжатом буфере, после которого случится lru inversion, и горячие данные начнут вытесняться на медленный дисковый своп, а холодные будут висеть в оперативе, занимая её часть и усугубляя проблему (ZRam реализована как своп, а линукс не умеет «умно» перераспределять данные между разными своп-файлами). Вторая ситуация гораздо печальнее первой.

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

Всё ИМХО, мя могу оказаться тупеньким.

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

Сжатие всегда предсказуемо. Непредсказуема лишь получаемая степень сжатия.

Кто-то еще может просветить?

степень сжатия

Контраргументный контраргумент :|

Когда я год назад изучал вопрос у меня сложилось впечатление что zram это актуальная технология а zswap - её устаревший идейный предшественник.

Но в чистом виде в репозитариях Debian 11 его почему-то не оказалось, нашелся только zram-tools, в составе которого оказался ZSwap.

zram уже есть в дефолтном ядре, ничего ставить не нужно, нужно его только включить. Я сделал так - убрал свап sda2 из /etc/fstab и дописал в /etc/rc.local

/root/startup/zram || echo "failed to start zram!"

#!/bin/sh -e

# https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html

# num_devices is number of /dev/zram0 /dev/ram1 ... devices
# each device compression is single-threaded
modprobe zram num_devices=1

# echo 1 > /sys/block/zram0/reset

# place for data that decides not to be in memory
echo /dev/sda2 > /sys/block/zram0/backing_dev

# size of uncompressed data on zram0
echo 8000000000 > /sys/block/zram0/disksize

# physical memory usage limit
echo 2000000000 > /sys/block/zram0/mem_limit


mkswap /dev/zram0
swapon /dev/zram0 --priority 10

Тут будет создаваться сжатый свап с заявленным размером данных 8ГБ, после сжатия до 2ГБ сжатых данных будет храниться в памяти, а остальное (если случится) - в sda2. Всего на этом устройстве памяти 4ГБ, из них как минимум 2ГБ (4-2) остаётся на несвапнутую память.

вкратце: если своп всё-таки пришлось использовать, производительность будет сильно хуже, чем без ZRam совсем

«без zram» скорее всего на этом месте прибьёт что-нить oom killer-ом или вообще упадёт целиком, т.к. память закончится.

Нет, пока есть место в свопе, оно будет безжалостно жить. Мя рендерил на 40 (нет) гигабайт в свопе, и никто не пришёл.

firkaxВот спасибо за толковое разъяснение! :-)

А как в таком случае быть с параметром swappiness?

По дефолту стояло 60, и swap постоянно был занят, даже доходил до полного заполнения, хотя свободная память реально была.
Поэтому уменьшил swappiness до 10, и swap не теперь вообщене затрагивается, по нулям.

Но это было до использования ZRam. А как быть с ним ?

а остальное (если случится) - в sda2

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

Стабильно раз в месяц эта тема.

ИМХО, zram надо использовать, когда свопить нельзя в принципе (под системой флэш, как на телефонах / харда(свопа) нет вообще), а память экономить надо. В остальном проще использовать zswap.

Ну это разве что если свап раз в 5 (а то и 10) больше реальной памяти. Такие системы конечно бывают, но весьма редко. Ну, ещё может попасться какая-нить очень плохо сжимаемая память, тогда zram тоже проиграет, но это тоже редко.

ZRam в Linux всё ещё подвержена проблеме LRU inversion

А MLRU?

Разные решаемые проблемы

Первый раз про это слышу. Обычно преподносятся как аналоги.

После пары лет периодического изучения арчвики и прочих источников я (и, видимо, много кто ещё) так и не вдуплил в чем сакральная разница. Кроме того, что zram - это сжатый рамдиск с любой файловой системой, хоть linuxswap, хоть ntfs, а zswap - отточен под сжатый swap в ОЗУ.

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

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

Но это было до использования ZRam. А как быть с ним ?

Я у себя его не трогал (дефолтное 60), лень разбираться и вроде и так всё работало.

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

Это, если что, не перераспределение между разными свап-разделами, это backing device внутри zram'а, свап-движку снаружи он не виден вообще.

Mem: 23Gi
Swap: 110Gi

кхе <_<

MLRU

Не знаю, а что это? Гуглится с трудом.

Первый раз про это слышу

Оригинальное исследование!

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

Естественно, совсем новодобавленное вообще мимо свопа ложится, в огрызок обычной памяти.

Так а зачем нужен обычный свап если уже используется zram? Если уж использовать zram, то логично все имеющиеся свап-разделы (если их несколько) превратить в zram backing devices и уже /dev/zramX делать свапами.

Единственная проблема - hibernate перестанет работать если нет обычного свапа. Ну, можно сделать спец-раздел типа swap для hibernate (рассчитывая что как свап он использоваться не будет никогда), в итоге диск чуть больше потратится.

Мя и говорю - разные задачи..

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

Если ещё аналогий, zswap, по-сути, кэш-компрессор перед основным свопом (ну если можно обойтись только кэшем, то почему бы и нет, до собственно свопа и не дойдёт). zram - это в принципе своп и есть, только в RAM (ест-но сжатый иначе какой-бы в этом был смысл).

А как в таком случае быть с параметром swappiness?

в случае использования zram:
100 на старых ядрах
200 на новых

Ну zram не задействует в принципе ничего, кроме ram.

https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#writeback

Это optional feature, которую надо включать и крутить руками.

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

в убунте она включена:
# grep ZRAM /boot/config-5.4.0-100-generic
CONFIG_ZRAM=m
CONFIG_ZRAM_WRITEBACK=y
CONFIG_ZRAM_MEMORY_TRACKING=y

Не знаю, а что это? Гуглится с трудом.

Ошибочка вышла, MGLRU.

Оригинальное исследование!

Наоборот прошу показать исследование.

Много занятного живописали, спасибо! :-)

Так каков же окончательный вывод?

Так каков же окончательный вывод?

По моему, очевидно, что лучше использовать zswap. Это более прямое решение, поэтому его и настраивают.

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

А ZSwap пока на задворках - почему?

юзай zram.
при необходимости можешь добавить writeback.

Различие между zram и zswap проявляется в зависимости от конкретного софта, его способа работы с памятью и взаимодействия с системой. Поэтому вопрос «что лучше» некорректен

Вы политик, что ли? Бла-бла-бла, и ничего конкретного :-)

Для ответа нужен правильно поставленный вопрос. А то вы спрашиваете «кто лучше - мама или папа?» и ждете конкретный ответ. В инете полно статей о преимуществах и недостатках каждого из них, но все они сводятся к одному - пока не поставите и не сравните - никто этого за вас не сделает. А если вы хотите устроить на эту тему холивар - то для этого явно недостаточно фанатов )

ZRam это сжатый своп в оперативной памяти, zswap то же самое + вытеснение в своп на диске (в несжатом виде), когда область в памяти заполнится.

В инете полно статей о преимуществах и недостатках каждого из них, но все они сводятся к одному - пока не поставите и не сравните - никто этого за вас не сделает.

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

Я об этом сразу и написал - нет и не может быть никакого «окончательного вывода». Каждый софт, в каждой отдельно взятой системе по разному использует память и своп. Даже на одном компе в зависимости от текущей загрузки утром может оказаться выгоднее zram, а вечером zswap. А может вообще никакой разницы не обнаружите. Так что бросайте это грязное дело. Zram и zswap используют не от хорошей жизни, а не просто так.

Сказать бросить проще простого.
Но как же можно бросить это дело, если софт постепенно отжирает память и потом наступает коллапс.

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

Для его комфортной работы требуется 16 ГБ, а у меня только 8, нарастить ее невозможно по объективным причинам, вот и приходится выкручиваться всякими костылями.

А ты знал, что в кальке zram настроен по умолчанию уже пару лет как?

Но как же можно бросить это дело, если софт постепенно отжирает память и потом наступает коллапс.

Работайте с настройками. Не должен софт постепенно отжирать память. И очень тяжело представить, что он так написан и ничего с этим не сделать.

Для его комфортной работы требуется 16 ГБ, а у меня только 8, нарастить ее невозможно по объективным причинам, вот и приходится выкручиваться всякими костылями.

На первый взгляд - под ваш случай больше подходит zswap

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

Сначала отвел для swap физической памяти 16 ГБ - через неделю swap дошел до 15 ГБ, коллапс.
Тогда уменьшил swappiness с дефолтовых 60 до 0. Но тогда через некоторое время переполнилась сама память.

Затем уменьшил swappiness до 10, и хотя swap уже не так быстро заполнялся, но через неделю переполнилась RAM.

Вот и задумался о ZRam/ZSwap, что из них лучше подходит для данного случая.

Пока выкручиваюсь ежесуточным ребутом...

Работайте с настройками.

Он замечательно работает с настройками Как дать возможность работать админу?

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

Мля, вспомнил этот топик )

Агонию слегка продлить?

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

На мой взгляд, идеальный вариант - Zram без дискового свопа. Если же дисковый своп имеется, то проще использовать zswap.

eternal_sorrow
Чем конкретно обоснуете свой взгляд?

Да ничем особо. Просто лично мне дисковый своп не нужен. Но совсем без свопа линукс использовать не рекомендуют. Поэтому zram. А если всё же используется дисковый своп, то zswap настроить проще. В простейшем случае никакие дополнительные настройки вообще не требуются, достаточно просто его включить.

Увидел вот такое

zram-hibernate