LINUX.ORG.RU

Zram vs Zswap. Часть 1: практика

 , ,


7

4

Хочу поделиться историей вылезшего косяка настройки свопа.

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

Итак, Raspberry Pi 3, да, до сих пор. Изначально был подключен zram на 400М. Очевидный косяк в том, что он поглощает данные в первую очередь, забивается и всё, выключается из работы, по крайней мере та часть, которая останется невостребованной. В некоторых моих сценариях это может быть полный объём несжимаемыми данными которые будут лежать там мёртвым грузом. Для компенсации этого косяка я разбил zram на 2 участка по 200М и хроном периодически и попеременно высвобождал их. И в целом это работало, система и на холодную, и после высвобождения на какое то время получала пинок под зад.

Но zswap лишён этого недостатка воообще: «мёртвые» данные в сжатом кеше это первый кандидат для сброса на диск, всё как и должно быть. И использование zswap на ноуте с 2Гб памяти показало куда лучшую стабильность произвобительности.

И вот я затеваю эксперимент по пересадке RPi3 на zswap (не сильно просто, ведь у меня там всё ещё самосброное ядро 4.4, опция экспериментальная, нужны пересборки для включения), и получаю неожиданные результаты:

  • Во первых простой прямой свопинг на ssd оказался плавнее и намного стабильнее по лагам. Использование zram только иногда давало прирост производительности, но большую часть времени вызывал лаги и тормоза из за сложных алгоритмов (нагрузка на цпу и очевидно ожидание) и вероятно «мёртвых» данных в оперативке.
  • Во вторых zswap при свопинге на ssd не столько повышает производительность (визуально прироста не видно, вероятно разница проявится в синтетике), сколько снижает i/o и экономит ресурс. Да, во времена hdd обе подсистемы были эффективными ускорителями, но сейчас похоже быстрей скидывать несжатые данные чем сжимать и сортировать их. О чём кстати написано в вике ядра, но туда похоже никто не заглядывает и в статьях это не упоминается.
  • И в третих, оказывается zswap всё таки требует настройки! Не только по используемому алгоритму и объёму буфера, но и по драйверу сжатого буфера (zpool). Есть 3 варианта: zbud (дефолт), zsmalloc и z3fold, настройка через строку параметров ядра при загрузке «zswap.zpool=»
    • zsmalloc должен максимально компактно располагать сжатые страницы в памяти... и не сбрасывать их на диск! Довольно странное решение, мне кажется это вообще противоречит идее zswap.
    • zbud упаковывает в 1 страницу 2 страницы памяти. Пишут что при его использовании степень сжатия памяти в среднем 1,7.
    • z3fold должен паковать до 3 страниц в одну и ожидается степень сжатия до 2,7. По какой то причине z3fold не установлен по умолчанию.

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

Часть 2: тесты

★★★★★

Проверено: maxcom ()

самосборное ядро 4.4

Интересно, а установлен патч le9 или mglru? Иначе все эти zram/zswap полезны конечно, но Thrashing. Просто тогда ждем ядро 6.1.
А насчет несжимаемых данных, вот пример скрипта при 4G RAM, zram с sysvinit (комментарий).

Да и использовать настолько старое ядро… Любое дефолтное «5.+» даст фору этому самосборному, имхо. Механизмы работы с памятью Folios, DAMON, оптимизированный zstd

p.s. Если реальность такова, что памяти впритык, а железка не позволяет расширяться, то надо идти в ногу с прогрессом. :) Плюс выбирать легкие WM и версии приложений, чтобы не свопилось со старта. Да и uksm не помешает:

$ uksmstat -smvv
Shared pages: 541 MiB
krasnh ()
Последнее исправление: krasnh (всего исправлений: 2)
Ответ на: комментарий от krasnh

Thrashing

Я с ним практически никогда не встречаюсь. По сути чтобы его вызвать надо перегрузить оперативку не просто приложениями, а активно работающими невытесняемыми прложениями вроде архиваторов, ffmpeg или виртуалок. Короче научился избегать.

вот пример скрипта при 4G RAM

Это вариант, когда zram имеет собственный физический своп-раздел? Я читал о такой фишке, но у меня ещё нигде нет ядра с такой штукой. Ну и я не думаю что это чем то будет отличаться от работы zswap.

Да и использовать настолько старое ядро…

Ну, обновление ядра потребует обновление загрузчика из за dtb и я потеряю возможность откатиться (по крайней мере это будет довольно сложно), а эта малина находится в режиме жёсткого легаси и не будет обновляться пока я не подготовлю полнофункциональную замену из 4-й. А это не только борьба с протухшим софтом, но и корпус надо соорудить, причём не в версии «кирпич», а в версии «ноутбук». С батарейками.

Если реальность такова, что памяти впритык, а железка не позволяет расширяться

Это сейчас мейнстрим. Память почти везде распаяна, а если её много то всегда находится какое нибудь стадо мамантов, которое не хочется разгонять. Даже сраный андроид в «лёгкой» редакции теперь жрёт 2 гига просто ничего не делая, только показывая ланчер и шторку на 64М оперативки. Линуксы до такого ещё не деградировали, но это только пока.

чтобы не свопилось со старта

Так я и не со старта :-) Другое дело что обычно первым действием после старта является запуск файерфокса с 3-4 вкладками... Да, и так как это одноплатник, то аптаймы у этого файерфокса в среднем от 10 суток и до сколько электрики позволят.

kirill_rrr ★★★★★ ()

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

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

Для компенсации этого косяка я разбил zram на 2 участка по 200М и хроном периодически и попеременно высвобождал их. И в целом это работало, система и на холодную, и после высвобождения на какое то время получала пинок под зад.

Что значит «высвобождал zram»? Может быть высвобождал положенный туда свап?

и вероятно «мёртвых» данных в оперативке.

У zram есть backing device, куда эти данные можно выгружать.

firkax ★★★ ()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

У zram есть backing device, куда эти данные можно выгружать.

Он туда выгружает сжатое или предварительно расжимает, как в случае zswap?

greenman ★★★★★ ()
Ответ на: комментарий от greenman

Не знаю. Сейчас почитал https://docs.kernel.org/admin-guide/blockdev/zram.html - там этот аспект не уточняется, видимо надо исходники смотреть. Мне казалось само собой разумеющимся что выгружаются сжатые. Очень удивлён что zswap их разжимает, этим убивается половина его смысла.

firkax ★★★ ()
Ответ на: комментарий от firkax

Как я понимаю, в случае zswap данные в своп могут попасть и минуя zswap (и если я правильно понимаю, плохо сжимаемые данные он сразу в своп сбрасывает). А признаков, позволяющих понять, сжата та или иная порция свопа, нет. Это надо заметно сам механизм свопа переделывать, видимо.

В случае zram это отдельное блочное устройство, и такой проблемы вроде бы нет.

greenman ★★★★★ ()
Последнее исправление: greenman (всего исправлений: 2)
Ответ на: комментарий от firkax

странное утверждение. zram это просто сжатый виртуальный раздел

Ну разумеется в теме про свопинг имеется в виду своп-радел лежащий на устройстве zram.

Может быть высвобождал положенный туда свап?

Именно.

У zram есть backing device, куда эти данные можно выгружать.

С каких то пор, но не в ядре 4.4. Об этой фишке я узнал где то с полгода назад или меньше. Пока что не планирую сравнивать zswap с zram+backing device.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от firkax

Очень удивлён что zswap их разжимает, этим убивается половина его смысла.

Спорно. Выгрузка на диск из zswap должна происходить более лениво чем решения свопить страницу, очень вероятно что zswap сглаживает лаги от ожидания сброса данных на диск. И в случае ssd явно быстрее поднять с диска уже разжатую страницу чем разжимать сжатую. Кстати это можно как то оттестировать и я наверное попробую.

Хотя возможно всё дело в примитивном алгоритме упаковки по 2 или 3 страницы в одну, и соответственно при запросе одной страницы пришлось бы поднимать с диска сразу 2 или 3, короче проще сбрасывать на диск уже разжатые по одной.

kirill_rrr ★★★★★ ()

По какой то причине z3fold не установлен по умолчанию.

Есть догадки. Прописал, а при загрузке:

zswap: zpool z3fold not available, using default zbud
zswap: loaded using pool lzo/zbud
th3m3 ★★★★★ ()
Ответ на: комментарий от krasnh

Раз пишет что не может подключить значит его не собрали. Хотя остаётся возможность что сначала надо подключить модуль.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от th3m3

У меня работает, ядро 6.0:

$ modinfo z3fold
name:           z3fold
filename:       (builtin)
description:    3-Fold Allocator for Compressed Pages
author:         Vitaly Wool <vitalywool@gmail.com>
license:        GPL
file:           mm/z3fold
alias:          zpool-z3fold


Правда, в нем похоже дефолтно:

[2.249201] zswap: loaded using pool zstd/z3fold


upd. На всякий, у меня pf-kernel.

krasnh ()
Последнее исправление: krasnh (всего исправлений: 3)
Ответ на: комментарий от krasnh

Речь ведь об юбунте?

Да(Xubuntu).

Сюда размещу, мало ли кому понадобится:

sudo su
echo lz4 >> /etc/initramfs-tools/modules
echo lz4_compress >> /etc/initramfs-tools/modules
echo z3fold >> /etc/initramfs-tools/modules
update-initramfs -u

Потом в grub в GRUB_CMDLINE_LINUX_DEFAULT прописал:

zswap.enabled=1 zswap.compressor=lz4 zswap.zpool=z3fold

Теперь работает.

th3m3 ★★★★★ ()

zswap в связке с дисковым свопом, zram годится только как самостоятельный своп без дискового свопа. я пришёл к такому выводу.

eternal_sorrow ★★★★★ ()

какие настройки подкручивались для zram? с дефолтными sysctl zram, имхо, нерабочий

плюс zram можно (а иногда и нужно) использовать вместе с обычным swap, просто с другим приоритетом

whereisthelinus ()
Последнее исправление: whereisthelinus (всего исправлений: 1)
Ответ на: комментарий от whereisthelinus

По кочану. Умеет ли zram сбрасывать данные в дисковый swap без декомпрессии?

eternal_sorrow ★★★★★ ()
Ответ на: комментарий от whereisthelinus

swappiness 100, lz4, размер 2*200 Мб, приоритет разумеется повышен относительно диска. /proc/sys/vm/min_free_kbytes = 64Мб. Больше ничего, да там вроде и нет ничего больше.

sysctl zram никогда не пользуюсь - не люблю ненужных прослоек. А конкретно на этой RPi3 его вообще нет.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от whereisthelinus

Потому что при работе с памятью прослойка виртуального блочного устройства - лишняя. Она создаёт проблемы и для их исключения собственно и был создан zswap. Изначально zram был костылём на коленке, собранным из совершенно друго подсистемы.

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

kirill_rrr ★★★★★ ()
Ответ на: комментарий от whereisthelinus

если это не поможет, то надо выкручивать swappiness больше 120 или даже 150 (100 - это для обычного(!) swap на ssd, стандартные 60 для hdd)

whereisthelinus ()

Данные сжимаются, но если сжимаются плохо, то сбрасывается не сжатая копия, логично же.

drl ()
Ответ на: комментарий от kirill_rrr

Но по какой то причине, видимо по инерции, в zram был добавлен свой собственный физический свопинг.

На раздел/файл или еще куда оно свопится?

ex-kiev ()
Ответ на: комментарий от ex-kiev

С CONFIG_ZRAM_WRITEBACK zram может записывать простаивающие/несжимаемые страницы в резервное хранилище, а не хранить их в памяти. Чтобы использовать эту функцию, администратор должен настроить резервное устройство через:
echo /dev/sda5 > /sys/block/zramX/backing_dev
На данный момент он поддерживает только разделы.

https://docs.kernel.org/admin-guide/blockdev/zram.html#writeback

upd. Но в дефолтных ядрах вроде не включена. В pf-kernel:

$ zgrep CONFIG_ZRAM_WRITEBACK /proc/config.gz 
CONFIG_ZRAM_WRITEBACK=y
krasnh ()
Последнее исправление: krasnh (всего исправлений: 1)

Ну ладно, я догнал наконец-то, zswap это типо фс, а в zram создаётся обычный swap раздел у которого нет сжатия.
Попробуй тогда одновременно оба zswap в оперативке и на диске.

drl ()
Ответ на: комментарий от whereisthelinus

Не знал о них. Насчёт page-cluster согласен, так должно быть лучше.

Насчёт watermark_scale_factor не понятно, в первую очередь по официальным пояснениям. В другом источнике пишут:

vm.watermark_scale_factor. По умолчанию его значение 10, это означает, что воркер ядра, ответственный за выгрузку памяти в своп, включается только тогда, когда осталось всего 0,1% свободной физической памяти и в нашем случае, при интенсивном выделении памяти, этого оказалось катастрофически мало...
Максимальное значение этого параметра 1000, что равно 10% свободной физической памяти, но такое значение я рекомендую выставлять только при медленном свопе и малом объеме памяти. На машине со свопом на SSD будет более чем достаточно значения в 5000. Собственно, именно при таком значении моя проблема была полностью решена. Теперь машина может лишь изредка фризить при активном задействовании свопа, что совершенно нормально!

А в третих: это некий коридор между максимальным и минимальным значением, но тогда дефолт в 0,1% это вообще ни о чём и просто невменяемо.

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

дефолт watermark_scale_factor действительно странный, но он нормально работает со swap на hdd (под него всё исторически и заточено), а вот zram «ломается» если начинает работать только в «самый последний момент»: в конце концов странички памяти после сжатия кладутся обратно в память, и нам необходимо иметь хоть какой-то её запас (например 5%), заодно повышается объём перемещаемой за раз памяти ram->swap (ram->compressed ram в случае zram) и у нас выше шансы почувствовать эффект от сжатия, а не дождаться чего-то неприятного из-за полного исчерпания памяти

whereisthelinus ()
Ответ на: комментарий от whereisthelinus

Но не сходятся 2 вещи: во первых на практике при дефолтных настройках ядро пытается держать свободными 5-7% памяти. В смысле совсем свободной, даже без кешей и буферов. И активный свопинг начинается как раз когда загрузка касается этой памяти. Ну и в случае hdd тоже лучше начать свопиться пораньше, а на ssd можно позволить себе ждать до полседнего момента.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от ex-kiev

Не использовать свап-раздел напрямую, а отдать его под backing dev.

// Давно бы уже по дефолту включили в ядро, блин

devl547 ★★★★★ ()
Ответ на: комментарий от kirill_rrr

Я делаю ставку что перегон zswap из озу в диск не будет пережимать, но с zram так делает.
Но несжимаемые данные да будут страдать ерундой.

drl ()
Ответ на: комментарий от drl

В случае ssd блоками по 4К очень вероятно, что поднимать данные с диска быстрее уже разжатыми. А если быстрее, то и фризы должны быть меньше. Короче кто кого - реально тестировать надо (а я пока не могу). Просто без backing_dev zram определённо сливается.

kirill_rrr ★★★★★ ()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

поднимать данные с диска быстрее уже разжатыми

Есть такое семейство дистров - Puppy Linux (а также другие, на том же принципе). Так там одной из киллер-фич считается именно чтение данных в сжатых образах/модулях (squashfs), что дает преимущество на HDD (на SSD наверно не так заметно).

Там конечно не все так однозначно, ) еще надо учитывать наличие aufs/overlayfs.

krasnh ()
Последнее исправление: krasnh (всего исправлений: 1)
Ответ на: комментарий от krasnh

Там потоковое чтение образа, а на 4К блоках можно налететь на чтение-разжатие-чтение-разжатие. Куча прерываний, низкое кпд.

kirill_rrr ★★★★★ ()
Ответ на: комментарий от AlexM

Современное состояние обработки нехватки памяти в линуксах: MGLRU и le9 патчи и юзерспейсные киллеры (комментарий)

Как это все выглядит на практике, можно почитать в статье от ValdikSS и даже скачать iso и запустить в вирте с низким «-m», в качестве эксперимента.
Речь там об le9, который схож с MGLRU по принципу действия.

krasnh ()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.