Jak ustawić swap i zram w Linuxie, żeby system nie mulił pod obciążeniem

Cel: responsywny Linux pod obciążeniem

Responsywność systemu pod obciążeniem zależy głównie od tego, jak kernel zarządza pamięcią i kiedy zaczyna intensywnie korzystać ze swapu. Dobra konfiguracja swapu i zram pozwala wykorzystać RAM możliwie efektywnie i uniknąć „mulenia”, czyli ciągłego mielania dyskiem i zacięć interfejsu.

Klucz tkwi w zrozumieniu kilku prostych mechanizmów: jak Linux używa RAM, co faktycznie oznacza zużycie pamięci, kiedy wchodzi do gry swap na dysku, a kiedy opłaca się użyć zram jako kompresowanego pseudo-swapu w RAM.

Jak Linux korzysta z pamięci – krótkie podstawy bez teorii dla teorii

RAM, page cache i kiedy zaczyna się swapowanie

Linux stara się wykorzystywać RAM możliwie maksymalnie. Pusta pamięć jest dla niego zmarnowanym zasobem. Dlatego w free -h często widać „zużyty” RAM, nawet gdy nic ciężkiego nie działa, a system działa płynnie.

Wolne miejsce w RAM jest wykorzystywane przede wszystkim na:

• page cache – buforowanie odczytanych z dysku plików,
• buffer cache – bufory operacji na blokach dyskowych,
• różne cache bibliotek, ikon, fontów, itp.

Te dane w cache mogą zostać szybko wyrzucone, gdy aplikacje potrzebują pamięci. Dzięki temu kolejne odczyty tych samych plików są szybsze, bo dane są już w RAM, a nie na dysku. To przyspiesza np. otwieranie często używanych programów.

Swapowanie zaczyna się, gdy kernel uznaje, że opłaca się „wyrzucić” z RAM rzadko używane strony pamięci procesów na dysk, żeby zostawić RAM na aktywne dane i cache. Decyzję podejmuje m.in. na podstawie vm.swappiness oraz bieżącego zapotrzebowania na pamięć.

Różnica między zużyciem RAM a „wolnym” RAM

Przydatne jest jedno polecenie:

free -h

Wynik pokazuje m.in. kolumnę available. To właśnie ten parametr mówi, ile pamięci możesz jeszcze realnie wykorzystać bez agresywnego swapowania, a nie sama liczba w kolumnie „free”.

Typowa sytuacja: „used” jest wysokie, „free” bardzo małe, ale „available” jest wciąż spore. To normalne. Oznacza to, że większa część „used” to cache, które system może zwolnić w razie potrzeby.

Problem zaczyna się, gdy available spada bardzo nisko, a system nie ma już co sensownie wyrzucać z cache. Wtedy kernel zaczyna przepychać strony pamięci procesów do swapu, co na wolnym dysku powoduje wyraźne „mulenie”.

Co się dzieje, gdy brakuje pamięci fizycznej: OOM vs swap

Po wykorzystaniu RAM i częściowo swapu, gdy nie ma już skąd brać pamięci, wchodzi do gry OOM-killer (Out Of Memory). Kernel wybiera procesy do „ubicia”, aby odzyskać pamięć.

Brak swapu nie oznacza, że będzie szybciej. Oznacza, że w sytuacji krytycznej procesy będą zabijane szybciej, zamiast zostać tymczasowo wypchnięte do swapu. Z kolei zbyt duży swap na wolnym dysku może doprowadzić do sytuacji, w której system zamiast ubić proces, przez długi czas mieli dyskiem, a użytkownik widzi zamrożony pulpit.

Optymalna konfiguracja dąży do tego, by:

• mieć niewielki, ale realny bufor bezpieczeństwa w swapie,
• unikać długotrwałego intensywnego I/O swapu (tzw. thrashing),
• pozwolić kernelowi wcześnie „oddychać” zramem, zamiast czekać na twardy OOM.

Typowe symptomy: przycinanie, zamrożenie pulpitu, ubijanie procesów

Przy złej konfiguracji swapu i zram, typowe objawy pod obciążeniem to:

• przycinanie na ruchach myszy, minimalizowaniu/zmaksymalizowaniu okien, przełączaniu kart w przeglądarce,
• zamrażanie pulpitu na kilkanaście–kilkadziesiąt sekund przy intensywnym I/O (np. kompilacja + przeglądarka + IDE),
• komunikaty w terminalu lub w dmesg o ubijaniu procesów przez OOM-killera,
• ciągłe świecenie się diody dysku, wysoki iowait w top / htop.

W takich sytuacjach zwykle pomaga korekta vm.swappiness, dołożenie zramu i ewentualnie lepszy podział między swapem na dysku a zramem.

Swap – po co w ogóle jest i kiedy pomaga, a kiedy szkodzi

Swapfile, partycja swap, brak swap – porównanie

Swap można mieć na trzy podstawowe sposoby:

• partycja swap – wydzielona partycja na dysku,
• plik swap (swapfile) – zwykły plik na istniejącym systemie plików, oznaczony jako swap,
• brak swapu – system opiera się tylko na RAM i ewentualnie zram.

Na współczesnych desktopach i serwerach najwygodniejszy jest plik swap. Daje elastyczność: można go szybko utworzyć, powiększyć albo zmniejszyć bez ruszania tablicy partycji.

Rola swapu: bufor bezpieczeństwa, nie zamiennik RAM

Swap nie jest po to, aby „dodać sobie RAM”. Jego główne zadania to:

• przechowywanie rzadko używanych stron pamięci, aby zwolnić RAM dla aktywnych danych,
• ratowanie systemu przed natychmiastowym OOM przy chwilowym piku zużycia pamięci,
• w niektórych konfiguracjach – obsługa hibernacji (suspend-to-disk).

Na dyskach SSD swap nie jest już takim dramatem jak na mechanicznych HDD, ale nadal intensywne swapowanie zabija responsywność. RAM ma o rzędy wielkości niższe opóźnienia niż dysk, nawet szybki NVMe.

Nie należy więc liczyć, że „dorzucenie 8 GB swapu” rozwiąże problem wiecznie za małego RAM. Swap pomaga zamortyzować skoki obciążenia i przenieść to, co rzeczywiście dawno nie było używane. Gdy jest używany intensywnie przez wiele minut – coś jest nie tak z konfiguracją albo obciążeniem.

Kiedy swap poprawia stabilność, a kiedy powoduje mulenie i thrashing

Swap jest korzystny, gdy:

• RAM jest czasem lekko za mały, ale zwykle wystarczający,
• procesy mają część pamięci, z której korzystają rzadko (duże IDE, Electrony, przeglądarki),
• system może spokojnie „odsunąć na bok” takie rzadko używane dane bez katowania dysku.

Swap szkodzi, gdy:

• aplikacje stale pracują na całej swojej przestrzeni pamięci (np. baza danych trzymająca w pamięci duże indeksy),
• swap jest zbyt mały i szybko się zapycha – system dusi się pomiędzy OOM a swapem,
• dystrybutor ustawił zbyt agresywne vm.swappiness, przez co kernel zbyt chętnie wypycha dane na dysk.

Najgorszy stan to thrashing – system non stop zapisuje i odczytuje strony pamięci ze swapu, zamiast realnie wykonywać pracę aplikacji. Objawia się to ogromnym iowait, zamrożeniem interfejsu i praktyczną nieużywalnością systemu.

Scenariusze: desktop, laptop, mały serwer, VM u dostawcy chmury

Inaczej konfiguruje się swap dla różnych przypadków użycia:

• Desktop (8–16 GB RAM) – jeden plik swap 2–4 GB, swappiness umiarkowany (20–40), dodatkowo zram jako szybki bufor.
• Stary laptop (4 GB RAM, HDD) – zram 2–4 GB, mały swap na dysku (1–2 GB) jako bufor awaryjny, niższy swappiness.
• Mały serwer / VPS (1–4 GB RAM) – swap potrzebny, ale raczej niewielki (1–2 GB) plus zram. Uwaga na politykę dostawcy chmury (I/O, throttling).
• Serwer bazodanowy – lepiej mieć dużo RAM i niewielki, ale istniejący swap; swappiness nisko, żeby baza nie wyleciała do swapu.

„Laptop bez swapfile” może działać, jeśli ma dużo RAM i nie używa się hibernacji, ale w przypadku zawodnej aplikacji (np. przeglądarka łykająca gigabajty RAM) szybciej pojawi się OOM-killer z utratą danych niż chwilowe zamulenie.

Zram – kompresowana pamięć zamiast klasycznego swapu na dysku

Zram vs swap na SSD/HDD

zram to specjalne urządzenie blokowe w RAM, na którym można np. założyć swap. Dane zapisane na zram są kompresowane w locie, co daje efekt „więcej logicznej pamięci” kosztem CPU, a nie I/O dysku.

Różnica praktyczna:

• swap na SSD/HDD – każde przepchnięcie strony pamięci oznacza operację I/O; szybki SSD łagodzi ból, HDD już niekoniecznie,
• zram – zapis/odczyt dzieje się w RAM, z dodatkowym narzutem na kompresję i dekompresję; skutkiem jest dużo niższe opóźnienie niż na dysku.

Dlatego na słabych laptopach z HDD, małych VM i starych maszynach zram często daje odczuwalny zysk – system zaczyna kompresować rzadziej używane dane w RAM, zanim sięgnie po wolny swap na dysku.

Jak działa zram: urządzenie blokowe w RAM z kompresją

Po włączeniu modułu zram kernel tworzy urządzenia /dev/zram0, /dev/zram1 itd. Każde można:

• ustawić na określony rozmiar logiczny (np. 4G),
• przypisać do niego algorytm kompresji (np. lz4, zstd, lzo),
• wykorzystać jako swap (mkswap + swapon) lub do innych celów (tmpfs, /var/tmp też bywa przenoszone na zram).

Realne zużycie RAM przez zram to rozmiar skompresowanych danych + narzut. Jeśli dane dobrze się kompresują (dużo pustych stron, powtarzalne wzorce), zram może zmieścić 2–3 razy więcej danych logicznych niż zarezerwowana pamięć. W praktyce zwykle daje to od kilkunastu do kilkudziesięciu procent „dodatkowego” RAM po kosztach CPU.

Zysk: mniej I/O kosztem CPU, szczególnie na słabszych dyskach

Najważniejsze korzyści zram:

• zanim system zacznie pisać po dysku, spróbuje skompresować dane w RAM,
• zmniejsza się liczba operacji I/O na swapie na dysku,
• na maszynach z HDD lub throttlowanym I/O w chmurze responsywność systemu wyraźnie się poprawia.

Kosztem jest dodatkowa praca procesora na kompresję/dekompresję. Na współczesnych CPU jest to zwykle akceptowalne, szczególnie przy lekkich algorytmach typu lz4. Zysk z mniejszego I/O jest często znacznie większy niż koszt kilku procent CPU.

Wady: dodatkowe obciążenie CPU, brak sensu na maszynach z dużą ilością RAM

Na serwerach z bardzo dużą ilością RAM (setki GB) i specyficznym obciążeniem (np. bazy danych, in-memory cache) zram może być zbędny albo wręcz szkodliwy. Baza danych potrafi sama zarządzać swoją pamięcią i korzysta intensywnie z całego alokowanego RAM. Kompresowanie tego w zram tylko niepotrzebnie obciąży CPU.

Również na mocno obciążonych procesorowo systemach (np. serwery CI, kompilacje, maszynowe uczenie) zbyt duży zram z agresywnym algorytmem kompresji może podkręcić load average i wprowadzić opóźnienia.

Najprostszą zasadą jest: im więcej RAM i im bardziej przewidywalne, „poważne” obciążenie, tym mniejszą potrzebę zramu i swapu, a większą kontrolę nad swappiness i polityką zarządzania pamięcią.

Kluczowe parametry jądra: vm.swappiness, vm.vfs_cache_pressure i pokrewne

vm.swappiness – jak chętnie kernel korzysta ze swapu

vm.swappiness określa, jak szybko jądro zacznie przerzucać strony pamięci do swapu. Skala to 0–100.

• 0–10 – swap używany dopiero, gdy naprawdę brakuje RAM,
• 20–40 – kompromis dla desktopów i laptopów,
• 60+ – agresywne wypychanie do swapu, typowe na serwerach ogólnego przeznaczenia lub w domyślnych ustawieniach niektórych dystrybucji.

Aktualną wartość pokazuje:

cat /proc/sys/vm/swappiness

Tymczasowa zmiana (do restartu):

sudo sysctl -w vm.swappiness=20

Na stałe (np. na desktopie z 8–16 GB RAM):

echo 'vm.swappiness=20' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

Jeśli interfejs „zamiera”, a dysk mieli przy dużym zużyciu RAM, zwykle warto zejść niżej z swappiness i dodać zram.

vm.vfs_cache_pressure – jak łatwo kernel wyrzuca cache katalogów i inode

vm.vfs_cache_pressure steruje, jak agresywnie zwalniane są cache inode i dentry (struktury używane przy dostępie do plików).

• 100 – domyślny, neutralny poziom,
• <100 – kernel chętniej trzyma cache plików,
• >100 – cache jest częściej czyszczony, RAM szybciej trafia do innych zadań.

Podgląd i jednorazowa zmiana:

cat /proc/sys/vm/vfs_cache_pressure
sudo sysctl -w vm.vfs_cache_pressure=50

Na desktopach z szybkim SSD ustawienie w okolicy 50–75 bywa sensowne: mniej I/O przy przełączaniu katalogów, mniejsze ryzyko, że kernel wytnie cache po to, by trzymać nieużywane dane procesów.

vm.min_free_kbytes i vm.lowmem_reserve_ratio – minimalna wolna pamięć

vm.min_free_kbytes to minimalna ilość RAM (w kB), jaką kernel stara się utrzymać jako wolną. Zbyt niska wartość może powodować skoki opóźnień przy nagłym alokowaniu pamięci.

Podgląd:

cat /proc/sys/vm/min_free_kbytes

Na większości nowoczesnych systemów nie ma potrzeby ruszać tej wartości. Gdy system ma bardzo mało RAM (1–2 GB) i pod obciążeniem reaguje „szarpnięciami”, czasem pomaga lekkie podniesienie (rozsądnie, np. o 20–30%).

vm.lowmem_reserve_ratio kontroluje, ile pamięci w niższych strefach ma być „zarezerwowane” dla nich samych. Zmiany mają sens głównie na serwerach z dużą ilością RAM i nietypowym obciążeniem, zwykle zostawia się domyślne wartości.

vm.dirty_ratio i vm.dirty_background_ratio – zapis na dysk pod kontrolą

Te parametry nie są bezpośrednio związane ze swapem, ale wpływają na subiektywne „mulenie”, bo sterują opóźnionym zapisem stron na dysk.

• vm.dirty_background_ratio – procent RAM, przy którym kernel zaczyna asynchronicznie spisywać brudne strony,
• vm.dirty_ratio – procent RAM, przy którym proces zapisujący dane może zostać przyblokowany do czasu spisania części buforów.

Podgląd:

sysctl vm.dirty_ratio vm.dirty_background_ratio

Na desktopach z HDD lekkie obniżenie (np. dirty_background_ratio=5, dirty_ratio=15) może zmniejszyć „szpilki” I/O, ale zbyt niskie wartości powodują częstsze zrzuty na dysk.

Planowanie rozmiaru swap i zram – bez magicznych formuł

Swap a RAM: praktyczne zakresy zamiast tabelek

Zamiast trzymać się sztywnych proporcji typu „2× RAM”, lepiej patrzeć na konkretne scenariusze.

• 2–4 GB RAM – swap 2–4 GB, zram 1–2 GB,
• 8–16 GB RAM – swap 2–4 GB, zram 2–4 GB,
• 32+ GB RAM – swap 2–8 GB (często tylko awaryjny), zram opcjonalnie lub mały (1–2 GB).

Jeśli system regularnie „dobija” do swapu, a zram jest pełny, lepszą odpowiedzią zwykle jest dołożenie RAM albo ograniczenie ciężkich usług, a nie dokładanie kolejnych gigabajtów swapu.

Hibernacja a rozmiar swapu

Dla suspend-to-disk swap musi zmieścić obraz pamięci plus narzut. Przy 8 GB RAM teoretycznie wystarczy swap ~8 GB, ale praktycznie przydaje się trochę zapasu.

Prosty schemat dla laptopów z hibernacją:

• RAM ≤ 8 GB – swap ≈ RAM lub RAM + 1–2 GB,
• RAM 16 GB – swap 16–20 GB (jeśli hibernacja jest faktycznie używana),
• RAM 32+ GB – często wygodniej zrezygnować z hibernacji niż robić bardzo duży swap.

Jeśli hibernacja nie jest używana, swap może być dużo mniejszy.

Ile zramu ma sens

Typowa praktyka na desktopach i małych serwerach to 25–100% RAM jako zram, ale górny koniec ma sens tylko przy agresywnej kompresji i słabym dysku.

• Desktop 8–16 GB RAM, SSD – zram 2–4 GB (ok. 25%),
• Stary laptop 4 GB RAM, HDD – zram 2–4 GB (50–100%),
• VPS 2 GB RAM – zram 1–2 GB + mały swap na dysku (1–2 GB).

Jeśli CPU jest stale wysoko obciążony, a swap prawie nie jest używany, zram można spokojnie zmniejszyć.

Priorytety: najpierw zram, potem dysk

Dla responsywności lepiej, żeby kernel najpierw korzystał ze swapu na zram, a dopiero potem z wolnego swapu na dysku. Ustawia się to priorytetem przy swapon.

Przykładowo:

• zram: pri=100,
• swap na SSD/HDD: pri=10 lub mniej.

Praktyka – konfiguracja klasycznego swapu (partycja, plik, priorytety)

Sprawdzanie istniejącego swapu

Na początek warto sprawdzić, co już jest włączone:

swapon --show
free -h

Jeśli lista jest pusta, system działa bez swapu lub korzysta tylko zram (jeśli został skonfigurowany osobno).

Tworzenie pliku swap o określonym rozmiarze

Przykład tworzenia 4 GB pliku swap na systemie plików /:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Stały wpis w /etc/fstab:

/swapfile none swap sw 0 0

Jeśli fallocate nie działa poprawnie (na niektórych FS), można użyć dd:

sudo dd if=/dev/zero of=/swapfile bs=1M count=4096
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Zmiana rozmiaru pliku swap

Zwiększenie lub zmniejszenie swapfile jest proste: trzeba go wyłączyć, usunąć i stworzyć na nowo.

sudo swapoff /swapfile
sudo rm /swapfile
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Po zmianie rozmiaru wpis w /etc/fstab zwykle pozostaje ten sam.

Konfiguracja partycji swap

Jeśli istnieje partycja przeznaczona na swap, można ją włączyć tak:

sudo mkswap /dev/sdX2
sudo swapon /dev/sdX2

Stały wpis w /etc/fstab lepiej robić po UUID, aby nie polegać na nazwach typu /dev/sda2:

blkid /dev/sdX2

UUID=xxxx-xxxx-xxxx-xxxx none swap sw 0 0

Priorytety wielu obszarów swap

Gdy jest zram i swap na dysku, kontrola priorytetów decyduje, z czego kernel korzysta w pierwszej kolejności.

Przykładowe wpisy w /etc/fstab:

/swapfile  none  swap  sw,pri=10   0 0
/dev/zram0 none  swap  sw,pri=100  0 0

Aktywne priorytety można sprawdzić:

swapon --show

Wyłączanie swapu „na żywo” i na stałe

Czasami trzeba tymczasowo wyłączyć swap, np. do testów:

sudo swapoff -a

Na stałe można usunąć wpisy z /etc/fstab albo dodać im opcję noauto. Warto jednak zostawić chociaż niewielki swap, chyba że maszyna ma bardzo dużo RAM i specyficzny profil obciążenia.

Praktyka – konfiguracja zram z użyciem narzędzi systemowych

Zram na dystrybucjach z gotowymi skryptami

Wiele dystrybucji ma już przygotowane mechanizmy:

• Debian/Ubuntu: pakiet zram-tools,
• Fedora: zram-generator,
• Arch: systemd z zram-generator lub skrypty AUR.

Konfiguracja zram na Debian/Ubuntu z użyciem zram-tools

Instalacja pakietu:

sudo apt install zram-tools

Domyślna konfiguracja jest zwykle w /etc/default/zramswap. Przykład prostego pliku:

ALGO=lz4
PERCENT=50
PRIORITY=100

Restart usługi, aby zastosować zmiany:

sudo systemctl restart zramswap.service

Sprawdzenie statusu:

swapon --show
cat /proc/swaps

Konfiguracja zram na systemd z użyciem zram-generator

Na systemach z zram-generator tworzy się plik konfiguracyjny, np. /etc/systemd/zram-generator.conf:

[zram0]
zram-size = ram / 2
compression-algorithm = lz4
swap-priority = 100

Następnie:

sudo systemctl daemon-reload
sudo systemctl start /dev/zram0

Na niektórych systemach usługa nazywa się systemd-zram-setup@zram0.service, warto sprawdzić systemctl list-units | grep zram.

Ręczne tworzenie zram bez dodatkowych narzędzi

Na minimalnych systemach można zram skonfigurować bezpośrednio.

sudo modprobe zram
echo lz4 | sudo tee /sys/block/zram0/comp_algorithm
echo $(( 1024 * 1024 * 1024 )) | sudo tee /sys/block/zram0/disksize  # 1G
sudo mkswap /dev/zram0
sudo swapon --priority 100 /dev/zram0

Aby działało po restarcie, można dodać prosty skrypt w /etc/systemd/system/zram.service albo użyć /etc/rc.local (jeśli jest obsługiwany).

Wybór algorytmu kompresji

Lista obsługiwanych algorytmów:

cat /sys/block/zram0/comp_algorithm

Ogólna praktyka:

• lz4 – bardzo szybki, mniejszy stopień kompresji, dobry domyślny wybór,
• zstd – większa kompresja, ale cięższa dla CPU, sensowny na mocniejszych maszynach,
• lzo – starszy, często dostępny, kompromis między szybkością a kompresją.

Na słabszych laptopach i VM lepiej zaczynać od lz4 i dopiero przy realnej potrzebie przestrzeni testować inne algorytmy.

Testowanie i monitorowanie pod obciążeniem – jak sprawdzić, czy system nie muli

Podstawowe narzędzia: free, vmstat, top/htop

Do szybkiego podglądu użycia pamięci i swapu wystarczą proste polecenia:

Obserwowanie zachowania pamięci w czasie

Sam odczyt free -h raz na jakiś czas niewiele mówi. Trzeba zobaczyć, jak system reaguje w dynamice.

watch -n 1 free -h

Przy lekkim obciążeniu zużycie swapu powinno rosnąć wolno, bez gwałtownych skoków. Nagłe dobicie swapu i szybki wzrost used + wysokie I/O to sygnał, że coś jest nie tak (za mało RAM, zbyt agresywny swappiness, brak zramu).

vmstat: szybki pogląd na I/O i „dławienie” pamięci

vmstat pokazuje, czy kernel ciągle coś wyrzuca do swapu:

vmstat 1

Istotne kolumny:

• si (swap in) – ilość danych ściąganych ze swapu (KB/s),
• so (swap out) – ilość danych zapisywanych do swapu (KB/s),
• wa (iowait) – procent czasu CPU czekającego na I/O,
• r – liczba procesów gotowych do działania (kolejka).

Jeśli pod obciążeniem so utrzymuje się wysoko przez dłuższy czas, a wa jest bliskie lub powyżej 20–30%, system realnie mieli na dysku. Wtedy trzeba zmienić parametry VM albo zmniejszyć ilość aktywnych usług.

top/htop: kto zjada pamięć

top i htop pozwalają szybko znaleźć procesy, które zaczynają „puchnąć”.

htop

W htop przydatne są kolumny:

• RES – rzeczywiście zajęta pamięć fizyczna,
• SHR – część współdzielona,
• VIRT – cała przestrzeń adresowa (mniej istotne przy diagnozie „mulenia”).

Jeżeli jeden proces rośnie niekontrolowanie, trzeba go ujarzmić (limit w systemd, ulimit, inna konfiguracja), zamiast próbować „ratować się” kolejnymi gigabajtami swapu.

iostat i atop: kiedy dysk jest wąskim gardłem

Jeżeli swap jest na wolnym HDD, to często właśnie on jest problemem, a nie sama ilość pamięci.

sudo apt install sysstat  # Debian/Ubuntu
iostat -xm 1

Najważniejsze pola:

• r/s, w/s – liczba operacji odczytu/zapisu na sekundę,
• await – średni czas obsługi operacji (ms),
• %util – procent czasu, gdy urządzenie jest zajęte.

Jeśli %util jest prawie stale przy 100%, a system mocno zwalnia przy intensywnym użyciu swapu, dobrze jest zwiększyć udział zramu albo przenieść swap na szybszy dysk.

Symulowanie niedoboru pamięci

Najprostszym testem jest uruchomienie czegoś, co dużo alokuje, np. kilku ciężkich przeglądarek, maszyn wirtualnych albo kontenerów. Można też użyć narzędzi testowych.

Przykład prostej aplikacji obciążającej pamięć:

stress-ng --vm 2 --vm-bytes 70% --vm-method all --verify -t 5m

W czasie takiego testu warto obserwować vmstat, htop i iostat. System pod obciążeniem może działać wolniej, ale nie powinien wchodzić w stan „czekam 30 sekund na reakcję myszy”. Jeśli tak się dzieje, konfiguracja swap/zram wymaga korekty.

Prosty scenariusz testowy dla desktopa

Na zwykłym desktopie można sprawdzić praktyczne działanie konfiguracji, wykonując kilka równoległych zadań:

1. Uruchomić kilka zakładek z ciężkimi stronami (np. aplikacje webowe).
2. W tle odpalić kompilację większego projektu lub archiwizację:

   tar -czf archiwum.tar.gz katalog/
   

3. Włączyć vmstat 1 i iostat -xm 1.

Jeśli mysz i przełączanie okien działają płynnie, a si/so tylko czasem „pikają”, konfiguracja jest zwykle wystarczająca. Jeśli zaczyna się ciągłe so + wysokie wa, trzeba ograniczyć swappiness, zwiększyć zram lub zmniejszyć obciążenie.

Diagnoza: zbyt mały czy zbyt duży swap?

Objawy zbyt małego swapu/zramu:

• częste zabijanie procesów przez OOM-killera,
• nagłe zamknięcia przeglądarki, edytora czy serwera aplikacji bez innego powodu,
• logi z komunikatami Out of memory w dmesg lub /var/log.

Objawy zbyt dużego lub zbyt agresywnie używanego swapu:

• ciągłe „mielenie” dysku mimo wolnej pamięci cache,
• duże opóźnienia przy przełączaniu się na dawno nieużywane okno/aplikację,
• wysokie si/so bez faktycznego niedoboru RAM.

W pierwszym przypadku rozsądniej jest dodać RAM albo ograniczyć procesy. W drugim – skorygować vm.swappiness, zwiększyć zram lub zmienić profil usług.

Obserwacja cache i page cache

Przy pracy serwera plików, baz danych czy kontenerów ważne jest, ile miejsca zostaje na cache.

grep -E 'Cached|Buffers' /proc/meminfo

Jeżeli Cached spada prawie do zera, a swap rośnie, kernel zostało wypchnięty do rogu: musi utrzymywać procesy i nie ma już miejsca na sensowny cache. W takim profilu lepiej nie ograniczać za mocno cache (vm.vfs_cache_pressure w rozsądnych granicach) i zapewnić odpowiednio dużo RAM.

Monitoring długoterminowy

Na serwerach i maszynach roboczych sens ma obserwacja użycia pamięci w dłuższym okresie. Uproszczone podejście to zbieranie prostych statystyk co kilka minut.

* * * * * root free -m >> /var/log/free.log

Taki plik po kilku dniach jasno pokaże, czy swap jest używany sporadycznie, czy stopniowo się zapełnia i nigdy nie wraca do niższego poziomu. W tym drugim przypadku konfiguracja jest na krawędzi i któryś „pik” obciążenia może wywołać OOM lub ostre mulenie.

Typowe błędy i pułapki przy ustawianiu swapu i zram

Całkowite wyłączanie swapu „bo mam dużo RAM”

Brak swapu bywa kuszący: „nic nie będzie mi swapować i system będzie szybki”. W praktyce kernel traci bufor bezpieczeństwa.

Bez swapu każde większe chwilowe obciążenie pamięci kończy się szybciej działaniem OOM-killera. Zamiast tego lepiej zostawić choćby mały swap (np. 1–2 GB) lub zram, tak żeby jądro miało gdzie odłożyć najmniej istotne strony.

Zbyt agresywny swappiness przy wolnym dysku

Ustawienie vm.swappiness=100 na laptopie z HDD to prosty sposób na wywołanie „mielenia” przy byle obciążeniu. Kernel będzie zbyt chętnie wyrzucał strony do swapu.

Na wolnych dyskach bez zramu lepiej trzymać się niskich wartości (10–20) i przetestować zachowanie. Gdy do gry wchodzi zram z wysokim priorytetem, można pozwolić sobie na większe swappiness, bo większość operacji trafia do pamięci kompresowanej, a nie na talerz.

Ogromny zram na słabym CPU

Zwiększanie zramu „na oko” do wielkości zbliżonej do RAM i włączenie ciężkiej kompresji na słabym CPU kończy się tym, że procesor zamiast obrabiać właściwą pracę, spędza czas na kompresji i dekompresji.

Na starszych laptopach i małych VPS rozsądniej jest ustawić PERCENT w okolicach 25–50% RAM i używać lz4. Jeśli mimo to CPU dobija do 100% przy intensywnym użyciu zramu, trzeba zejść z rozmiaru albo ograniczyć liczbę równoległych zadań.

Swap na tym samym HDD co system i baza danych

Łączenie swapu, systemu i intensywnej bazy danych na jednym talerzowym HDD powoduje ciągłe skakanie głowicy. Każde „dociśnięcie” bazy jeszcze bardziej spowalnia system.

Jeśli już trzeba korzystać z HDD i swapu, najlepiej rozdzielić talerze (osobny dysk pod swap) albo przenieść swap na szybsze medium (SSD, NVMe), pozostawiając HDD na dane „bulk”. W wielu domowych konfiguracjach skuteczniejsze jest jednak zwiększenie zramu i minimalny swap na HDD tylko jako awaryjny.

Brak priorytetów swapu przy mieszanym zram + dysk

Domyślne priorytety swapu nie zawsze pasują do założonej strategii. Zdarza się, że kernel częściej używa swapu na dysku niż zramu, bo oba obszary mają ten sam priorytet lub częściej aktywowany jest ten na dysku.

Priorytety trzeba ustawić świadomie:

/dev/zram0 none swap sw,pri=100 0 0
/swapfile  none swap sw,pri=10  0 0

Po zmianie dobrze jest sprawdzić swapon --show, czy priorytety faktycznie wyglądają tak, jak oczekiwano.

Niedopasowanie konfiguracji cache do profilu obciążenia

Przy klasycznych serwerach plików lub aplikacji bazodanowych zbyt wysokie vm.vfs_cache_pressure sprawia, że jądro zbyt chętnie czyści cache VFS, a i tak trzyma sporo rzadko używanych stron procesów w RAM.

Delikatne obniżenie, np. do 50–70, często daje lepszy kompromis: więcej cache katalogów i inode, mniej niepotrzebnie utrzymywanych stron procesów, które mogą spokojnie trafić do zramu. Z kolei zbyt niskie wartości mogą utrzymywać nadmierny cache kosztem „żywych” procesów, więc każdą zmianę trzeba sprawdzić pod typowym obciążeniem.

Liczenie na swap zamiast planowania zasobów

Swap, także zram, nie zastąpi RAM-u. Gdy regularne, typowe obciążenie stale „dobija” do limitu pamięci, system będzie cierpiał niezależnie od ustawień, tylko na różne sposoby.

Jeżeli statystyki z kilku tygodni pokazują, że w godzinach szczytu prawie cały RAM jest zajęty, swap powoli się zapełnia i nigdy nie wraca do niskiego poziomu, to znak, że pora zwiększyć pamięć fizyczną albo zmienić profil uruchomionych usług. Swap ma łagodzić szczyty, a nie być stałym „dodatkowym RAM-em”.

Najczęściej zadawane pytania (FAQ)

Czy w Linuxie lepiej mieć swap czy go całkiem wyłączyć?

W większości przypadków lepiej mieć choćby mały swap niż nie mieć go wcale. Swap działa jako bufor bezpieczeństwa przy chwilowych skokach zużycia pamięci i może uratować system przed natychmiastowym zadziałaniem OOM-killera.

Całkowity brak swapu ma sens głównie na maszynach z dużą ilością RAM i przewidywalnym obciążeniem. Na desktopach i laptopach (zwłaszcza z przeglądarkami, IDE, Electronem) brak swapu często kończy się nagłym ubijaniem procesów i utratą danych zamiast krótkiego spowolnienia.

Ile swapu ustawić przy 4 GB / 8 GB / 16 GB RAM?

Dla typowego desktopa sensowny punkt wyjścia to:

• 4 GB RAM: 2–4 GB swap (plus zram, jeśli dostępny),
• 8 GB RAM: 2–4 GB swap,
• 16 GB RAM: 2–4 GB swap, chyba że używasz ciężkich zadań (VM, kompilacje) – wtedy 4–8 GB.

To nie są twarde reguły, tylko praktyczne wartości startowe. Swap ma być buforem na piki, a nie „drugim RAM‑em”. Jeśli system regularnie zjada większość swapu, problemem jest za mały RAM albo zbyt ciężkie obciążenie.

Co to jest vm.swappiness i jaką wartość ustawić, żeby system nie mulił?

vm.swappiness określa, jak chętnie kernel wypycha pamięć procesów do swapu w porównaniu z trzymaniem cache w RAM. Wyższa wartość oznacza wcześniejsze i częstsze używanie swapu, niższa – trzymanie jak najwięcej w RAM.

Na desktopie zwykle dobrze sprawdza się zakres 20–40. Przykład: sudo sysctl -w vm.swappiness=30. Na serwerach bazodanowych albo maszynach, gdzie swap ma być tylko ostatecznością, można zejść niżej, np. 5–10.

Jak sprawdzić, czy system muli przez swap, a nie przez coś innego?

Podstawowe narzędzia to free -h, top/htop i vmstat 1. Jeśli w free -h wartość available jest bardzo niska, a jednocześnie rośnie użycie swapu, to system faktycznie ratuje się dyskiem.

W top lub htop zwróć uwagę na wysoki wa (iowait) i ciągłe operacje I/O, a w dmesg na wpisy o OOM-killerze. Charakterystyczny objaw thrashingu to: dioda dysku świeci praktycznie ciągle, interfejs graficzny prawie nie reaguje, a CPU nie jest w 100% zajęte obliczeniami.

Czym różni się zram od zwykłego swapu na dysku?

Zram tworzy w RAM kompresowane urządzenie blokowe, które kernel traktuje jak bardzo szybki, „pseudodyskowy” swap. Dane są kompresowane i dekompresowane w locie, dzięki czemu na tej samej ilości RAM można zmieścić więcej rzadko używanych stron pamięci.

W praktyce zram zmniejsza liczbę zapisów na prawdziwy dysk i poprawia responsywność pod obciążeniem, bo dostęp do niego jest znacznie szybszy niż do HDD czy nawet SSD. Dobrze sprawdza się na starszych laptopach z małą ilością RAM oraz wszędzie tam, gdzie dysk jest wolny lub ograniczany przez dostawcę VPS.

Czy przy zram nadal potrzebuję klasycznego swapu na dysku?

W typowej konfiguracji zram nie zastępuje całkowicie swapu na dysku, tylko go uzupełnia. Zram przejmuje na siebie „pierwszą linię” swapowania, a mały swap na dysku pozostaje jako dodatkowy bufor na skrajne sytuacje.

Wyjątkiem mogą być bardzo ograniczone maszyny (np. mały VPS), gdzie polityka I/O dostawcy jest ostra i swap na dysku tylko szkodzi. Wtedy czasem stosuje się wyłącznie zram, godząc się na to, że przy naprawdę dużym piku pamięci szybciej zadziała OOM-killer.

Jak rozpoznać, że powinienem dołożyć zram albo zmniejszyć swappiness?

Jeśli przy intensywnym obciążeniu:

• często widzisz długie przycinki interfejsu,
• dioda dysku świeci praktycznie nonstop,
• free -h pokazuje spory użyty swap mimo wciąż rozsądnego available,

to kernel zbyt chętnie korzysta ze swapu na dysku.

W takiej sytuacji zwykle pomaga obniżenie vm.swappiness oraz dodanie zramu (1–2× RAM w zależności od kompresji i obciążenia). Jeśli po tych zmianach system pod obciążeniem reaguje płynniej, a użycie swapu na dysku spada, konfiguracja idzie w dobrą stronę.

Co warto zapamiętać

• Responsywność pod obciążeniem zależy głównie od zarządzania pamięcią przez kernel: od tego, kiedy zaczyna się swapowanie i jak agresywnie system próbuje zwalniać RAM.
• Wysokie „used” w free -h nie oznacza problemu – kluczowa jest kolumna „available”, która pokazuje realną ilość pamięci możliwej do użycia bez intensywnego swapu.
• Brak swapu nie przyspiesza systemu – sprawia jedynie, że przy braku RAM szybciej włącza się OOM-killer i procesy są zabijane zamiast zostać tymczasowo przeniesione do przestrzeni wymiany.
• Zbyt duży swap na wolnym dysku prowadzi do „mielenia” i zamrażania pulpitu; lepszy jest niewielki, przemyślany bufor niż ogromny swap udający dodatkowy RAM.
• Typowe symptomy złej konfiguracji pamięci to przycinanie interfejsu, długie „zawieszki” przy dużym I/O, wysokie iowait oraz komunikaty OOM w dmesg.
• Na współczesnych desktopach i serwerach najpraktyczniejszy jest plik swap, bo łatwo go powiększyć lub zmniejszyć bez przebudowy partycji.
• Optymalne ustawienia zwykle łączą: niewielki swap na dysku, zram jako szybki, kompresowany pseudo-swap w RAM oraz rozsądny vm.swappiness, żeby kernel nie czekał do twardego OOM.

Opracowano na podstawie

• Linux Kernel Documentation: Admin Guide – Swap Management. The Linux Kernel Project – Oficjalny opis mechanizmów swapu, swappiness i decyzji o stronicowaniu
• Linux Kernel Documentation: Admin Guide – Memory Management. The Linux Kernel Project – Zarządzanie RAM, page cache, OOM-killer, polityki odzyskiwania pamięci
• Understanding the Linux Virtual Memory Manager. Prentice Hall (2004) – Szczegółowy opis VM w Linuksie: strony, cache, swap, OOM
• Linux Performance Tuning Guidelines. Red Hat – Praktyczne zalecenia dot. vm.swappiness, swapu i responsywności systemu