Ubuntu 24.04: Swap на SSD — робіть це безпечно (і коли цього не слід) (випадок №50)

Що таке swap (і чого це не є)

Swap — це віртуальна пам’ять з бекапом на диску. Це клапан скидання тиску: коли RAM закінчується, ядро може вивести холодні сторінки з пам’яті,
звільнивши місце для «гарячих» сторінок. Якщо робити це правильно, swap перетворює «процес вбито» на «процес став повільнішим».
Якщо робити це погано, swap перетворює «повільно» на «невідзивчиво».

В Ubuntu 24.04 зазвичай є swapfile у вигляді /swap.img, створений інсталятором і керований через systemd.
Також у вас може бути zram (стиснутий swap у RAM) залежно від редакції та конфігурації. Кожен з них має власні режими відмов.

Ментальна модель, яка вам потрібна

• Swap — це не додаткова RAM. Це резерв з іншою затримкою.
• Swap не лише для аварійних випадків. Його можна використовувати проактивно, щоб зберегти ефективну поведінку кеша, особливо при змішаних навантаженнях.
• Swap не є причиною витоку пам’яті. Це просто місце, куди витік поступово «переїжджає».

SSD змінює правила гри, оскільки I/O зі swap стає «менш жахливим», але не «швидким».
NVMe може виконувати вражаючі IOPS, але свапінг часто означає невеликі випадкові читання під час page fault — затримка важлива, черги важливі,
і обмеження cgroup теж мають значення. Навіть швидкий SSD може залишатися найповільнішим елементом у вузлі.

Одна цитата, яку операційні люди запам’ятовують рано:
«Надія — не стратегія.» — General Gordon R. Sullivan

Якщо ваш план — «увімкнути swap і надіятися», отримаєте саме такий swap, на який заслуговуєте.

Факти та історія, які мають значення

1. Swap існував задовго до Linux. Пейджинг і стратегії swap були ключовими у UNIX-часне-шерінгу задовго до того, як у споживацьких ПК стало достатньо RAM.
2. Linux використовує swap розумніше, ніж вважають люди. Він може виводити анонімну пам’ять, лишаючи файловий кеш «гарячим», залежно від тиску та налаштувань.
3. Страх «swap шкодить SSD» має історичні корені. Ранні споживчі SSD мали слабкі контролери та меншу витривалість; сучасні NVMe значно стійкіші.
4. Ubuntu давно перейшла на swapfile. Swap-розділи все ще валідні, але swapfile легше змінювати за розміром і розгортати в масштабі.
5. Гібернація — це спеціальний випадок для swap. Hibernate потребує області swap, достатньої для вміщення вмісту RAM, а swapfile вимагає додаткової конфігурації завантаження.
6. cgroups змінили значення «out of memory». Контейнер може бути OOM-killed, тоді як хост має вільну пам’ять, і swap може бути вимкнений на рівні cgroup.
7. zram став популярним, бо CPU подешевшав. Стиснення холодних сторінок у RAM часто виграє у доступу на диск, особливо на ноутбуках і маленьких VM.
8. NVMe зробив swap «можливим» на системах з великою пропускною здатністю. Це не зробить swap швидким, але може врятувати від катастрофічної повільності, як на механічних дисках.

Жарт №1: Swap — це як рухлива доріжка в аеропорту — корисна, якщо ви вже йдете; смішно, якщо ви намагаєтеся перевезти піаніно.

Чи варто розміщувати swap на SSD?

Мій упереджений дефолт

На Ubuntu 24.04 з SSD зазвичай варто зберігати принаймні якийсь swap — якщо у вас немає конкретної причини проти.
«Принаймні якийсь» означає кілька гігабайт для більшості серверів, і достатньо для hibernate, якщо ви дійсно ним користуєтесь.

Swap на SSD корисний для

• Запобігання раптовим OOM kills при сплесках навантаження (зборки пакетів, індексація логів, прогрів JVM).
• Підтримки стабільності системи під тиском пам’яті, щоб ви могли зайти, проінспектувати і виправити реальну причину.
• Зниження хвостових ризиків, коли ви запускаєте багато сервісів і один із них виходить з-під контролю.
• Здорового overcommit на хостах, що відповідально використовують overcommit пам’яті (і мають моніторинг).

Swap на SSD шкідливий для

• Платформ з критичною затримкою, де випадкові page fault неприпустимі.
• Систем, що вже завантажені по I/O (активні диски баз даних, переповнені NVMe черги, вузли зберігання, що виконують реальну роботу).
• Культур, які відмовляються адекватно підбирати RAM. Swap перетвориться на милицю, а потім — у рахунок за оплату.

Ключове питання

Ви намагаєтеся вижити у поганий день, чи економити гроші, постійно недодавши пам’яті?
Swap підходить для першого варіанту і поганий для другого.

Швидкий план діагностики

Коли хост відчувається «замороженим», часу на філософію немає. Потрібен короткий шлях до вузького місця.
Ось порядок, що зазвичай працює в реальному продакшні.

1) Підтвердіть, що відбувається свапінг (і наскільки сильно)

• Якщо використання swap близьке до нуля, це не інцидент зі swap. Перейдіть до CPU, I/O або блокувань.
• Якщо swap використовується багато і зростає, у вас тиск пам’яті і, ймовірно, ви наближаєтеся до трешу.
• Якщо використання swap стабільне, але машина повільна, можливо, у вас нападні хвилі swap-in (page fault), а не постійний swap-out.

2) Визначте, чи вузьке місце — I/O чи CPU

• Високий wa (I/O wait) та високі ставки swap-in/out зазвичай означають, що обмежує шлях зберігання.
• Низький I/O wait, але високе навантаження CPU зі зжаттям через zram може означати, що ви платите CPU, щоб уникнути доступу на диск.

3) Ідентифікуйте клас процесів, що створює тиск

• Шукайте один runaway (витік пам’яті) проти багатьох звичайних процесів в сумі (недостатньо RAM).
• На серверах спочатку перевіряйте ліміти cgroup; хост може бути в порядку.

4) Дійте: стабілізуйте, потім виправляйте

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

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

Ось точні перевірки та втручання, які я виконую на хостах Ubuntu 24.04. Кожне завдання містить реалістичний фрагмент виводу,
що він означає, і рішення, яке ви приймаєте.

Завдання 1: Подивіться, який swap існує і чи він активний

cr0x@server:~$ swapon --show --bytes
NAME       TYPE SIZE        USED PRIO
/swap.img  file 8589934592  0    -2

Значення: У вас є 8 GiB swapfile і він увімкнений, наразі не використовується.

Рішення: Якщо ви усуваєте уповільнення і USED близький до SIZE, у вас, ймовірно, тиск пам’яті. Якщо USED = 0, swap не є причиною.

Завдання 2: Швидкий знімок RAM + swap

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        25Gi       1.2Gi       1.0Gi       5.0Gi       3.0Gi
Swap:          8.0Gi       6.5Gi       1.5Gi

Значення: Swap сильно використовується і доступної RAM мало. Це позиція «зараз повільно, потім гірше».

Рішення: Перевірте, чи система активно свапить (Завдання 3). Якщо активного свапінгу немає, це може бути історичне використання swap, яке ще не було повернуто.

Завдання 3: Виявити активний свапінг проти старих виведених сторінок

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  0 6815744  93248  90112 2840000 120  240   300   600  800 1200 12  5 70 13  0
 3  1 6897664  84520  89400 2815000 800 1200  2100  3300 1400 2100 10  6 55 29  0
 1  1 7012352  70212  88000 2780000 600  900  1600  2400 1300 1900  9  5 58 28  0
 1  0 7012352  76000  88500 2779000   0    0   200   300  900 1400  8  4 84  4  0
 1  0 7012352  77000  88500 2778000   0    0   150   250  850 1300  7  4 85  4  0

Значення: Сплески si/so показують активний треш у перші секунди, потім заспокоюється.

Рішення: Якщо сплески корелюють з латентністю, треба зменшити тиск пам’яті або конкуренцію за I/O. Якщо це постійно високо — у вас стійкий треш.

Завдання 4: Перевірити ядрові налаштування swappiness і cache pressure

cr0x@server:~$ sysctl vm.swappiness vm.vfs_cache_pressure
vm.swappiness = 60
vm.vfs_cache_pressure = 100

Значення: Поведінка приблизно дефолтна: swap дозволений при зростанні тиску.

Рішення: Для багатьох серверів розгляньте vm.swappiness=10 або 20, якщо хочете віддавати перевагу збереженню анонімних сторінок у RAM — але лише після перевірки, щоб не маскувати проблему недостатньої RAM.

Завдання 5: Подивитися, чи система OOM-кілить

cr0x@server:~$ journalctl -k -g "Out of memory" -n 5
Dec 30 09:12:21 server kernel: Out of memory: Killed process 21877 (java) total-vm:18233400kB, anon-rss:12984320kB, file-rss:12288kB, shmem-rss:0kB, UID:1001 pgtables:36244kB oom_score_adj:0

Значення: Ви не лише свапите; ви влучаєте в OOM. Swap недостатній або попит на пам’ять росте швидше, ніж система встигає реагувати.

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

Завдання 6: Швидко визначити топ-споживачів пам’яті

cr0x@server:~$ ps -eo pid,comm,rss,vsz,pmem --sort=-rss | head
  PID COMMAND           RSS      VSZ %MEM
21877 java          12984320 18233400 41.2
 8421 postgres       2845120  5120000  9.0
 3112 node            980000  1600000  3.1
 1991 snapd            210000   980000  0.6

Значення: Один JVM домінує за resident-пам’яттю. Це ймовірне джерело тиску.

Рішення: Перевірте, чи це очікувано (кеш) чи витік/зростання. Для Java перегляньте настройки heap; для будь-якого процесу перевірте останні деплої.

Завдання 7: Перевірити використання swap по процесах (хто реально свапиться)

cr0x@server:~$ sudo smem -rs swap | head
  PID User     Command                         Swap      USS      PSS      RSS
 8421 postgres /usr/lib/postgresql/16/bin/...  2200M    850M    910M   1200M
 3112 www-data node /srv/app/server.js         1100M    420M    480M    600M
 1991 root     /usr/lib/snapd/snapd             210M     80M     90M    140M

Значення: Postgres і node мають великі swapped-out сліди. Зазвичай це означає, що вони були неактивні або ядро обрало їх для витіснення.

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

Завдання 8: Виміряти реальний тиск на зберігання та черги

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10.12    0.00    4.50   28.20    0.00   57.18

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz aqu-sz  %util
nvme0n1         980.0   18000.0     0.0   0.00    7.20    18.37   420.0   12000.0   12.40    28.57   8.10  98.50

Значення: NVMe майже насичено (%util ~ 98%) і очікування зростають. Якщо swap активний, він конкурує з усім іншим.

Рішення: Якщо ваш swap знаходиться на тому ж пристрої, що й база даних, це «сутичка у телефонній будці». Розгляньте переміщення swap на менш завантажений пристрій або виправлення розміру пам’яті.

Завдання 9: Підтвердити, чи swap — це файл і де він розташований

cr0x@server:~$ ls -lh /swap.img
-rw------- 1 root root 8.0G Dec 30 08:52 /swap.img

Значення: Це swapfile у кореневій файловій системі.

Рішення: Переконайтеся, що файлова система безпечно підтримує swapfiles (ext4 — так; btrfs потребує спеціальної обробки). Якщо root використовує шифрування/LVM — це нормально, але розумійте наслідки для hibernate.

Завдання 10: Перевірити тип файлової системи (перевірка безпеки swapfile)

cr0x@server:~$ findmnt -no FSTYPE /
ext4

Значення: ext4 дружній до swapfile.

Рішення: Продовжуйте як завжди. Якщо ви бачите btrfs — зупиніться і дотримуйтесь специфічних правил для btrfs (відключити CoW, забезпечити суміжні екстенти).

Завдання 11: Перевірити стан TRIM/discard (догляд за SSD)

cr0x@server:~$ systemctl status fstrim.timer --no-pager
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Mon 2025-12-29 10:00:00 UTC; 23h ago
    Trigger: Mon 2026-01-05 10:00:00 UTC; 5 days left

Значення: Тижневий TRIM увімкнений. Добре: це допомагає стабільності продуктивності SSD з часом.

Рішення: Залишайте. Не додавайте постійний параметр mount discard лише заради вигляду; плановий TRIM зазвичай правильний вибір.

Завдання 12: Подивитися сигнали тиску пам’яті (PSI) і поводитися як дорослий

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.85 avg60=0.40 avg300=0.15 total=23840219
full avg10=0.20 avg60=0.08 avg300=0.02 total=4022191

Значення: Система регулярно блокується при звільненні пам’яті (some) і іноді повністю (full).

Рішення: Це не теоретично. Ви платите реальної латентності. Зменшіть робочий набір, додайте пам’ять або додайте швидкий swap/zram як тимчасовий захід, поки виправляєте причину.

Завдання 13: Перевірити, чи zram увімкнений (і який розмір)

cr0x@server:~$ swapon --show
NAME       TYPE      SIZE   USED PRIO
/swap.img  file      8G     2.1G   -2
/dev/zram0 partition 4G     1.3G  100

Значення: zram присутній з вищим пріоритетом (100). Ядро використовуватиме zram перед SSD swapfile.

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

Завдання 14: Підтвердити пріоритет swap і змінювати навмисно

cr0x@server:~$ cat /proc/swaps
Filename				Type		Size		Used		Priority
/dev/zram0                               partition	4194300	1365000		100
/swap.img                                file		8388604	2200000		-2

Значення: zram буде віддаватися перевага, swapfile — як запасний варіант.

Рішення: Хороший дефолт: тримати SSD swap як «другу лінію оборони». Якщо ви покладаєтесь на SSD swap для hibernate, переконайтеся, що пріоритети і розміри не перешкоджають цьому плану.

Завдання 15: Тимчасово відключити swap, щоб довести його як вузьке місце (обережно)

cr0x@server:~$ sudo swapoff -a
swapoff: /swap.img: swapoff failed: Cannot allocate memory

Значення: У вас недостатньо вільної RAM, щоб повернути сторінки зі swap в пам’ять. Swap тримає систему.

Рішення: Не робіть цього насильно. Спершу зменшіть використання пам’яті (зупиніть сервіси, знизьте навантаження) або додайте RAM. Відключення swap у цьому стані зробить OOM killer вашим новим SRE.

Завдання 16: Перевірити стан і витривалість NVMe (санітарна перевірка, не забобон)

cr0x@server:~$ sudo smartctl -a /dev/nvme0n1 | egrep -i "data units written|percentage used|critical_warning"
critical_warning                    : 0x00
percentage_used                     : 3%
data_units_written                  : 1,234,567 [632 TB]

Значення: Здоров’я диска виглядає добрим; використання витривалості низьке. Swap I/O не обов’язково смертельне.

Рішення: Зосередьтеся на продуктивності та стабільності. Не забороняйте swap через застарілі міфи про SSD; перевіряйте стан і метрики записів.

Безпечні схеми налаштування в Ubuntu 24.04

Схема A: Залиште дефолтний swapfile, але налаштуйте поведінку

Для більшості систем найпростіший безпечний підхід: зберегти /swap.img, переконатися, що він на ext4/xfs,
забезпечити роботу TRIM і помірно налаштувати swappiness.

Поставити swappiness постійно

cr0x@server:~$ echo 'vm.swappiness=20' | sudo tee /etc/sysctl.d/99-swappiness.conf
vm.swappiness=20

cr0x@server:~$ sudo sysctl --system | tail -n 3
* Applying /etc/sysctl.d/99-swappiness.conf ...
vm.swappiness = 20

Значення: Ядро буде намагатися сильніше тримати анонімну пам’ять у RAM і звільняти кеш спочатку.

Рішення: Використовуйте 10–30 для багатьох серверних навантажень. Уникайте значення 0 як «вимкнути swap» — це не те саме і може призвести до неприємної поведінки при reclaim.

Схема B: Використовувати zram як першу лінію, SSD swap як другу

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

Ubuntu може вже надавати zram через пакети і пресети залежно від інсталяції. Якщо ви вмикаєте його самостійно — тримайте помірний розмір.
Надмірне виділення zram перетворює «стискання» на «чому робить гучний шум кулер у датацентрі».

Схема C: Виділений swap-розділ на SSD (рідко необхідно)

Swap-розділи все ще придатні. Вони можуть бути простішими для hibernate і уникати деяких файлових межових випадків.
Але для більшості продакшн-парків swapfile простіше змінювати за розміром і керувати через конфігураційні інструменти.

Безпечне зміни розміру swapfile

Безпечна послідовність: відключити swapfile, змінити розмір, виставити права, створити підпис swap, увімкнути назад, перевірити.
Небезпечна послідовність — «truncate живий swapfile і молитися».

cr0x@server:~$ sudo swapon --show
NAME      TYPE SIZE USED PRIO
/swap.img file 8G   0B   -2

cr0x@server:~$ sudo swapoff /swap.img

cr0x@server:~$ sudo fallocate -l 16G /swap.img

cr0x@server:~$ sudo chmod 600 /swap.img

cr0x@server:~$ sudo mkswap /swap.img
Setting up swapspace version 1, size = 16 GiB (17179865088 bytes)
no label, UUID=2b4b2b0a-3baf-4c5d-9b7e-8e8d7d0f5b43

cr0x@server:~$ sudo swapon /swap.img

cr0x@server:~$ swapon --show
NAME      TYPE SIZE  USED PRIO
/swap.img file 16G   0B   -2

Значення: Swap змінено за розміром і активовано.

Рішення: Оберіть розмір, що відповідає вашій меті: виживання при аварії та оперативний контроль, а не постійна заміна RAM.

SSD-гігієна, яка справді має значення

• Уникайте контенції пристроїв: не розташовуйте swap на тому ж завантаженому NVMe, що і ваша основна база даних, якщо можна уникнути.
• Тримайте TRIM увімкненим: weekly fstrim.timer достатній для більшості.
• Не панікуйте щодо зносу без доказів: перевірте SMART/NVMe метрики та припущення про write amplification перед тим, як оголосити swap «небезпечним».
• Використовуйте пріоритети: якщо у вас кілька бекендів swap (zram + SSD swapfile), встановлюйте пріоритети свідомо.

Коли не слід використовувати swap на SSD

Є реальні випадки, коли swap на SSD — неправильне рішення. Не тому, що SSD — тендітні квіти,
а тому що I/O зі swap у невідповідному місці може посилити системний збій.

1) Ноди зберігання і сервери баз даних із насиченими дисками

Якщо ваш NVMe вже зайнятий обслуговуванням операцій бази даних або реплікації зберігання, swap конкурує в тих самих чергах.
Під тиском пам’яті латентність зростає, виникає більше таймаутів, повторів, більше навантаження, більше swap — і починається спіраль.

У таких системах правильніша відповідь: підібрати RAM під робочий набір, встановити ліміти пам’яті і тримати swap мінімальним — іноді навіть вимкненим — якщо ви можете гарантувати, що він не знадобиться.
Ось де більшість команд починають брехати собі.

2) Сервіси з ультра-низькою латентністю

Якщо ви запускаєте сервіси з жорсткими SLO на хвостову латентність і спіковою поведінкою, page fault зі swap може порушити SLO так, що важко відтворити.
Ваші метрики покажуть «один дивний сплеск», який зіпсує день.

3) Неправильні очікування щодо hibernate

Якщо вам «потрібна гібернація», але ви не налаштували resume для swapfile, ви рано чи пізно протестуєте гібернацію в невдалий момент.
І система не повернеться.

4) Шифрований root з складними ранніми-boot обмеженнями (крайові випадки)

Swap на зашифрованому root підходить для звичайного свапінгу. Hibernate-resume додає складність: initramfs має знайти область swap рано.
Якщо ви не хочете брати на себе цю складність — не стверджуйте, що вам потрібна гібернація.

Жарт №2: Нічого так не кричить «п’ятниця після обіду», як виявлення того, що ваша «тимчасова зміна swap» була вписана в золотий образ шість місяців тому.

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

1) Симптом: хост «піднятий», але SSH займає 20–60 секунд

Причина: swap-треш (велика латентність page fault) і CPU застрягає в reclaim; інтерактивні shell постійно викликають page fault.

Виправлення: Підтвердіть через vmstat (si/so) і PSI. Негайно зменшіть навантаження (зупиніть винуватця), потім додайте RAM або обмежте використання пам’яті. Розгляньте zram як пом’якшувальний захід.

2) Симптом: swap заповнений, але si/so близько нуля

Причина: Історичне використання swap; витягнуті сторінки холодні і не звертаються. Саме по собі це не активний інцидент.

Виправлення: Якщо продуктивність в порядку — нічого не робіть. Якщо хочете повернути swap, виконайте swapoff/swapon у вікні технічного обслуговування лише якщо є достатньо вільної RAM.

3) Симптом: OOM kills відбуваються навіть при достатньому swap

Причина: ліміти cgroup (контейнери), або раптові сплески алокацій, коли reclaim не встигає, або політики oom_score_adj, що спрямовують на неправильний процес.

Виправлення: Перевірте ліміти cgroup, налаштування swap у runtime контейнера та журнали ядра. Виправте споживача пам’яті або підніміть ліміт; не просто збільшуйте swap.

4) Симптом: NVMe %util застиг на ~100% і все сповільнюється

Причина: swap I/O конкурує з основним навантаженням I/O, часто на тому ж пристрої.

Виправлення: Перемістіть swap на менш навантажений пристрій або зменшіть свапінг, додавши RAM / зменшивши робочий набір. Якщо можливо, ізолюйте класи I/O через cgroups і контролери I/O, але не чекайте чудес.

5) Симптом: увімкнення zram робить систему повільнішою

Причина: навантаження обмежене CPU; накладні витрати стиснення відбирають цикли у застосунку. Або zram надто великий і викликає хитання.

Виправлення: Заміряйте час CPU і load. Зменшіть розмір zram або відключіть його на цьому класі хостів; використовуйте SSD swap як резерв, якщо доречно.

6) Симптом: swapfile існує, але зовсім не використовується

Причина: swap вимкнений, неправильний запис у /etc/fstab або systemd-юнит неактивний.

Виправлення: Запустіть swapon --show. Переконайтеся, що /etc/fstab містить swapfile і що права встановлені правильно (0600), потім увімкніть swap.

7) Симптом: гібернація не вдається або резюмує у ребут

Причина: resume offset не налаштований для swapfile, або swap недостатній, або ранній етап завантаження не може дістатися до пристрою бекапу.

Виправлення: Якщо вам обов’язково потрібна гібернація — використовуйте swap-розділ або налаштуйте resume для swapfile і перебудуйте initramfs. Інакше перестаньте вдавати, що гібернація — це вимога.

Чеклісти / покроковий план

Чекліст A: Вирішіть, чи прийнятний swap на SSD для цього хоста

1. Чи критична латентність з жорсткими хвостовими SLO? Якщо так — тримайте swap мінімальним і зосередьтесь на розмірі RAM та лімітах.
2. Чи SSD вже сильно завантажений для основних I/O? Якщо так — swap конкуруватиме і може посилити інциденти.
3. Чи потрібна гібернація? Якщо так — сплануйте розмір swap і конфігурацію resume ретельно.
4. Чи ви запускаєте контейнери зі строгими лімітами пам’яті? Якщо так — перевірте налаштування cgroup щодо swap; хостовий swap не врятує контейнер, який не дозволено користуватися ним.
5. Чи є у вас моніторинг тиску пам’яті (PSI), активності swap і дискової латентності? Якщо ні — ви летите за приладами, які не встановили.

Чекліст B: Розгорнути безпечний swapfile на Ubuntu 24.04 (ext4 root)

1. Перевірте тип файлової системи: findmnt -no FSTYPE / має бути ext4/xfs.
2. Перевірте поточний swap: swapon --show.
3. Якщо змінюєте розмір, впевніться, що використання swap низьке і RAM має запас; тоді виконайте swapoff для файлу.
4. Створіть/змінить розмір за допомогою fallocate або dd (fallocate підходить для ext4).
5. Виставте права: chmod 600.
6. Форматуйте під swap: mkswap.
7. Увімкніть: swapon.
8. Переконайтеся в постійності в /etc/fstab (або покладайтеся на існуючу конфігурацію Ubuntu).
9. Перевірте через free -h і swapon --show.

Чекліст C: Стабілізувати хост у стані трешингу (повернути контроль)

1. Підтвердьте треш: vmstat 1 і cat /proc/pressure/memory.
2. Знайдіть винуватця: ps/smem, потім метрики на рівні застосунку.
3. Зменшіть навантаження: зупиніть неважливі воркери, призупиніть пакетні роботи, знизьте паралельність.
4. Безпечно звільніть пам’ять: перезапустіть винуватця, якщо він витікає, або очищуйте кеші лише якщо розумієте наслідки (зазвичай не варто).
5. Лише після цього розгляньте зміну розміру swap/zram як короткострокове пом’якшення.
6. Після стабілізації: виправте корінь проблеми (витік пам’яті, некоректні ліміти, недопровізування або шумний сусід).

Три корпоративні міні-історії (анонімізовані, правдоподібні, технічно болючі)

Інцидент через неправильне припущення: «Swap вимкнено в контейнерах, отже хост не має значення.»

Команда запускала набір Java і Node сервісів на Ubuntu-хостах під контейнерним runtime. Вони вважали, що swap — це «питання контейнера»,
і що вимкнення swap на хості безпечне, бо «контейнери все одно мають ліміти пам’яті».
Вони вимкнули swap по середовищу, щоб «зробити продуктивність більш передбачуваною».

Перший сигнал проблеми був не про продуктивність. Це був uptime. Періодичні сплески — хвилі деплоїв, прогрів кешу, кілька клієнтських пакетних робіт —
почали викликати OOM kills. Не акуратні рестарти, а ядро вбивало найбільший процес у cgroup в моменті,
іноді це був сайдкар для логування, іноді — головний API-процес.

Неправильне припущення було тонким: ліміти cgroup були встановлені, але сплески були легітимні.
Без swap не було буфера для тимчасових піків. Команда налаштувала heap JVM близько до лімітів і припускала, що решта пам’яті
(native allocations, mmap, JIT overhead) поводитиметься.

Після повернення swap — помірного, з консервативним swappiness — події OOM помітно зменшилися. Продуктивність не стала «непередбачуваною».
Вона стала виживаною. Реальне вирішення пізніше було: більше пам’яті та реалістичніші ліміти контейнерів.
Swap не був рішенням, а ременем безпеки.

Оптимізація, що обернулась проти: «Поставити swap на найшвидший NVMe і підвищити swappiness для кращого кеша.»

Інша організація мала NVMe скрізь та культуру цінування хитрих налаштувань. Хтось запропонував: поставити swap на NVMe,
підвищити swappiness і дозволити ядру переміщувати холодні сторінки, щоб файловий кеш зростав. Декілька тестів виглядали добре.

Потім реальність прийшла: хост зі змішаними навантаженнями — база даних, стек метрик і пакетні завдання. Під щоденним батч-раном
тиск пам’яті виріс і ядро почало свапити. NVMe, вже зайнятий базою даних, досяг насичення.
Латентність зросла. Запити бази сповільнились. Повторні спроби збільшили навантаження. Система почала ще більше свапити, бо процеси чекали довше,
тримаючи пам’ять зайнятою. Класична петля зворотного зв’язку.

Найгірше: графіки були заплутаними. CPU не був зафіксований. Мережа була в порядку. Команда дивилася на метрики застосунків,
поки хост тихо чергував I/O, наче колекціонував марки.

Остаточне виправлення було неелегантним: знизити swappiness, ізолювати пакетну роботу на інший клас нод і перестати ставити swap у ту саму I/O-зону, що й базу даних.
Урок не в тому, що swap поганий. Урок у тому, що swap — це I/O, і I/O — спільний ресурс, визнавайте це.

Нудна, але правильна практика, що врятувала день: «Ми тримали малий swap, zram і алерти на тиск пам’яті.»

Одна платформа керувала флотом Ubuntu 24.04 VM з помірним RAM. Вони мали простий стандарт:
малий SSD-backed swapfile, zram увімкнений у консервативному розмірі і алерти на memory PSI та ставки swap-in.
Без геройств. Без «swap завжди зло». Просто дефолти з запобіжниками.

Якось оновлення агента від постачальника внесло витік пам’яті. Аґент не був критичним, але запускався всюди.
Протягом кількох годин тиск пам’яті повільно зростав. На хостах без swap такий витік викликає раптові OOM і каскадні рестарти.

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

Swap не запобіг витоку. Моніторинг не запобіг витоку. Комбінація не дала перетворитися поганому деплою на всефлотський простій.
Це виглядає як надійність у будні: нудно, вимірно і тихо ефективно.

FAQ

1) Чи безпечно ставити swap на SSD з погляду диска?

Зазвичай — так. Сучасні SSD мають вирівнювання зносу та витривалість, що значно кращі за ранні споживчі моделі. Перевіряйте SMART-метрики NVMe і обсяги записів.
Якщо ви свапите постійно — у вас проблема ємності, а не «проблема swap».

2) Скільки swap мені потрібно на Ubuntu 24.04?

Для серверів часто 2–8 GiB як буфер безпеки, більше якщо бувають епізодичні сплески і ви можете терпіти уповільнення. Для десктопів/ноутбуків — достатньо, щоб згладжувати піки,
і достатньо для hibernate, якщо ви ним користуєтесь. Для hibernate розмір swap приблизно повинен дорівнювати RAM (точні потреби залежать від стиснення і навантаження).

3) Swapfile чи swap-розділ?

Swapfile легше змінювати за розміром і автоматизувати. Swap-розділ простіший для hibernate і уникає файлових обмежень.
На ext4 swapfile — надійний дефолт.

4) Чи ставити swappiness в 1 або 0?

Не робіть це рефлекторно. Значення 10–30 підходять для багатьох серверів, щоб віддавати перевагу RAM. Значення 0 поводиться відмінно від «майже ніколи свапити»
і може спричинити неприємні патерни reclaim під тиском.

5) Чому swap використовується, навіть якщо є «вільна» RAM?

Бо «free» — це не єдина мета. Ядро балансує між анонімною пам’яттю і файловим кешем, і може тримати кеш гарячим, витісняючи холодні анонімні сторінки.
Дивіться на available у free -h, а не лише на free.

6) Чи замінює zram SSD swap?

Ні, він доповнює. zram швидший і уникає дискового I/O, але використовує CPU і все ще займає RAM (стиснену). SSD swap повільніший, але дає більший бекап.
Звичний патерн: з високим пріоритетом zram, з нижчим — SSD swap.

7) Чи можу я повністю вимкнути swap?

Так, але робіть це лише якщо ви протестували піки пам’яті, маєте правильні ліміти пам’яті і приймаєте, що OOM kills будуть відбуватись швидше і різкіше.
Вимкнення swap не вирішує витоки пам’яті або недопровізування нод. Воно просто змінює режим відмови.

8) Як зрозуміти, що swap спричинює мою латентність?

Дивіться на активність swap-in/out у vmstat, підвищений memory PSI і дискову латентність/черги в iostat.
Саме високе використання swap не є доказом; важлива кореляція активності swap зі затримками.

9) Чи допоможе перенесення swap на інший SSD?

Може, якщо поточний пристрій контендиться. Продуктивність swap в основному про латентність під навантаженням.
Перенесення swap з того ж зайнятого пристрою, що й база даних, може посилити найгірші моменти.

Наступні кроки, які ви можете зробити вже сьогодні

Якщо ви працюєте на Ubuntu 24.04 з SSD, розумний базовий підхід: зберігайте помірний swapfile, переконайтеся, що TRIM увімкнений,
і налаштовуйте swappiness тільки після вимірювання реального тиску пам’яті. Додавайте zram якщо він допомагає вашому класу хостів, а не тому, що це модно.

Зробіть ці три речі далі:

1. Виміряйте: запустіть swapon --show, vmstat 1, iostat -xz 1 і перевірте /proc/pressure/memory під час періоду уповільнення.
2. Вирішіть: якщо у вас трешинг, виправте робочий набір (ліміти, витоки, ємність). Якщо ви просто носите холодні сторінки, не перебільшуйте реакцію.
3. Зміцніть: тримайте swap помірним, встановіть консервативний swappiness (часто 10–30 на серверах) і налаштуйте алерти на тиск пам’яті, перш ніж користувачі покличуть вас.

Swap на SSD — не гріх. Це інструмент. Користуйтеся ним як інструментом: з вимірюваннями, з чіткими цілями і з планом на випадок, коли його не вистачає.