Настройка ZSWAP/ZRAM

ИМХО в ZRAM больше смысла. Впрочем, они и совместно могут существовать. swappiness и прочий тюнинг, если точно не уверен, что оно надо, то лучше не трогать. Он и по дефолту нормально выставлен.

У меня конфиг вот такой на слабых машинах (и Raspberry)

#!/bin/sh

CORE_RAM_SIZE=512 #сколько хочется свопа (в рассчёте на кол-во ядер-1)
CORES=`nproc`

modprobe zram num_devices=$CORES

CORES_NUM=`expr $CORES - 1`
for i in `seq 0 $CORES_NUM`; do
    echo $(($CORE_RAM_SIZE*1024*1024)) > /sys/block/zram$i/disksize
    mkswap /dev/zram$i
    swapon /dev/zram$i -d -p 10
done

запускается systemd-ой

[Unit]
Description=Enable and configure ZRAM 
ConditionFileNotEmpty=/root/zram.sh
After=network.target #впрочем не обязательно после network, но у меня "работает не трогаю"

[Service]
Type=forking
ExecStart=/bin/sh '/root/zram.sh'
TimeoutSec=0
RemainAfterExit=yes
GuessMainPID=no

[Install]
WantedBy=multi-user.target

echo $(($CORE_RAM_SIZE*1024*1024)) > /sys/block/zram$i/disksize

Вообще то принято делить SIZE на кол-во zram-ов.

Вообще то принято делить SIZE на кол-во zram-ов.

Ну так здесь и создаётся ZRAM (512 * ($CORES_NUM-1)) Мб.. Ну да, коммент может ввести в заблуждение, что это итоговый размер, согласен. Но я же написал, что «в рассчёте на …»

1024*1024 - это просто приставка Мега (там же байты надо указывать).

Или что-то другое имелось ввиду?

что это итоговый размер

Да не. Обычно берётся итоговый размер, рубится и прописывается получившаяся порция.

А, понял о чём речь. Да, в принципе можно и так переписать, согласен. Будет даже несколько поудобней.

Ну, уж как написал. В общем-то, тоже работает. А ТС волен написать как ему больше нравится. Переделать на вариант с делением нетрудно.

Будет даже несколько поудобней.

И да, и нет. Просто так принято. Но тут возникает вопрос: А какой суммарный объём пользовать? В автоматических скриптах тупо берётся полный объём памяти (исходят из того, что даже в худшем варианте это будет занимать не всю память). Но это тоже «вилами по воде». Менее плохой вариант - индивидуальный выбор небольшого размера (чисто для ускорения) с большим приоритетом + обычный свап с низким приоритетом.

Насколько я понимаю, вводить множество /dev/zram$i — уже устарело.

«There is no single-compression-stream mode anymore, unless you are running a UP system or has only 1 CPU online.»

Ну разве что из таких соображений.

А какой суммарный объём пользовать?

Меня до сих пор интересует этот вопрос. Пишут везде по разному и единого мнения лично у меня не сложилось. Делаю чтобы ZRAM суммарно был в половину RAMы. Если и так не хватает, то ещё добавлял swap-файл с меньшим приоритетом.

По принципу, нет необходимости - не используем. т.е. хватает RAM - отлично (поэтому и пополам), не хватило, но влезло в ZRAM - замечательно, всё равно не влезло - ну медленно и печально свопим на диск.

Советую zswap и эту утилиту настройки.

Делаю чтобы ZRAM суммарно был в половину RAMы.

у меня zram равен объёму оперативки.

Ещё есть zramctrl, (если не доступен возможно просто в пути нет папки /sbin), там можно смотреть сколько реальной памяти занимает zram.

$ zramctl
NAME       ALGORITHM DISKSIZE   DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram1 lzo         989,4M 226,2M 54,8M 57,4M       4 [SWAP]
/dev/zram0 zstd          500M   444M    9M   10M       4 /var/log

у меня zram равен объёму оперативки.

И в «плохом» случае наносишь «удар» по буферам накопителей. Сомнительный, крайне сомнительный поступок.

Смысла в zram не вижу, особенно в комбинации zram и обычный swap.

Использую zswap c compressor=zstd и zpool=z3fold, всё остальное по дефолту. Сжатый буфер перед swap.

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

Смысла в zram не вижу, особенно в комбинации zram и обычный swap.

Предотвратить, или хотя бы максимально отсрочить дисковый swap. Разве нет? zswap хоть и сжатый буфер, но всё равно свопит на диск.

Разве нет?

Поменьше мифов, господа. За усё есть цена. На обычном свопе система вполне работоспособная, только медленная. Второе не отменяет первое. ZRAM в отличии от ZSWAP гораздо «хитрее» и накладных расходов там поболее. Так что зачастую ZSWAP гораздо эффективнее.

Предотвратить, или хотя бы максимально отсрочить дисковый swap.

Zswap этим и занимается.

Zram - смысл в нем только в бездисковых системах. Даже для (сжатых) ram-fs, думаю, лучше использовать комбинацию tmpfs+zswap - пусть система сама разрулить, что сжимать и скидывать на диск.

в zswap всегда больше смысла, zram вообще в ядре остался для каких-то странных экспериментов

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

насколько важны данные

Ба! Всё-таки затронули вопрос надёжности. Обычно ведь конкретно игнорят (а во многих случаях намеренно замалчивают), хотя на ЛОРе много тем о проблемах с памятью, которые приводят к крашу всей системы. И ZRAM, по сравнению с ZSWAP, в этом плане в полном ауте.

вообще я подразумевал LRU, но ладно

Установите и запустите zram-tools (есть во многих дистрибутивах). Если настройки по умолчанию не устроят — настроите по-своему.

vm.swappiness рекомендую оставить на стандартных 60, а вот vm.watermark_scale_factor установить в 200, чтобы за раз сразу много данных перемещалось в своп или из свопа.

vm.watermark_scale_factor установить в 200, чтобы за раз сразу много данных перемещалось в своп или из свопа

Отличный совет. На самом деле с этот фактор позволяет резервировать объем файловых страниц пока есть возможность вытеснять в своп анонимные. Резервирование файловых страниц соответственно уменьшает thrashing.

с zswap имеет смысл, начни со стандартных рекомендаций. А насколько zswap это мощно, прекрасно реализовано в chrome os, где на трех гигах и 50 вкладок летают, в linux увы эффект послабее.

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

А насколько zswap это мощно, прекрасно реализовано в chrome os, где на трех гигах и 50 вкладок летают, в linux увы эффект послабее.

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

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

/sys/module/zswap/parameters/same_filled_pages_enabled:Y /sys/module/zswap/parameters/enabled:N /sys/module/zswap/parameters/max_pool_percent:20 /sys/module/zswap/parameters/compressor:lzo /sys/module/zswap/parameters/zpool:zbud

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

Да и на десктопе было бы неплохо, чтобы они суспендились при нехватке ОЗУ, если они ничего не воспроизводят и не содержат форм с набранным текстом.

Уж явно лучше, чем насиловать своп.

Как там на хромиуме, ничего такого не внедрили еще? Сто лет его не запускал.

50 вкладок летают

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

Очевидно, имеются в виду дефолты.

Плюс у хромомос свои патчи, не вошедшие в ядро https://lore.kernel.org/patchwork/patch/222042/

Очевидно, имеются в виду дефолты.

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

Без тебя никто не знал о базе. Поведай тайное знание теперь о MacOS, что это семейство юникс.

Бред какойто. У меня тоже есть ноут.

Это что за поток сознания? Можно на человеческий перевести?

Ниче не понимаю...

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

единого мнения лично у меня не сложилось

Единого и не может быть.

Анон рекомендует zram disksize = 2MemTotal.

Она никогда не была гентой. Использование портажа не делает дистрибутив гентой.

Как там на хромиуме, ничего такого не внедрили еще? Сто лет его не запускал.

В Edge (который основан на хромиуме) есть такое.

не понял.
там написано: «On ChromiumOS, we do not use swap.»
как это согласуется с этим: «А насколько zswap это мощно, прекрасно реализовано в chrome os...»?

ФФ вроде такое умеет.

On ChromiumOS, we do not use swap. - это цитата из 2010.

зрам появился позже и немедленно начал использоваться с disksize=1.5*memtotal

Количество zram нынче - 1. Потому что zram научился в могопоток, и больше не нужно плодить по zram на ядро. Просто кое где всем наплевать чему он там научился и умолчальные настройки дистрибутивов годами не меняют. Хуже он от этого впрочем работать не начинает, просто выглядит некрасиво.

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

ftfy

Там выше, товарищ про zswap говорил, а не про zram.

Я тоже юзаю 1 девайс.
Но вот Кто-то из лоровцев кидал пруфов что недоучился он в многопоток.

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

А насколько zswap это мощно, прекрасно реализовано в chrome os, где на трех гигах и 50 вкладок летают

в хором ос используется zram, а не zswap

Но вот Кто-то из лоровцев кидал пруфов что недоучился он в многопоток.

https://github.com/zen-kernel/zen-kernel/issues/223#issuecomment-897022209

Это пруф?

См выше. Пруфы ли это?

Оф док, кстати:

Regardless of the value passed to this attribute, ZRAM will always allocate multiple compression streams - one per online CPU - thus allowing several concurrent compression operations.

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

Это пруф. Благодарю.

А это то самое о чём я говорил. Но пруф выше убедил меня что количество потоков компрессии больше одного в один девайс не отменяет блокировку самого свап девайса. Так что несколько зрам девайсов выгоднее одного, I got it, благодарю.