Хочу поделиться историей вылезшего косяка настройки свопа.
Я до сих пор гоняю в качестве десктопа железки с очень малым объёмом памяти и соответственно очень активно своплюсь. Раньше для этоого использовал традиционный и более распиареный 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 не установлен по умолчанию.
Кстати, с учётом поведения этих драйверов напрашивается вывод: более тяжёлый алгоритм сжатия не обязательно проявит себя лучше.
