перенёс swap на zram, заодно расскажу зачем это на маленьком сервере

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

apt install zram-tools
# /etc/default/zramswap: PERCENT=50
systemctl restart zramswap
swapon --show

Смысл не «добавить памяти», а пережить пик без похода на медленный диск. swappiness при этом можно поднять до 100 — свап-то теперь быстрый, в RAM. Файловый свап оставил маленький как аварийный на случай, если и zram кончится. Кто на маленьких серверах — zram или обычный файл, и замечали разницу под нагрузкой?

lexa92 zram на cpu-серверах под модели — вещь, подтверждаю. сжатие почти бесплатное по cpu, а своп в разы быстрее дискового, когда олама на пике лезет за край. только не жди чудес: если модель реально не влезает в RAM, zram лишь сгладит, а не спасёт, всё равно упрёшься. как парашют под пик — да, как «добавил памяти под 14b на восьмёрку» — нет.

lexa92 у меня postgres на 8 гб, поставил zram после наших разговоров про свап — под пиком база теперь не проваливается в дисковый своп так больно. swappiness поднял, как ты говоришь. Но nesterov прав в соседнем треде: это сглаживание, а не решение, я всё равно конекты пулом ужал, чтоб не долетать до края. zram + pgbouncer вместе — вот тогда ровно.

lexa92 глянул zramctl и опять запутался. Там размер устройства отдельно, DATA отдельно, TOTAL отдельно. Большой размер устройства ведь не значит, что у меня столько оперативки уже съедено? А то я увидел цифру и решил, что всё сделал только хуже.

kirill_nsk да, размер устройства — не уже занятая физическая память. DATA показывает объём данных до сжатия, TOTAL — расход памяти с накладными расходами. И сжатие бывает очень разным. Мою фразу выше про «почти бесплатно по cpu» лучше не брать за правило: на своей нагрузке надо смотреть и процессор, и задержки.

kirill_nsk смотри расход памяти и изменения под той же задачей, а не одну большую цифру. Если раньше были подвисания, сравни время ответа приложения, а не только красивое сжатие. Описание счётчиков есть у ядра: zram. Универсальный процент от RAM я бы всем подряд не копировал.

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

kirill_nsk правильный подход с замерами до и после. Единственное, добавь ещё vmstat или iostat в момент нагрузки — если видишь, что si/so (swap in/out) по нулям, а приложение всё равно тормозит, значит zram не при чём и бутылочное горлышко в другом месте. И да, не гонись за идеальным сжатием, главное чтобы latency не проседала.

che32, с zram счётчики si/so тоже отражают обмен со swap-устройством, хотя данные могут оставаться в сжатой оперативной памяти. Нули за короткий интервал говорят об отсутствии обмена в этот момент, а не об отсутствии занятых страниц в swap. Поэтому полезно вместе посмотреть занятый объём, обмен во время нагрузки и задержку приложения.

olga_mac писал:
Нули за короткий интервал говорят об отсутствии обмена в этот момент, а не об отсутствии занятых страниц в swap

Вот на этом сегодня себя и поймал. Встал раньше всех, пока дети спят, глянул домашний сервер: vmstat — si/so по нулям. Сижу с кофе довольный), думаю — ну всё, памяти хватает, zram и не понадобился. А потом ради интереса zramctl — а там TOTAL под сотню мегабайт занято. Страницы лежат сжатые, просто никуда не двигаются. Мой «ноль» был не «всё влезло в RAM», а «осело и молчит».

Привычка осталась с дисковых времён: там si/so выше нуля — уже тревога, диск молотит, всё встаёт колом. С zram эта логика ломается: обмен может идти, а беды нет, потому что молотит не диск, а память. Так что для себя теперь тройкой смотрю — si/so на движение, TOTAL на «сколько осело», и время ответа приложения сверху.

И вопрос вдогонку: если zram забьётся под завязку, а дискового свопа у меня нет совсем — дальше сразу OOM придёт или оно как-то мягче деградирует? Проверять на живом домашнем не хочется, там женины фотоархивы)

che32 писал:
дальше сразу OOM придёт или оно как-то мягче деградирует?

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

Out of memory: Killed process 1823 (ollama)

то есть да, пришёл какой-то oom killer и прибил самое жирное что нашёл)) но у меня тогда свопа не было никакого, ни дискового ни zram, так что может у тебя и правда мягче будет.

и у меня встречный вопрос, я опять куда-то не туда смотрю наверное: а как понять что zram уже под завязку? ждать пока TOTAL дорастёт до размера устройства? я записал свои цифры как lexa92 говорил, у меня TOTAL 40 с чем-то мегабайт при устройстве 512. это типа всё ок или уже пора думать?

olga_mac писал:
Нули за короткий интервал говорят об отсутствии обмена в этот момент

вот тут я завис. che32 я запустил vmstat как ты говорил, минут сорок в эти колонки сидел, их там штук двадцать)) si и so нашёл вроде, у меня нули.

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