Debian 13: ZRAM/Zswap — коли вони рятують систему і коли шкодять

Ментальна модель: що насправді роблять zram та zswap

ZRAM: стисканий блочний пристрій у RAM

ZRAM створює блочний пристрій, що живе в пам’яті (наприклад /dev/zram0), і дозволяє ядру трактувати його як пристрій підкачки.
Коли ядро вирішує витіснити сторінку, вона може потрапити в zram, стиснута.
«Диск» — це пам’ять, але ви отримуєте ефективну ємність завдяки стисненню сторінок. Платите ви за це CPU-циклами.

Мисліть про zram як «swap без диску», що звучить парадоксально, поки не згадаєте: сторінки часто стискуються (заповнені нулями, повторювані дані, старі об’єкти купи, кешований JSON, який не варто було зберігати тощо).
У кризі стиснути 4 GiB холодних сторінок до 2 GiB RAM — це виграш. Стиснути 4 GiB до 3.9 GiB — лише дорога нажаль.

Zswap: стиснений кеш перед реальним swap-пристроєм

Zswap відрізняється. Це не swap-пристрій. Це кеш для витіснених сторінок, збережених стисненими в RAM, що стоїть перед вашим реальним свопом (розділом або файлом).
Коли сторінки витісняються, zswap намагається тримати їх стисненими в пам’яті. Якщо пул zswap заповнюється, він викидає сторінки на реальний swap-пристрій.

Це робить zswap «зменшувачем записів» і згладжувачем латентностей: менше записів на SSD/HDD, менше випадкових IO під тиском, кращі хвостові латентності під час трешу.
Але він все ще залежить від наявності адекватного swap-бекенду. Немає пристрою swap — немає страховки zswap.

Операційна різниця, яка має значення

• zram може замінити дисковий swap на невеликих системах або стати «швидким шаром підкачки» перед диском, якщо ви зберігаєте дисковий swap.
• zswap — це кеш; він зменшує IO при свопінгу, але не замінює загальну ємність swap.
• Обидва — це форми торгівлі CPU за пам’ять. На сучасних CPU ця угода часто вигідна. На завантажених системах вона може бути руйнівною.

Парафразована ідея часто приписувана Jim Gray: «Виміряйте перед тим, як налаштовувати; більшість налаштувань — це здогадки без даних.»
Стиснення пам’яті — ідеальний приклад. Легко бути хитрим. Складніше — бути правим.

Жарт №1: Стиснення пам’яті — наче вакуумна упаковка шафи. Працює чудово, доки вам не знадобиться та рубашка під час тривоги.

Факти та контекст: як ми дійшли до цього (і чому це важливо)

Трохи контексту перетворює «довільне крутіння регуляторів ядра» на інженерну практику. Ось кілька конкретних фактів, які варто тримати в голові:

1. zram починався як «ramzswap» роки тому, потім був перейменований і занесений в upstream; ідея завжди була «стиснутий swap у RAM», а не загальний кеш.
2. zswap з’явився як frontswap backend, тобто він підключається до підсистеми swap як кеш-слой, а не блочний пристрій.
3. Алгоритми стиснення змінили правила гри: LZO був популярний раніше за швидкість; LZ4 став поширеним; ZSTD набув популярності за кращі коефіцієнти стиснення при прийнятній вартості.
4. Облік пам’яті в Linux став суворішим з часом (cgroups v2, PSI, краща поведінка reclaim), що робить «здається повільним» діагностованим за реальними сигналами.
5. Chrome і сучасні браузери повернули своп у норму на робочих станціях: великі робочі набори з багатьма холодними вкладками, частково стиснювані.
6. SSD зробили swap життєздатним, але не безкоштовним: латентність хороша в порівнянні зі шпинделями, але стійкі випадкові записи під навантаженням все ще вбивають хвостову латентність і пришвидшують знос.
7. Контейнери зробили своп політичним: деякі організації забороняють swap для нод, інші на нього покладаються; стиснення пам’яті стає компромісом, коли хочете грацію без ілюзій.
8. За замовчуванням ядра консервативні: більшість дистрибутивів уникають агресивних дефолтів для zram/zswap, бо «невірний» дефолт стає проблемою підтримки.
9. Сила Debian — передбачуваність, тому часто доводиться явно вмикати складні речі — і саме тому треба тестувати як дорослі.

Коли зram/zswap рятують систему (і коли ні)

Використовуйте zram, коли потрібен «якийсь swap», а сховище повільне, ненадійне або відсутнє

zram блискуче працює на:

• Невеликих VM, де сховище гіпервізора шумить або тонко провізіонується, і IO свопу викликає проблеми на рівні кластера.
• Edge-пристроях з дешевою флеш-пам’яттю, де знос через swap важливий.
• Ноутбуках розробників з вибухоподібною пам’яттю: збірки, браузери, IDE та «я забув, що мій Docker запущено».
• Системах із запасом CPU і помірним тиском на пам’ять: вартість компресії залишається під контролем.

Що ви купуєте: можливість уникнути OOM у слабкому-помірному тиску й зменшення хаотичного циклу записів на диск.
Чого ви не купуєте: нескінченну пам’ять. Якщо ваш робочий набір істотно перевищує RAM, zram просто змінює спосіб відмови.

Використовуйте zswap, коли: хочете зберегти реальний swap, але зробити його менш жахливим

zswap корисний, коли у вас вже є swap на SSD/NVMe (або навіть HDD) і ви хочете згладити найгіршу поведінку під час reclaim:

• Бази даних і JVM, де навіть невеликі латентності при своп-іні викликають довгі хвости, але ви все ще хочете клапан скидання тиску.
• VM-хости, де IO-шторм на swap викликає конкуренцію за сховище; zswap зменшує записову ампліфікацію.
• Змішані навантаження, де «деякі сторінки холодні й стискуються» — правда, але неможливо передбачити які саме.

Не варто, коли: вузьке місце не в пам’яті

Якщо ви вже обмежені CPU, додавання компресії — як найняти бухгалтера під час пожежі в кухні, бо він «добре з числами».
Якщо ви обмежені IO через сторонні дискові навантаження, zswap може допомогти, зменшуючи swap IO — але не вирішить базову конкуренцію за диск.

Жорстка правда: стиснення не замінює планування ємності

zram/zswap — чудові інструменти «граціозного погіршення». Вони не дають права запускати 28 GiB сервісів на 16 GiB VM.
Якщо ваш робочий набір у стейді перевищує RAM, правильний фікс — більше RAM, менше навантаження або обидва.
Стиснення може купити вам час. Рідко воно купує спокій.

Як це відпрацьовує неналежно: режими відмов, що виглядають як «Linux повільний»

Відмова №1: насичення CPU через компресію

Найпоширеніший режим відмов простий: система під тиском пам’яті починає свопити, і тепер ще й стиснення/декомпресія працюють.
Якщо ваші CPU вже зайняті, ця додаткова робота штовхає вас у смертельне коло: менше CPU для застосунку, більше затримок, більше черг, більше пам’ятевих змін.

Це часто трапляється з:

• завантаженими веб-нодами з алокаціями під запит і високим тиском GC,
• CI-раннерами, що виконують багато паралельних збірок,
• будь-якою машиною, де ви намагались «вирішити пам’ять», ввімкнувши ZSTD на високому рівні без вимірювання.

Відмова №2: хибне відчуття стабільності («вже не OOM»), за яким слідує колапс латентності

zram особливо може перетворити миттєвий OOM на тривалий період мук.
Система не вмирає. Вона просто стає непридатною: інтерактивні затримки стрибують, RPC таймаути, watchdog перезапуски, і on-call вивчає нові матюки.

На серверах правильне питання не «ми уникли OOM?» — а «ми зберегли SLO?»
Іноді швидке вбивство одного процесу є більш людяним, ніж тримати все напівживим 20 хвилин.

Відмова №3: reclaim бореться з вашим навантаженням

Активність свопу не є апріорі злою, але агресивний reclaim може бути таким.
Якщо «гарячий» набір вашого навантаження великий і постійно змінюється (наприклад, кеші, аналітичні завдання або метрики з великою кардинальністю), ядро може витіснити сторінки, які вам скоро знову знадобляться.
З zram/zswap ви тепер платите додаткові витрати за цикл «стискати, зберігати, декомпресувати, знову фолтити».

Відмова №4: неправильно обрані пули і сюрпризи з «пріоритетом swap»

Ви можете одночасно запускати дисковий swap і zram. Ядро обирає за пріоритетом swap.
Помиліться — і ви можете випадково штовхнути сторінки на диск першими, залишивши zram переважно неактивним, поки ваш SSD кричить.
Або навпаки: ви можете надто агресивно заповнити zram, лишивши замало RAM для page cache і робочих наборів додатків.

Відмова №5: пул zswap повний + повільний бекенд = раптовий обрив

zswap виглядає чудово, допоки пул не заповниться. Тоді йому доводиться викидати на реальний swap-бекенд.
Якщо цей бекенд повільний або конкурується, ви дуже швидко переходите від «приємно» до «о ні».
Це не означає, що zswap зламався; це означає, що ви жили на позиченій латентності.

Жарт №2: Увімкнути стиснення swap без вимірювань — як поставити турбо на вилочний навантажувач. Він їде швидше, поки не зустріне фізику.

Швидкий план діагностики (перші/другі/треті перевірки)

Коли Debian 13 машина «повільна» і ви підозрюєте тиск пам’яті, не починайте з редагування sysctl.
Почніть із трьох питань: чи є ми під тиском пам’яті? Чи відбувається свопінг? Біль — це CPU чи IO?

Перше: підтвердьте тиск і хто його спричиняє

• Перевірте PSI (pressure stall information): чи задачі затримуються через reclaim пам’яті?
• Перевірте major faults і swap-in: чи відбувається активне сторінкування?
• Визначте топ RSS/anon порушників і чи вони зростають.

Друге: визначте, чи компресія допомагає чи шкодить

• Огляд CPU-профілю: чи гарячий kswapd? Чи працює kcompactd? Чи спалюємо CPU в шляхах компресії?
• Статистика zram: наскільки заповнений, який коефіцієнт стиснення, які швидкості читання/запису?
• Статистика zswap: розмір пулу, збережені сторінки, кількість reject/duplicate, і викиди на диск.

Третє: оберіть найменш погане пом’якшення

• Якщо система трешить: зменшіть конкуренцію, позбудьтеся навантаження, зупиніть пакетні роботи або тимчасово перезапустіть найбільш пам’ятогоне завдання.
• Якщо backend swap — вузьке місце: увімкніть/налаштуйте zswap або додайте маленький зram-щабель із правильним пріоритетом.
• Якщо CPU — вузьке місце: знизьте вартість компресії (вибір алгоритму) або відключіть компресію та прийміть швидший OOM.

Практичні завдання: команди, виводи та рішення (12+)

Це призначено для запуску на реальному хості Debian 13. Кожне завдання містить: команду, що означає вивід, і яке рішення можна прийняти.
Нічого містичного. Це просто дисципліноване спостереження.

Завдання 1: Перевірити, чи існують zram-пристрої і чи використовуються вони

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,ROTA,MOUNTPOINTS
NAME        TYPE  SIZE ROTA MOUNTPOINTS
vda         disk   80G    1
├─vda1      part   79G    1 /
└─vda2      part    1G    1 [SWAP]
zram0       disk    8G    0

Значення: zram0 присутній і відображається як диск. Розмір — це сконфігурований віртуальний розмір.
Дисковий swap — vda2.

Рішення: Якщо ви очікуєте zram, але не бачите його — він не використовується. Якщо бачите, але він крихітний/гігантський — перевірте розмір.

Завдання 2: Перевірити активні swap-пристрої та пріоритети

cr0x@server:~$ swapon --show=NAME,TYPE,SIZE,USED,PRIO
NAME      TYPE      SIZE   USED PRIO
/dev/zram0 partition   8G   512M  100
/dev/vda2 partition    1G     0B   -2

Значення: zram має вищий пріоритет (100), тому буде використовуватись перед /dev/vda2.

Рішення: Якщо ваш дисковий swap має вищий пріоритет за zram — виправте це, якщо немає свідомої причини.

Завдання 3: Швидко виміряти загальний тиск пам’яті та своп

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi        12Gi       320Mi       1.1Gi       2.9Gi       1.2Gi
Swap:           9.0Gi       1.0Gi       8.0Gi

Значення: «available» — ключове число для короткострокового запасу. Використаний swap вказує, що ми почали витіснення.

Рішення: Якщо available низький і swap росте — ви в зоні reclaim. Перейдіть до PSI і vmstat далі.

Завдання 4: Перевірити memory PSI, щоб побачити, чи ядро гальмує задачі

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.42 avg60=0.30 avg300=0.18 total=43832490
full avg10=0.07 avg60=0.05 avg300=0.02 total=8203491

Значення: «some» показує контенцію при reclaim; «full» вказує на серйозні затримки, коли задачі не можуть просунутись через тиск пам’яті.

Рішення: Якщо «full avg10» немале для сервісу чутливого до латентності — ви пройшли межу «налаштування» і в зоні пом’якшення: зменште навантаження, вбийте винуватців, додайте RAM.

Завдання 5: Спостерігати swap-in/out і поведінку reclaim в реальному часі

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  1  942080 332000  60200 812000  120  240    14    90  820 1280 40 10 35 15  0
 1  2  954368 318000  60180 810500  200  420     0   140  900 1400 45 12 28 15  0
 3  1  990720 290000  60150 808900  320  500     0   210 1050 1600 52 13 20 15  0
 2  2 1015808 270000  60120 807400  410  690     0   260 1120 1750 55 15 16 14  0
 2  1 1048576 250000  60090 805100  300  520     0   180  980 1500 50 13 22 15  0

Значення: si/so — це swap-in/out за секунду. Сталий ненульовий показник свідчить про активне сторінкування.
CPU wa вказує на очікування IO; якщо він стрибає під час свопу, бекенд swap може бути болісним.

Рішення: Високий si означає, що ви зараз платите вартість (фолтите назад). Високий so означає, що ви витісняєте сторінки. У будь-якому випадку знайдіть пам’ятогоне завдання і вирішіть: вбити/перезапустити/обмежити.

Завдання 6: Визначити, чи система повільна через дисковий swap IO

cr0x@server:~$ iostat -xz 1 3
Linux 6.12.0 (server)  12/30/2025  _x86_64_  (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          45.12    0.00    9.20   18.44    0.00   27.24

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
vda              2.00     48.00     0.00   0.00   3.50    24.00  120.00   4096.00     0.00   0.00  45.00    34.13    5.40  98.00

Значення: Майже 100% завантаження і високе очікування на пристрої бекенду swap означає, що сховище — вузьке місце.

Рішення: Якщо диск завантажений під час свопінгу, zswap може допомогти. Якщо він вже ввімкнений і все ще завантажений, бекенд занадто повільний або система перевантажена.

Завдання 7: Перевірити коефіцієнт стиснення zram і поточне використання

cr0x@server:~$ cat /sys/block/zram0/mm_stat
786432000 196608000 131072 0 0 0 0 0

Значення: Поля залежать від ядра, але зазвичай включають: оригінальний розмір даних, стиснений розмір і метадані.
Тут ~750MB оригінальних сторінок стиснуто до ~187MB: гарний коефіцієнт.

Рішення: Якщо стиснений розмір близький до оригіналу, zram дає мало користі; розгляньте швидший алгоритм, менший zram або відключення, якщо CPU страждає.

Завдання 8: Перевірити, який алгоритм використовує zram

cr0x@server:~$ cat /sys/block/zram0/comp_algorithm
lzo [lz4] zstd

Значення: Алгоритм в дужках активний (lz4).

Рішення: Для серверів віддавайте перевагу lz4 за швидкість, якщо тільки не доведете, що ZSTD покращує коефіцієнт достатньо, щоб знизити paging суттєво.

Завдання 9: Перевірити, чи zswap увімкнений і що він робить

cr0x@server:~$ cat /sys/module/zswap/parameters/enabled
Y

cr0x@server:~$ grep -H . /sys/kernel/debug/zswap/*
/sys/kernel/debug/zswap/pool_total_size: 268435456
/sys/kernel/debug/zswap/stored_pages: 23144
/sys/kernel/debug/zswap/same_filled_pages: 120
/sys/kernel/debug/zswap/duplicate_entry: 340
/sys/kernel/debug/zswap/reject_reclaim_fail: 0
/sys/kernel/debug/zswap/reject_compress_poor: 42
/sys/kernel/debug/zswap/written_back_pages: 1800

Значення: zswap увімкнений. Він зберігає сторінки в пулі, відхиляє деякі через погане стиснення і записав назад деякі сторінки на диск.

Рішення: Високий показник written_back_pages плюс повільний диск вказують, що пул занадто малий, пам’ять під тиском або бекенд swap — справжня проблема.

Завдання 10: Підтвердити політику swap ядра (swappiness та інші)

cr0x@server:~$ sysctl vm.swappiness vm.vfs_cache_pressure vm.page-cluster
vm.swappiness = 60
vm.vfs_cache_pressure = 100
vm.page-cluster = 3

Значення: swappiness впливає на те, наскільки охоче ядро свопить проти реаймування page cache. page-cluster впливає на патерни передчитування при свопі.

Рішення: Якщо ви використовуєте тільки zram на латентно-чутливому боксі, розгляньте зниження swappiness (часто 10–30), щоб уникнути надто охочого витіснення анонімних сторінок. Після змін вимірюйте.

Завдання 11: Виявити топ споживачів пам’яті (RSS/anon) без омани

cr0x@server:~$ ps -eo pid,comm,rss,%mem --sort=-rss | head -n 10
  PID COMMAND           RSS %MEM
 2210 java          4123456 26.1
 1842 postgres      2104320 13.3
 3011 node          1456896  9.2
 1123 prometheus     802560  5.1

Значення: RSS — resident set size: що зараз у RAM. Під тиском RSS може впасти, тоді як продуктивність колапсує, бо процес фолтить сторінки туди-сюди.

Рішення: Якщо процес величезний і росте, ви або обмежуєте його (ліміти), налаштовуєте (heap, кеші), або ставите його в інцидент. Не «додавайте просто zram», щоб уникнути розмови.

Завдання 12: Перевірити major page faults, щоб підтвердити справжній біль від сторінкування

cr0x@server:~$ pidstat -r 1 3
Linux 6.12.0 (server)  12/30/2025  _x86_64_  (8 CPU)

12:20:01 PM   UID       PID  minflt/s  majflt/s     VSZ     RSS   %MEM  Command
12:20:02 PM  1000      2210   2300.00     12.00 6123456 4123456  26.1  java
12:20:02 PM  1000      1842    820.00      6.00 3256780 2104320  13.3  postgres
12:20:03 PM  1000      2210   2500.00     20.00 6123456 4123456  26.1  java

Значення: Major faults (majflt/s) потребують доступу до диску або swap (або принаймні нетривіальний шлях обробки фолта). Якщо major faults зростають разом зі стрибками латентності — ви агресивно фолтите.

Рішення: Якщо major faults сталий — зосередьтесь на зменшенні робочого набору і своп-чуру. Стиснення може допомогти, якщо воно зменшує дисковий IO; воно не лікує завеликий робочий набір.

Завдання 13: Підтвердити ліміти cgroup v2 (хости контейнерів люблять брехати)

cr0x@server:~$ cat /sys/fs/cgroup/memory.max
max

cr0x@server:~$ cat /sys/fs/cgroup/memory.current
12582912000

Значення: Під root немає ліміту cgroup; поточне використання ~11.7GiB. Для контейнерів/сервісів перевіряйте їхні індивідуальні cgroup теж.

Рішення: Якщо сервіс має занадто жорсткий ліміт, він може трешитись у своєму cgroup, навіть коли хост має пам’ять. Виправте ліміт перед налаштуванням swap.

Завдання 14: Перевірити швидкості активності zram через /proc/swaps і /proc/vmstat

cr0x@server:~$ cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/zram0                               partition	8388604		524288		100
/dev/vda2                                partition	1048572		0		-2

cr0x@server:~$ egrep 'pswpin|pswpout' /proc/vmstat
pswpin 184233
pswpout 392001

Значення: Загальні лічильники swap-in/out дозволяють корелювати «повільні періоди» зі сторінкуванням.

Рішення: Якщо pswpin зростає під час інцидентів — ви платите латентністю свопу. Якщо тільки pswpout зростає — ви витісняєте сторінки (можливо через swappiness).

Поради з налаштування: важливі регулятори в Debian 13

Оберіть стратегію: тільки zram, тільки zswap або шарована конфігурація

Ось продукційний погляд:

• тільки zram: добре для малих систем і edge-пристроїв, де дисковий swap неприйнятний. Ризик: тривале трешування замість швидкого OOM.
• тільки zswap: загальний вибір, коли у вас вже є swap на SSD/NVMe. Він зменшує IO, не прикидаючись, що RAM — нескінченна.
• шарована (zram + диск): потужна, коли ви правильно виставите пріоритети. zram поглинає хаотичність; диск — останній форпост.

Вибір алгоритму: не будьте розумнішими, ніж стабільність

Для zram і zswap вибір алгоритму — це політичне рішення:

• LZ4: швидкий, гідний коефіцієнт, зазвичай найкращий дефолт для серверів.
• LZO: також швидкий, іноді трохи гірший коефіцієнт, ніж LZ4.
• ZSTD: кращий коефіцієнт, вища вартість CPU; може бути відмінним, якщо це запобігає дисковому IO, або катастрофічним, якщо CPU вже натиснуті.

Моє правило: під час діагностики інциденту обирайте швидкість. Якщо проектуєте стейт-апсет на CPU-багатій машині — експериментуйте з ZSTD, але вимірюйте «full» PSI пам’яті і хвостову латентність.

Розмір zram: припиніть ставитись до нього як до безкоштовної RAM

Поширені поради щодо розміру zram плавають як народна медицина (25%, 50%, «рівний RAM» тощо).
У продакшені розмір zram — це про те, що ви хочете витримати, а не про те, що ви хочете прикидати.

• На серверах: починайте близько 10–25% RAM, якщо використовуєте його як швидкий шар, а не як підміну ємності.
• На ноутбуках/десктопах: 25–50% RAM часто прийнятно, бо інтерактивні навантаження виграють і ви можете терпіти деякі витрати CPU.
• На малих системах (≤ 2–4 GiB RAM): zram може бути пропорційно більшим, але обережно: компресійний CPU на малих ядрах може стати вузьким місцем.

Розмір zswap: контролюйте пул і поведінку викидів

Пул zswap має максимальний відсоток RAM і використовує аллокатор (часто zbud/z3fold), який міняє щільність на CPU і фрагментацію.
Якщо пул занадто малий — ви швидко пишете назад на диск і втрачаєте сенс. Якщо занадто великий — витісняєте page cache і гарячі анонімні сторінки.

Розумний початок для серверів із SSD swap — кап пулу в діапазоні 10–20% RAM.
Якщо ви часто б’єте writeback під нормальним навантаженням — ви недопроізведені або ваше навантаження настільки спайкове, що треба переглянути ліміти та конкуренцію.

Swappiness: з одним числом політи не виграєш

vm.swappiness — це не «скільки swap я хочу». Це частина системи прийняття рішень про реаймінг page cache проти анонімної пам’яті.
З zswap вищий swappiness може бути прийнятним, оскільки витіснення можуть лишатись у RAM стиснутими, зменшуючи IO. З zram-only занадто високий swappiness може спричинити непотрібний шурхіт.

Практичний підхід:

• Сервери чутливі до латентності: починайте близько 10–30 і тестуйте.
• Загального призначення: дефолти (60) можуть бути прийнятними, особливо з zswap.
• Сервіси з великими кешами: можливо, варто вищий показник, якщо реаймінг page cache бажаний, але тільки після розуміння компромісів.

Що адміністраторам Debian 13 варто стандартизувати

Стандартизуйте дві речі по флоту:

1. Видимість: експортуйте PSI (/proc/pressure/*), swap-in/out (/proc/vmstat) і статистики zram/zswap. Якщо ви не бачите — будете звинувачувати «Linux».
2. Політику: вирішіть для кожного класу нод, чи дозволений swap і чи це zswap, zram чи обидва. Узгодженість краще за хитрощі о 3 ранку.

Три короткі історії з реального життя

Міні-історія 1: Інцидент через неправильне припущення

Середня компанія тримала флот Debian VM для внутрішніх API. Платформна команда ввімкнула zswap у нових образах.
Припущення було простим: «zswap означає, що своп дешевий тепер, тож можна перестати хвилюватися про своп-шторм». Вони також тихо зменшили розмір swap до «на всяк випадок», щоб не дивуватись використанню диску.

Місяців потому рутина деплой підвищила використання пам’яті на кілька сотень мегабайт на інстанс.
Нічого драматичного. Ні один процес не вийшов з-під контролю. Той поступовий ріст, який робить графіки неначе м’які пагорби.
Під піком ноди почали таймаутитись. Не падали — таймаути. Ретрайзи зросли, що підвищило навантаження, що підвищило пам’ятеві коливання. Класика.

On-call знайшов zswap увімкненим і здоровим. Пул заповнився, потім почав писати назад на бекенд swap.
Але бекенд swap був крихітним, тому швидко заповнився. Коли swap повний, у ядра менше опцій; ви отримуєте тиск reclaim, затримки і врешті OOM — часто в найгірший момент.

Виправлення було нудним: відновити розумний розмір бекенду swap, залишити zswap і налаштувати алерти на насичення пулу zswap і зростання використання swap.
Команда також додала перевірку «бюджету пам’яті» до деплойментів: невеликі збільшення на вузлі можуть перетворитися на великі флотські відмови.

Міні-історія 2: Оптимізація, що відпрацювала проти

Інша організація запускала CI-раннери на Debian. Збірки були агресивно паралелізовані, і тиск пам’яті був очікуваний.
Хтось прочитав, що ZSTD дає кращий коефіцієнт стиснення, і вирішив «покращити продуктивність», перемкнувши zram на ZSTD всюди.
Зміни виглядали круто в тихому тесті: використання swap впало, і «вільна пам’ять» виглядала краще.

У продакшені CPU був справжнім дефіцитом. Ці раннери вже були зайняті компіляцією, лінкуванням, стисненням артефактів і крипто-обміном з реєстрами.
Коли тиск пам’яті настав, система почала стиснювати сторінки ZSTD. CPU з «зайнятий але в нормі» перейшов у «насичений і хаотичний».
Часи збірки зросли. Час черги зріс. Інженери додавали ще паралельних завдань, щоб компенсувати — стало гірше.

Підказкою були метрики, яких вони не стежили: memory PSI «full» зростав у піки, і CPU steal на гіпервізорі ріс, бо всі боролись за цикли.
«Кращий коефіцієнт» був неважливим; системі не потрібна була більша ефективна ємність swap. Тій потрібний був менший CPU-overhead під конкуренцією.

Вони відкотилися на LZ4, трохи зменшили розмір zram і додали політику планування, щоб обмежувати паралельні збірки відповідно до доступної пам’яті і порогів PSI.
Результат: менше героїчних трюків з ядром, кращий пропуск і менше загадкових уповільнень.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Сервіс, що працював поруч з платіжними системами, мав жорсткий бюджет латентності. SRE-команда мала політику: swap дозволений, але лише з zswap і лише з конкретними алертами.
Вони відстежували memory PSI, швидкість swap-in і час очікування диску. Нічого фантастичного. Просто послідовна видимість.

Одного дня пішов сплеск трафіку разом з, здавалося б, безпечним конфіг-зміненням, що збільшило кешування в пам’яті.
Використання пам’яті зросло, і почався reclaim. Ключове те, що система не впала одразу; zswap поглинув ранні витіснення, зменшуючи записи на диск.
Але алерти спрацювали: memory PSI «full» піднявся, і written-back pages з zswap почали зростати — раннє попередження, що пул заповнюється.

On-call не гадали. Вони слідували рунабуку: зменшили розмір кешу, понизили конкуренцію воркерів і горизонтально масштабували.
Ніяких драматичних перезапусків. Ніяких «давайте ще zram». Просто контрольоване пом’якшення в рамках SLO.
Інцидент став не подією: сторінка, відповідь і фікс до того, як клієнти помітили.

Практика, що їх врятувала, була нудна: вони мали провісні індикатори. Використання swap — лагуючий індикатор; коли воно велике, ви вже платите.
PSI і zswap writeback дали їм шанс діяти раніше, ніж машина перетвориться на слайд-шоу.

Поширені помилки: симптом → корінь проблеми → виправлення

1) Симптом: високий load average, високий CPU, але нічого «не виглядає» зайнятим

Корінь проблеми: потоки ядра спалюють CPU на реаймені і компресії сторінок (kswapd, ворккі в компресії), часто викликані zram/zswap під тиском.

Виправлення: підтвердьте через PSI і vmstat. Якщо CPU — обмеження, перейдіть на швидший алгоритм (LZ4), зменшіть zram, понизьте конкуренцію або тимчасово відключіть компресію, щоб змусити швидший OOM і відновлення.

2) Симптом: диски досягають 100% під час «інцидентів пам’яті»

Корінь проблеми: бекенд swap приймає важкі записи/читання; zswap може бути вимкнений, неправильно налаштований або занадто малий; пріоритет zram може бути невірним.

Виправлення: увімкніть zswap (з реальним swap-пристроєм), переконайтеся, що zram (якщо використовується) має вищий пріоритет за диск, і перевірте, що дисковий swap не на контендованому пристрої.

3) Симптом: «ми увімкнули zram, але кеші стали гірші і продуктивність погіршилася»

Корінь проблеми: zram занадто великий; він відбирає RAM у page cache і гарячих анонімних сторінок, викликаючи більше IO і фолтів.

Виправлення: зменшіть розмір zram; розглядайте його як невеликий аварійний буфер, а не як другий банк RAM. Перевіряйте з реальним навантаженням.

4) Симптом: система більше не OOM-ить, але стає неробочою на хвилини

Корінь проблеми: трешинг: робочий набір значно перевищує RAM. zram робить відмову повільнішою і болючішою.

Виправлення: встановіть ліміти, зменшіть використання пам’яті або додайте RAM. Розгляньте збереження невеликого дискового swap з zswap (або без swap) залежно від SLO; вирішіть, чи кращий швидкий OOM за довгі зупинки.

5) Симптом: zswap увімкнений, але записи swap все одно важкі

Корінь проблеми: пул zswap швидко насичується; погані коефіцієнти стиснення (багато reject); або бекенд swap використовується напряму через політику/пріоритети.

Виправлення: перевірте debug-лічильники zswap; трохи збільште pool cap або змініть алгоритм; перевірте swap-пристрої і пріоритети; виправте базове зростання пам’яті.

6) Симптом: контейнерні навантаження OOM-ляться в cgroups, хоча хост має вільну пам’ять

Корінь проблеми: cgroup memory.max занадто малий; поведінка свопінгу відрізняється всередині cgroup; системний zram/zswap не виправить поганий ліміт.

Виправлення: підкоригуйте ліміти cgroup, встановіть розумні бюджети на сервіс і моніторьте PSI по cgroup, якщо можливо. Не використовуйте системне стиснення swap як пластир для поганих квот.

7) Симптом: «Swap використовується, хоча RAM є в наявності»

Корінь проблеми: непорозуміння звітності пам’яті в Linux; «free» ≠ «available», динаміка page cache і проактивний reclaim.

Виправлення: використовуйте free -h і зосередьтесь на «available», застосовуйте PSI для підтвердження тиску. Не вимикайте swap через паніку «swap used != bad».

8) Симптом: проблеми з підвіскою/пробудженням або гібернацією на ноутбуках після увімкнення zram

Корінь проблеми: гібернація потребує бекінгу swap достатнього розміру для запису образу RAM; zram не годиться як єдина мішень для гібернації.

Виправлення: зберігайте дисковий swap-partition/file розміром для гібернації; використовуйте zram як додатковий swap з вищим пріоритетом, а не як єдиний swap.

Контрольні списки / покроковий план

Чекліст A: Вирішіть, що розгортати (по класу нод)

1. Класифікуйте ноду: ноутбук, VM, база даних, CI-раннер, хост контейнерів, edge-пристрій.
2. Визначте пріоритет відмови: швидкий OOM чи граціозне уповільнення. Для сервісів, чутливих до латентності, швидка відмова часто безпечніша.
3. Перевірте запас CPU: якщо CPU регулярно >70% на піку, вартість компресії може нашкодити.
4. Перевірте якість бекенду swap: SSD/NVMe — ок; повільне мережеве сховище або контендовані диски — ні.
5. Оберіть стратегію: zswap-only для більшості серверів; zram-only для відсутнього/повільного диску; шарована для шумного сховища.

Чекліст B: Безпечний базовий набір для сервера Debian 13 (zswap-first)

1. Переконайтесь, що у вас є реальний swap-пристрій (файл або розділ) згідно політики розміру.
2. Увімкніть zswap і почніть з швидкого алгоритму.
3. Встановіть алерти на memory PSI «full» і швидкість swap-in.
4. Тестуйте навантаження при реальній конкуренції і дивіться хвостові латентності, а не лише пропуск.
5. Лише потім розгляньте додавання маленького zram-слою, якщо дисковий swap все ще вузьке місце.

Чекліст C: Шарований swap (zram + диск) без самосаботажу

1. Створіть/увімкніть zram swap з вищим пріоритетом, ніж дисковий swap.
2. Залиште дисковий swap як резерв з нижчим пріоритетом.
3. Обмежте розмір zram до консервативної частки (10–25% RAM для серверів).
4. Використовуйте LZ4, якщо немає виміреного виправдання для іншого алгоритму.
5. Моніторьте: заповненість zram, коефіцієнт стиснення, швидкості swap-in/out і CPU.

Чекліст D: Реагування на інцидент, коли тиск пам’яті піднявся

1. Перевірте PSI (memory). Якщо «full» підвищений — трактуйте це як серйозне.
2. Перевірте швидкість swap-in і major faults. Підтвердьте активне сторінкування.
3. Перевірте час очікування диску/завантаження. Якщо диск завантажений — IO частина проблеми.
4. Знайдіть топ-винуватця і вирішіть: перезапустити, обмежити або масштабувати.
5. Після інциденту: виправте регрес пам’яті і додайте захисний механізм (ліміт, бюджет або алерт).

FAQ

1) Чи варто використовувати zram або zswap у Debian 13?

Для більшості серверів: zswap з реальним swap-бекендом. Для малих/edge-пристроїв: zram може бути чудовим. Для шумного сховища: шарована конфігурація може бути відмінною, якщо пріоритети виставлені правильно.

2) Чи можна запускати одночасно zram і zswap?

Так, але робіть це свідомо. zswap кешує сторінки, призначені для swap-пристроїв; якщо одним із цих пристроїв є zram, ви можете отримати подвійне стиснення «попереду» вже стисненого пристрою. Загальна шарована схема — zram + дисковий swap, а не zswap + zram, хіба що ви виміряли реальну користь.

3) Чи стиснення swap запобігає OOM killer?

Воно може відкласти OOM, збільшуючи ефективну ємність для холодних/стиснюваних сторінок. Воно не усуває OOM, якщо робочий набір продовжує зростати.
Іноді відкладення OOM — погано: отримуєте хвилини таймаутів замість швидкого перезапуску.

4) Який алгоритм стиснення обрати?

Починайте з LZ4 для серверів. Розглядайте ZSTD тільки після вимірювання CPU-запасу і доведення, що кращий коефіцієнт покращує хвостову латентність за рахунок зменшення дискового swap.

5) Який розумний розмір zram?

Сервери: часто 10–25% RAM як швидкий шар. Десктопи: 25–50% може працювати добре.
Якщо встановити «рівно RAM» і забути — ви будуєте генератор повільного краху.

6) Чому swap використовується, коли є «вільна» пам’ять?

Тому що «free» ≠ «available», а Linux активно використовує пам’ять для кешів. Також ядро може витіснити холодні анонімні сторінки, щоб зберегти кеш.
Дивіться «available» у free -h і використовуйте PSI для підтвердження реального тиску.

7) Як зрозуміти, чи zswap дійсно допомагає?

Шукайте зниження швидкості записів на диск під час тиску пам’яті, менший IO wait і стабільні хвостові латентності. У статистиці zswap — здорове число збережених сторінок і керовані швидкості запису назад.
Якщо пул насичується і written-back pages стрибають — ви просто відтерміновуєте дисковий біль.

8) Чи поганий swap для баз даних типу PostgreSQL?

Непланований своп поганий для баз даних, чутливих до латентності. Але невелика кількість swap з zswap може запобігти катастрофічному OOM і зменшити IO-шторм.
Правильне рішення — адекватне планування пам’яті і уникнення overcommit; zswap — ремінь безпеки, а не новий двигун.

9) Чи зменшить zram знос SSD?

Так, якщо він замінює або зменшує записи swap на диск. zswap також допомагає, поглинаючи витіснення в RAM і пишучи назад менше.
Але якщо ви сильно трешите — все одно писатимете на диск (викиди zswap) і витрачатимете CPU.

10) Чому увімкнення zram зробило систему повільнішою навіть без важкого свопінгу?

Якщо zram занадто великий, він споживає RAM для власних метаданих і конкурує з page cache. Система може більш агресивно реаймити або мати менший hit rate кешу, що викликає більше IO.
Розміріть консервативно і перевіряйте на реальному навантаженні.

Висновок: наступні кроки, які можна виконати сьогодні

Якщо ви працюєте з Debian 13 у продакшені, ставтесь до zram/zswap як до будь-якої іншої функції продуктивності: підключайте усвідомлено, вимірюйте постійно і відкочуйте, коли вона вас обманює.
Хороша новина — не потрібні героїчні вчинки. Потрібен план.

1. Оберіть політику за замовчуванням для кожного класу нод (zswap-only — тьмяний переможець для багатьох серверів).
2. Додайте видимість: memory PSI, swap-in/out, disk await/util і статистики zram/zswap.
3. Прогнajte тест під тиском, що відповідає реальності: пікова конкуренція, фонова робота і шумні сусіди включені.
4. Визначте пріоритет відмов: швидкий OOM чи повільний треш, і налаштуйте swap/стиснення під нього.
5. Виправіть корінь проблеми після інциденту: бюджети пам’яті, ліміти і розміри. Стиснення — не план ємності.

Ядро робить усе можливе, щоб утримати систему живою. Ваше завдання — переконатися, що «жива» ще й «корисна».