Debian 13: підводні камені swapfile — створіть його правильно (права, fstab, пріоритет)

Факти й контекст (чому swapfile досі підводить)

Swapfile не нові. Нове — це скільки шарів може втрутитися: файлові системи з копіюванням при записі (CoW), шифрування, обмеження пам’яті cgroups, zram та порядок запуску systemd. Swapfile може існувати, бути «увімкненим» і при цьому бути марним (або шкідливим), якщо він повільний, фрагментований, на неправильній файловій системі або конкурує з іншим swap-пристроєм з вищим пріоритетом.

8 коротких фактів і історичних відомостей

1. Swap старший за Linux: UNIX-подібні системи використовували пейджинг з 1970-х; Linux успадкував концепцію і з часом суттєво еволюціонував поведінку віртуальної пам’яті.
2. Раніше стандартною відповіддю були розділи swap, бо вони були передбачувані: суміжні блоки, без сюрпризів метаданих файлової системи.
3. Historично swapfile вважали «другосортними» на деяких файлових системах, бо відстеження блоків було складнішим, фрагментація важила сильніше, а вимоги для гібернації були суворі.
4. Сучасні ядра можуть ефективно використовувати swapfile на традиційних файлових системах (ext4/XFS), якщо файл правильно виділений і не є sparse — проте люди все ще випадково створюють sparse swapfile.
5. Btrfs ускладнив swapfile: copy-on-write та стиснення конфліктують із очікуваннями swap. Сучасні ядра підтримують це з обмеженнями (nocow, без стиснення, правильне виділення), але помилитися легко.
6. Пріоритет існує давно: Linux може розподіляти I/O swap між областями однакового пріоритету; це не просто «вибрати один». Неправильно встановлені пріоритети створюють дивну поведінку.
7. Swappiness — не «регулятор швидкості»; це регулятор політики. Багато команд неправильно використовують його як фікс продуктивності, потім дивуються, чому затримка зросла під навантаженням.
8. Гібернація — інша історія: вона потребує, щоб шлях відновлення знайшов точну область swap, де збережено образ; swapfile може працювати, але лише якщо конфігурація resume відповідає реальності.

Цитата варта того, щоб повісити її над терміналом:

«Надія — це не стратегія.» — Gen. Gordon R. Sullivan

Налаштування swap — ідеальне місце, щоб припинити сподіватися.

Як має виглядати «правильно» на Debian 13

Правильна конфігурація swapfile на Debian 13 має такі властивості:

• Swapfile є не-sparse (реально виділені блоки).
• Права — 0600, власник root.
• Воно розташоване на файловій системі, яка безпечно підтримує swapfile для вашого випадку (ext4 і XFS — «нудно добре»; Btrfs вимагає додаткової уваги; ZFS — окрема розмова).
• Воно вмикається під час завантаження через /etc/fstab (або systemd-юніт), і ви можете підтвердити це командою swapon --show.
• Пріоритет задано свідомо: ви знаєте, яка область swap має використовуватися першою і чому.
• Є моніторинг: ви бачите тиск на пам’ять, використання swap і великі page fault до того, як користувачі почнуть скаржитися на таймаути.

Дві істини про swap, які варто прикріпити на стіну:

• Swap не замінює планування ємності. Це страховка, а не матрац.
• Якщо ви покладаєтесь на swap для стабільної продуктивності, ви будуєте генератор затримок.

Жарт №1: Swap як кофеїн: корисний у надзвичайних ситуаціях, але якщо це частина вашого щоденного раціону — десь «зламалося» вгорі.

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

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

Спочатку: підтвердіть, що swap існує і активний

• Перевірте активні області swap і їхні пріоритети.
• Підтвердіть, що swapfile не ігнорується мовчки через права або обмеження файлової системи.

По-друге: підтвердіть тиск на пам’ять (не лише CPU або I/O)

• Перевірте MemAvailable, швидкість swap in/out і великі page fault.
• Шукайте OOM kills: вони — найгучніший симптом «swap відсутній або неефективний».

По-третє: визначте, чи swap допомагає чи шкодить

• Якщо I/O swap високий і затримка диска зростає, ви в режимі thrash.
• Якщо використання swap помірне і стабільне, а система залишається чутливою — swap виконує свою роботу.

По-четверте: ізолюйте процес, що створює проблему

• Визначте процеси, які збільшують RSS або викликають page fault.
• Перевірте обмеження cgroup і налаштування контейнерів, якщо застосовно.

По-п’яте: прийміть рішення

• Короткостроково: додайте ОЗП, додайте swap, зменшіть concurency або вбийте процеси, що розбігаються.
• Середньостроково: виправте витоки пам’яті, правильно розміркуйте ресурси і забезпечте розумну конфігурацію swap.

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

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

Завдання 1 — Подивіться, чи увімкнений swap (і який пріоритет)

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
NAME      TYPE  SIZE  USED PRIO
/swapfile file   8G  256M   -2

Значення: Swap увімкнено і використовується (256M). Пріоритет — -2; від’ємні пріоритети нормальні для swapfile, якщо ви не вказували інше.

Рішення: Якщо нічого не показується, у вас немає активного swap. Виправте це перед будь-яким тюнінгом.

Завдання 2 — Переконайтеся, що ядро бачить swap

cr0x@server:~$ cat /proc/swaps
Filename                                Type            Size            Used            Priority
/swapfile                               file            8388604         262144          -2

Значення: Ядро бачить swapfile; розмір і використання в KiB.

Рішення: Якщо swapfile відсутній тут, але є на диску, активація не вдалася — перевірте права, fstab і обмеження файлової системи.

Завдання 3 — Швидко перевірити тиск на пам’ять

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        27Gi       1.2Gi       412Mi       3.0Gi       2.8Gi
Swap:          8.0Gi       256Mi       7.8Gi

Значення: «available» — найкращий швидкий індикатор; 2.8Gi available свідчить про присутній, але не катастрофічний тиск. Swap використовується слабо.

Рішення: Якщо «available» дуже малий і використання swap швидко зростає, ви наближаєтесь до thrash або OOM.

Завдання 4 — Визначити, чи відбувається свопінг прямо зараз

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 262144 1248932 212344 2912456    0    0    12    45  241  512  9  3 87  1  0
 1  0 262144 1251120 212352 2911988    0    0     0    16  198  430  7  2 90  1  0
 3  1 270336  312144 212360 3014332  512 1024   800  1200  412  980 18  7 52 23  0
 2  1 285696  140512 212368 3040012  768 2048   900  1500  430 1100 20  8 41 31  0
 1  0 285696  210224 212376 3038008    0    0   110   220  260  600 11  4 83  2  0

Значення: Стовпці si/so показують swap-in/out за секунду. Стрибки (512/1024 тощо) вказують на активний свопінг.

Рішення: Якщо постійні значення si/so відмінні від нуля і wa зростає, ймовірний тиск пам’яті плюс I/O-конкуренція. Визначте навантаження і розгляньте додавання ОЗП або зменшення пам’ятевого сліду.

Завдання 5 — Перевірка OOM kills (квитанція «у вас не було плану»)

cr0x@server:~$ journalctl -k -g "Out of memory" -n 10 --no-pager
Dec 30 10:12:44 server kernel: Out of memory: Killed process 24891 (java) total-vm:14688208kB, anon-rss:12710492kB, file-rss:1420kB, shmem-rss:0kB, UID:1000 pgtables:27820kB oom_score_adj:0

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

Рішення: Якщо OOM відбувається і swap відсутній або замалий, додайте swap як страховку — але також виправте попит пам’яті. Якщо swap є, а OOM все одно трапляється, можливо swap недоступний (проблема файлової системи) або є обмеження memcg.

Завдання 6 — Перевірити права swapfile (безпека та коректність)

cr0x@server:~$ ls -lh /swapfile
-rw------- 1 root root 8.0G Dec 30 09:58 /swapfile

Значення: -rw------- — це 0600. Саме це вам потрібно. Swap може містити потенційно чутливі дані.

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

Завдання 7 — Виявити sparse swapfile (мовчазні проблеми з продуктивністю та активацією)

cr0x@server:~$ filefrag -v /swapfile | head
Filesystem type is: ef53
File size of /swapfile is 8589934592 (2097152 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..  65535:   532480..  598015:  65536:
   1:    65536.. 131071:   598016..  663551:  65536:
   2:   131072.. 196607:   663552..  729087:  65536:
 /swapfile: 3 extents found

Значення: Невелика кількість екстентів — добре: ймовірно достатньо суміжно. Sparse-файл показував би дірки, і деякі інструменти попереджають при активації.

Рішення: Якщо ви бачите багато екстентів (сотні/тисячі) на обертових дисках, очікуйте болісного I/O для swap. Пересоздайте swapfile методом, який виділяє суміжні блоки, і тримайте його на швидкому сховищі.

Завдання 8 — Підтвердити тип файлової системи під swapfile

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

Значення: Swapfile на ext4: загалом безпечно і просто.

Рішення: Якщо воно на btrfs або zfs, прочитайте розділ про специфіку файлових систем перед тим, як святкувати перемогу.

Завдання 9 — Перевірте, що запис у fstab використовується (і не ігнорується)

cr0x@server:~$ grep -nE 'swap|swapfile' /etc/fstab
12:/swapfile none swap sw,pri=10 0 0

Значення: У вас є явний запис swapfile з пріоритетом 10.

Рішення: Якщо рядка swap немає, ви покладаєтесь на ручне swapon або допоміжний інструмент дистрибутива. Для серверів зробіть поведінку під час завантаження детермінованою через fstab або systemd.

Завдання 10 — Протестуйте активацію зараз (вловіть помилки одразу)

cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE  SIZE USED PRIO
/swapfile file   8G   0B   10

Значення: Ре-активація пройшла успішно і пріоритет застосовано.

Рішення: Якщо swapon видає помилки (права, дірки, не підтримується), виправте основну проблему замість її примусу.

Завдання 11 — Виміряти симптоми затримки I/O для swap-пристрою

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          14.21    0.00    5.10   18.33    0.00   62.36

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
nvme0n1          8.00    512.0     0.00   0.00   0.45    64.0     65.00   8192.0     0.00   0.00   4.80   126.0   0.32  12.00

Значення: Підвищений iowait плюс високі швидкості запису можуть бути наслідком swap-out. На NVMe кілька мс можуть бути прийнятні; на HDD — тут системи повільно вмирають.

Рішення: Якщо %iowait і await зростають під час тиску на пам’ять, swap є причиною; перенесіть swap на швидше сховище або зменшіть свопінг.

Завдання 12 — Перевірити swappiness і вирішити, чи чіпати його

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

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

Рішення: Не копіюйте механічно vm.swappiness=1. Змінюйте тільки з чіткою метою: наприклад, для затримкочутливих навантажень, які мають уникати swap, або для систем з обмеженою пам’яттю, де ви хочете швидше звільняти кеш.

Завдання 13 — Підтвердити, чи присутній zram (і чи конкурує)

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
/dev/zram0 partition  2G  0B   100
/swapfile  file       8G  0B    10

Значення: zram має набагато вищий пріоритет, тому буде використовуватися першим.

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

Завдання 14 — Якщо вас цікавить гібернація: знайти офсет swap (тільки для swapfile)

cr0x@server:~$ sudo filefrag -v /swapfile | awk '/^ *0:/{print $4}' | tr -d '.'
532480

Значення: Це фізичний офсет першого екстенту (в одиницях блоків файлової системи), використовуваний деякими налаштуваннями гібернації для обчислення resume_offset.

Рішення: Якщо ви гібернуєте, вам потрібна стабільна мапа swapfile і правильна конфігурація resume. Якщо не гібернуєте — не ускладнюйте систему під випадок, який вам не потрібен.

Створення swapfile — нудно правильно

Є два загальні підходи: виділити блоки через fallocate або записати нулі через dd. На сучасних ext4/XFS fallocate зазвичай швидкий і правильний. На деяких файлових системах або конфігураціях fallocate може створити екстенти в небажаний спосіб або взагалі відмовитися. Суть не в ідеології, а в передбачуваній поведінці.

Рекомендовано: swapfile на ext4/XFS з використанням fallocate

Це чистий шлях для більшості серверів Debian 13 на ext4/XFS.

cr0x@server:~$ sudo swapoff -a
cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=8b0a9a2e-35e6-4f1a-bf94-7a843e62c2e6
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show
NAME      TYPE  SIZE USED PRIO
/swapfile file   8G   0B   -2

Чому ці кроки в такому порядку:

• swapoff -a гарантує, що ви не змінюєте активну область swap (так, люди так роблять).
• Пересоздання уникає спадщини дивностей (дірки, прапори стиснення, CoW). Swap — не унікальна річ; ставтеся до нього як замінної.
• chmod 600 запобігає витоку і не дає swapon скаржитись або відмовлятись у більш суворих середовищах.
• mkswap записує заголовок swap. Без нього ядро не знає, що це за файл.

Коли використовувати dd натомість

Якщо ви на файловій системі, де fallocate дає щось схоже на sparse, відмовляється або створює дивні екстенти, використовуйте dd, щоб примусово виділити. Це повільніше, але чесніше.

cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo dd if=/dev/zero of=/swapfile bs=1M count=8192 status=progress
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 9 s, 954 MB/s
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB, 8.0 GiB) copied, 9.00726 s, 953 MB/s
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=52b75f13-10bd-4b0a-89c7-92b9c2aa9916
cr0x@server:~$ sudo swapon /swapfile

Правило рішення: Якщо filefrag показує абсурдну кількість екстентів або активація скаржиться на дірки, пересоздайте за допомогою dd або перенесіть swapfile на більш підходящу файлову систему.

Жарт №2: Sparse swapfile як «бездротовий» кабель живлення — технічно існує, але не те, що ви мали на увазі.

Безпека: права й куди потрапляють дані swap

В swap можуть потрапити шматки всього: приватні ключі TLS у пам’яті, токени сесій, відкриті паролі, які перебували в буфері мить. Ваш swapfile має бути у власності root з правами 0600. Це не паранойя. Це буденна турбота.

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

fstab: записи, порядок і пастки

Swap, що не піднімається під час завантаження, — це swap, якого у вас немає. Для серверів я віддаю перевагу /etc/fstab, оскільки це явне і рецензоване. Ви також можете використовувати systemd swap-юніти, але бавитись доведеться тими самими інструментами діагностики.

Хороший запис swapfile у fstab

cr0x@server:~$ sudo sh -c 'printf "%s\n" "/swapfile none swap sw,pri=10 0 0" >> /etc/fstab'
cr0x@server:~$ tail -n 3 /etc/fstab
# swap was on /dev/sda3 during installation
/swapfile none swap sw,pri=10 0 0

Значення: Система активує /swapfile під час завантаження з пріоритетом 10.

Рішення: Оберіть пріоритет свідомо. Якщо у вас кілька областей swap, пріоритет вирішує, що буде використовуватися першим (і чи ядро робитиме роузподіл).

Поширені пастки в fstab, що відбирають години

• Неправильний шлях: ви створили /swapfile, а в fstab написали /swap.img.
• Пробіли або приховані символи: копіпаст із чату може додати небезпечні пропуски. Так, я бачив це.
• Swapfile на монті, що піднімається пізно: якщо /swapfile розміщено на окремому файловому розділі, який не змонтувався, swap не активується. Це може бути тихою помилкою, якщо ви не читаєте журнали завантаження.
• Припущення, що fstab означає успіх: він лише означає спробу. Після завантаження перевіряйте swapon --show.

Перевірте, чи systemd насправді його активував

cr0x@server:~$ systemctl status swapfile.swap --no-pager
Unit swapfile.swap could not be found.

Значення: У вас немає явного юніта з іменем swapfile.swap. При використанні fstab systemd генерує юніти динамічно; імена залежать від кодування шляху.

Рішення: Не ганяйтесь за іменем юніта насамперед. Підтвердіть активацію через swapon, потім, за потреби, перегляньте згенеровані юніти:

cr0x@server:~$ systemctl list-units --type=swap --all --no-pager
  UNIT           LOAD   ACTIVE SUB    DESCRIPTION
  dev-zram0.swap loaded active active /dev/zram0
  swapfile.swap  loaded active active /swapfile

LOAD   = Reflects whether the unit definition was loaded.
ACTIVE = The high-level unit activation state.
SUB    = The low-level unit activation state.

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

Пріоритет swap: що він робить і як ним користуватися

Пріоритет — це місце, де «на моєму ноуті працює» перетворюється на заплутану серверну поведінку. Linux використовує пріоритет swap, щоб вирішити, з яких областей виділяти пам’ять. Вищий пріоритет використовується першим. Області з однаковим пріоритетом можуть використовуватися збалансовано (уявіть розподіл I/O), що корисно, якщо у вас кілька однаково швидких пристроїв, і дуже погано, якщо ви випадково робите stripe між швидким NVMe і старим HDD.

Практичні шаблони пріоритетів

• zram першим (високий пріоритет): використовувати стиснуту swap в RAM для коротких піків без звернення на диск.
• швидкий диск другим: NVMe swapfile/розділ як наступний рівень.
• повільний диск останнім (або ніколи): HDD може тримати систему живою, але покарає за затримки.

Встановити пріоритет у fstab

Приклад: віддати перевагу zram, потім swapfile.

cr0x@server:~$ sudo sed -i 's#^/swapfile .*#\/swapfile none swap sw,pri=10 0 0#' /etc/fstab
cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo swapon /swapfile
cr0x@server:~$ swapon --show --output=NAME,SIZE,PRIO
NAME      SIZE PRIO
/dev/zram0   2G  100
/swapfile    8G   10

Рішення: Якщо бачите однакові пріоритети на пристроях різної швидкості, виправте це. Передбачуваність краща за випадкове стріпування.

Знати, що означає «пріоритет -2»

Коли ви запускаєте swapon без зазначення пріоритету, ядро присвоює стандартний. Розділи swap часто отримують вищий пріоритет за swapfile залежно від способу активації. Це важливо, коли у вас є обидва і ви припускаєте, що «новий swapfile» працює, тоді як система продовжує навантажувати старий swap-розділ.

cr0x@server:~$ swapon --show --output=NAME,TYPE,SIZE,USED,PRIO
/dev/sda2 partition  4G  1.2G   -1
/swapfile  file       8G  128M   -2

Рішення: Якщо ви хочете, щоб swapfile був у пріоритеті, встановіть pri вищим, ніж у розділу (або відключіть розділ). Не припускайте.

Пастки, пов’язані з файловими системами (ext4, XFS, Btrfs, ZFS)

Тут живе більшість «готч» зі swapfile. Підсистема swap потребує стабільного відображення блоків. Деякі файлові системи люблять переміщувати блоки з хороших причин (CoW, дефрагментація, reflink). Swap цього ентузіазму не поділяє.

ext4: за замовчуванням — не випадково

ext4 swapfile зазвичай безпечні. Ваші основні ризики:

• Створення sparse-файлу (поширено при використанні truncate або певних поведінок fallocate на дивних налаштуваннях).
• Розміщення swap на сильно фрагментованій файловій системі (більш болісно на HDD, ніж на SSD).
• Неправильні права або забування mkswap.

XFS: теж «нудно добре»

XFS swapfile загалом нормальні. Як і для ext4, забезпечте правильне виділення файлу та правильні права. XFS широко використовується в продакшені, і swapfile там не екзотика.

Btrfs: можливо, але не імпровізуйте

Btrfs має фічі, які конфліктують із swap: copy-on-write, стиснення і потенційно динамічне відображення екстентів. Сучасні ядра можуть підтримувати swapfile на Btrfs, але лише якщо swapfile відповідає обмеженням (без CoW, не стиснений і правильно виділений). Якщо ви не розумієте ці обмеження, ви створите swapfile, який активується сьогодні і відмовить після дефрагментації або balance.

Перевірки, які треба виконати, якщо swapfile на Btrfs:

cr0x@server:~$ findmnt -no FSTYPE,TARGET /swapfile
btrfs /
cr0x@server:~$ lsattr /swapfile
---------------------- /swapfile

Значення: Атрибути файлу тут не показують NOCOW (C). Це підозріло для Btrfs.

Рішення: Для swapfile на Btrfs зазвичай бажано NOCOW. Один зі способів — встановити атрибут на файл і тільки потім виділити простір. Якщо ви вже записали дані, можливо, доведеться пересоздати. Приклад потоку:

cr0x@server:~$ sudo swapoff /swapfile
cr0x@server:~$ sudo rm -f /swapfile
cr0x@server:~$ sudo truncate -s 0 /swapfile
cr0x@server:~$ sudo chattr +C /swapfile
cr0x@server:~$ sudo fallocate -l 8G /swapfile
cr0x@server:~$ sudo chmod 600 /swapfile
cr0x@server:~$ sudo mkswap /swapfile
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=0e1c4a2d-5d8d-4c08-a5c8-40db51b4dfc3
cr0x@server:~$ sudo swapon /swapfile

На що дивитися: Якщо swapon помилиться з «Invalid argument» або скаржитись на дірки, екстенти файлу неприйнятні. Не примушуйте; перенесіть swap на розділ swap або на файлову систему без CoW.

ZFS: зазвичай swapfile — неправильний інструмент

На ZFS swapfile відомі як проблемні, оскільки ZFS — copy-on-write і не дає тих самих гарантій, яких очікує swap. Багато операторів використовують розділ swap або zvol для swap. Якщо ви запускаєте Debian на ZFS root, план «swapfile на ZFS dataset» може стати пасткою продуктивності та надійності.

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

• Якщо ви на ZFS і хочете swap, віддавайте перевагу виділеному розділу swap або zvol з належною конфігурацією.
• Якщо ви мусите використовувати swapfile, тестуйте ретельно під навантаженням пам’яті, підтверджуйте, що снапшоти/recordsize/compression не шкодять вам, і готуйтеся до неприємних сюрпризів.

Налагодження продуктивності та надійності (що важливо, а що ні)

Продуктивність swap переважно залежить від затримки сховища та уникнення паталогічного свопінгу. Ідеально налаштований swapfile на повільному сховищі все одно залишається повільним. Ваша ціль — не «ніколи не свопити». Ваша ціль — «залишатися живими та чутливими під очікуваним навантаженням».

Swappiness: політика, а не магія

За замовчуванням swappiness (часто 60) підходить для загальногo призначення. Зменшення може зменшити свопінг, але може збільшити тиск на page cache і викликати інші режими відмови (наприклад, ранні OOM у певних патернах). Збільшення може тримати більше кешу поза RAM, але це може штовхнути анонімні сторінки на диск раніше, що погіршить інтерактивну затримку.

cr0x@server:~$ sudo sysctl -w vm.swappiness=20
vm.swappiness = 20
cr0x@server:~$ sudo sh -c 'printf "%s\n" "vm.swappiness=20" > /etc/sysctl.d/99-swappiness.conf'
cr0x@server:~$ sysctl vm.swappiness
vm.swappiness = 20

Рішення: Змінюйте swappiness тільки після того, як переконалися, що swap правильно налаштований і ви можете відтворити патерн навантаження. Інакше ви просто змінюєте спосіб, у який система відмовляє.

Як виглядає «swap thrash»

Thrash — коли система витрачає більше часу на переміщення сторінок туди й назад, ніж на корисну роботу. Симптоми:

• Load average росте, тоді як CPU idle залишається ненульовим, але iowait стрибає.
• Інтерактивні відповіді стають від секунд до хвилин.
• vmstat показує постійний swap-in/out.
• Зростає затримка диска; підвищується глибина черги.

cr0x@server:~$ cat /proc/pressure/memory
some avg10=0.25 avg60=0.18 avg300=0.10 total=48239210
full avg10=0.07 avg60=0.05 avg300=0.02 total=10293829

Значення: PSI (Pressure Stall Information) показує час, коли завдання блокуються в очікуванні пам’яті. «full» означає блокування настільки серйозні, що прогрес неможливий.

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

Пріоритети та змішане сховище: не стріпуйте NVMe з HDD

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

Розмір: «скільки swap мені потрібно?»

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

• Загальні сервери: 2–8 GiB swap часто достатньо як страховка, якщо у вас адекватна RAM.
• Build/test ранери та JVM-хости: більший swap може купити час під піками, але треба контролювати затримки.
• Гібернація: swap має вміщувати образ гібернації (часто близько до розміру RAM, іноді менше з компресією, але не ризикуйте).

Коли сумніваєтесь: розмірюйте swap для короткого піку та щоб уникнути паніки/OOM, а не щоб зробити систему з недостатньою RAM «доброю».

Три корпоративні міні-історії з полів swapfile

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

Середня компанія запускала Debian на флоті CI-воркерів. Вони стандартизували крок «8G swapfile скрізь». Хтось написав автоматизаційний скрипт, який робив: створити файл, виконати mkswap, додати в fstab — і все. Це працювало в стейджингу. У продакшені — здебільшого працювало. «Здебільшого» — це звідки приходять інциденти.

Воркері мали мікс файлових систем: старі вузли були на ext4; нові — на Btrfs через бажання когось мати снапшоти. Автоматизація не визначала тип файлової системи. На Btrfs вузлах swapfile існував, але активація могла випадково провалитись на деяких перезавантаженнях і пройти на інших після операцій обслуговування. Симптоми були непостійні: деякі вузли були в порядку, інші раптово вбивали збірки під час піку навантаження.

Неправильне припущення було простим: «swapfile — це swapfile». Це не так. Поведінка файлової системи важлива, особливо CoW і семантика дефрагментації. Команда втратила день на пошук «випадкової поведінки ядра» і «витоків пам’яті JDK», перш ніж хтось порівняв swapon --show по вузлах і помітив, що половина флоту не має активного swap.

Виправлення було нудним і рішучим: виявляти Btrfs, створювати swap на виділеному розділі для тих хостів (або правильно налаштувати Btrfs swap з NOCOW і пересоздати), і додати перевірку на ранзі завантаження, яка попереджає, якщо swap не активний. Інцидент не був про розмір swap; він був про відсутню страхову сітку.

Міні-історія 2: Оптимізація, що обернулась проти

Фінтех-команда мала API із вимогами до низької затримки. Хтось прочитав, що swap викликає затримки, що в певному сенсі правда. Вони встановили vm.swappiness=1 по всьому флоту і зменшили розмір swap майже до нуля. Метрики виглядали чудово — до моменту, коли деплой додав невелике збільшення пам’яті.

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

Вони оптимізували для щасливого шляху й забрали буфер для нещасливого. Найдратівливіше: інцидент не був навіть великим витоком пам’яті. Це була нова фіча плюс сплеск трафіку плюс відсутність страховки.

Вони відкотили swappiness до розумного значення, відновили swap-ємність і ввели політику: зменшувати свопінг шляхом виправлення використання пам’яті, а не відключенням swap. Swap знову став тим, чим має бути: інструментом, що купує час для втручання, а не приховувачем хронічного недопропонування.

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

Команда внутрішньої платформи вела Debian 13 на наборі stateful-воркерів. Вони зробили нудну річ, яку мало хто ставить у пріоритет: скрипт перевірки на старті, який перевіряв активацію swap і логував чітку помилку, якщо він відсутній. Це було частиною перевірки «готовності вузла», поруч із простором на диску і коректністю NTP.

Під час планового оновлення ядра підмножина вузлів перестала вмикати swap після перезавантаження. Причина не була гламурною: зміни в зберіганні змінили порядок монтованих розділів, і шлях до swapfile тимчасово був недоступний у момент, коли systemd намагався його активувати. Ніхто не помітив цього відразу — крім перевірки готовності, яка відмітила вузли як нездорові і не допустила туди робочі навантаження.

Це запобігло гучному інциденту. Команда мала час переглянути journalctl, відрегулювати порядок запуску (а в декількох випадках перемістити swap) і поступово повернути вузли. Користувачі нічого не помітили. Керівництво не питало, чому графіки затримки схожі на сейсмограму. Це тихий успіх, який дають нудні контролі.

Урок: swap — не лише про продуктивність; це про операбельність. Передбачувана система краща за хитру.

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

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

1) Swapfile існує, але не вказаний у swapon

Симптом: ls /swapfile показує файл, але swapon --show порожній або не показує його.

Причина: Swap не активований (fstab відсутній/неправильний) або активація не вдалася при завантаженні.

Виправлення: Виконайте sudo mkswap /swapfile (якщо потрібно), потім sudo swapon /swapfile. Додайте правильний запис у fstab і підтвердіть після перезавантаження.

2) swapon відмовляється з «Operation not permitted» або «permission denied»

Симптом: sudo swapon /swapfile видає помилку.

Причина: Права не 0600, неправильний власник або політика безпеки блокує.

Виправлення: sudo chown root:root /swapfile && sudo chmod 600 /swapfile, потім повторіть спробу.

3) swapon відмовляється з «Invalid argument» на Btrfs

Симптом: Активація не вдається, незважаючи на правильні права.

Причина: Swapfile на Btrfs з CoW/сжаттям або з непідтримуваними екстентами/дірками.

Виправлення: Пересоздайте swapfile з NOCOW (chattr +C перед виділенням), вимкніть стиснення або використайте розділ swap/ zvol.

4) Система завантажується, але swap іноді відсутній після перезавантаження

Симптом: Swap присутній інколи, відсутній інколи при перезавантаженнях.

Причина: Гонка/порядок: swapfile на файловій системі, яка не змонтована, коли запускається активація swap; або обслуговування файлової системи змінило відображення екстентів так, що swap стає непридатним.

Виправлення: Розмістіть swap на root-файловій системі або забезпечте, щоб underlying mount був доступний рано; перевірте залежності systemd swap-юніта; розгляньте виділений розділ для надійності.

5) Інтенсивний свопінг викликає 10x затримку і таймаути

Симптом: Час відповіді вибухає; vmstat показує постійний si/so; iowait підскакує.

Причина: Робочий набір не вміщується в RAM; swap на повільному сховищі; або надмірна пам’яткова overcommit через конкуренцію.

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

6) Swap використовується, але першим використовується не та область

Симптом: Ви додали швидкий NVMe swapfile, але система продовжує свопити на HDD-розділ.

Причина: Пріоритети віддають перевагу розділу, або однакові пріоритети призводять до стріпування.

Виправлення: Встановіть явний pri= у fstab або через swapon -p, щоб віддати перевагу швидшому swap, і занижуйте/відключайте повільний swap.

7) Гібернація не працює після переходу на swapfile

Симптом: Відновлення не вдається; система завантажується «холодно».

Причина: Конфігурація resume не оновлена для swapfile офсету; swapfile переміщено/змінено екстенти.

Виправлення: Обчисліть правильний resume offset і оновіть конфігурацію initramfs відповідно, або використайте виділений розділ swap для стабільності гібернації.

8) «Ніякого swap» було навмисним, і тепер ви отримуєте OOM kills

Симптом: Процеси вбиваються під час сплесків; система нестабільна.

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

Виправлення: Поверніть помірний swap (і моніторинг), потім виправте витрати пам’яті і правильно розміркуйте хости.

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

План A: Стандартний сервер Debian 13 на ext4/XFS (swapfile)

1. Підтвердіть файлову систему: findmnt -no FSTYPE,TARGET /swapfile. Якщо ext4/XFS — продовжуйте.
2. Оберіть розмір: почніть з 4–8 GiB, якщо немає явної потреби (гібернація або великі сплески).
3. Створіть swapfile: fallocate -l 8G /swapfile.
4. Встановіть права: chmod 600 /swapfile; перевірте через ls -l.
5. Ініціалізуйте: mkswap /swapfile.
6. Увімкніть зараз: swapon /swapfile; перевірте swapon --show.
7. Зробіть постійним: додайте /swapfile none swap sw,pri=10 0 0 до /etc/fstab.
8. Тест перезавантаження: перезавантажте у вікні обслуговування; підтвердіть активний swap після старту.
9. Моніторинг: відслідковуйте використання swap, PSI пам’яті і OOM-події; сигналізуйте при стрибках swap або коли «full» pressure ненульовий тривалий час.

План B: Btrfs root (swapfile лише якщо ви знаєте обмеження)

1. Розгляньте, чи не простіше розділ swap: для багатьох продакшен-систем це так.
2. Якщо використовуєте swapfile: створіть файл з NOCOW перед виділенням блоків.
3. Переконайтесь, що стиснення вимкнено: не зберігайте swapfile у стисненому підтомі/датасеті.
4. Пересоздавайте, а не модифікуйте: ставтеся до swapfile як до незмінної одиниці. Якщо змінюєте атрибути після запису — це шлях до проблем.
5. Перевірте активацію зараз і після перезавантаження: якщо воно нестабільне — зупиніться і змініть підхід.

План C: Кілька областей swap (zram + дисковий swap)

1. Визначте порядок пріоритетів: zram найвище; NVMe далі; HDD останній.
2. Явно вкажіть пріоритети: не покладайтеся на значення за замовчуванням.
3. Перевірте ефективний порядок: swapon --show --output=NAME,PRIO.
4. Протестуйте під навантаженням пам’яті: доведіть систему до деградації, щоб підтвердити, що вона деградує плавно і не thrash.

Питання й відповіді

1) Чи використовувати розділ swap або swapfile на Debian 13?

На ext4/XFS: swapfile підходить і його легше змінювати за розміром. Якщо вам потрібна надійна гібернація або ви на складних файлових системах (особливо Btrfs/ZFS), розділ (або zvol на ZFS) часто безпечніший.

2) Які права має мати swapfile?

0600, у власності root. Все інше — ризик витоку даних і можливі помилки активації залежно від політик.

3) Чому мій swapfile показує пріоритет -2?

Це пріоритет, призначений за замовчуванням, коли ви не вказали його. Сам по собі це не помилка. Це стає проблемою, коли у вас кілька областей swap і вам важливо, яка використовується першою.

4) Чи завжди безпечно використовувати fallocate для swapfile?

Зазвичай безпечно на ext4/XFS. Не універсально безпечно на всіх файлових системах і конфігураціях. Якщо активація скаржиться на дірки або файл дивно фрагментований — пересоздайте через dd або перенесіть swap на простішу файлову систему.

5) Як зрозуміти, чи swap шкодить продуктивності?

Шукайте постійний swap-in/out (vmstat), зростаючий iowait (iostat) і підвищений «full» memory pressure (PSI). Якщо затримка відповіді зростає разом із цим — ви thrash.

6) Чи можна розмістити swapfile на Btrfs?

Так, але лише якщо дотримуватися обмежень (без CoW, без стиснення, стабільне виділення). Якщо не можете це гарантувати — використайте розділ swap. Надійність важливіша за новизну.

7) Якого розміру має бути swapfile для серверів?

Зазвичай 4–8 GiB як страховка, далі коригуйте за спостереженнями за піками і історією інцидентів. Якщо потрібна гібернація — розміруйте спеціально під цей випадок.

8) Чи ставити vm.swappiness=1 заради продуктивності?

Не за замовчуванням. Це може зменшити свопінг, але підвищити ризик OOM під час сплесків. Налаштовуйте на підставі даних навантаження, а не інтернет-порад.

9) Чому swap не вмикається при старті, хоча fstab правильний?

Часто причина — порядок монтовання: swapfile розташовано на файловій системі, яка недоступна, коли запускається активація swap. Перевіряйте журнали завантаження і згенеровані systemd-юніти, а також розгляньте переміщення swap.

10) Чи замінює zram дисковий swap?

Воно доповнює. zram гарний для поглинання коротких сплесків швидко. При тривалому тиску вам може знадобитися дисковий swap або більше RAM залежно від навантаження.

Висновок: наступні кроки, що реально знижують ризик

Якщо ви керуєте Debian 13 у продакшені, розглядайте swap як частину проектування системи, а не як пункт у чек-листі. Ваші наступні кроки прості й практичні:

1. Аудит стану swap по флоту: підтвердіть, що swap увімкнений, пріоритети навмисні, і активація послідовна після перезавантажень.
2. Спочатку виправте коректність: права 0600, не-sparse виділення, придатність файлової системи.
3. Зробіть поведінку при завантаженні детермінованою: fstab (або явні systemd swap-юніти), плюс перевірка здоров’я, яка сповіщає про відсутній swap.
4. Вимірюйте тиск на пам’ять: використовуйте vmstat, PSI і журнали OOM; не чекайте скарг від користувачів для моніторингу.
5. Використовуйте пріоритети, щоб уникнути сюрпризів: тримайте швидкий swap швидким, а повільний — лише як останній засіб, якщо взагалі зберігаєте його.

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