Najczęstsze błędy w konfiguracji swap i jak je naprawić

Serwer po nocnym deployu niby działa, ale każde logowanie przez SSH trwa wieczność, aplikacja odpowiada z opóźnieniem, a free -h pokazuje zajęty swap. Na desktopie scenariusz wygląda podobnie: kilkadziesiąt kart w przeglądarce, komunikator, IDE i nagle system zaczyna „mielić” tak, jakby obraził się na użytkownika. W takich sytuacjach łatwo uznać, że winny jest sam swap. Problem w tym, że użycie swapu nie zawsze oznacza złą konfigurację swapu, a nie każdy tuning pamięci rozwiązuje prawdziwą przyczynę spowolnień.

Swap ma prostą rolę: daje systemowi bufor bezpieczeństwa pod presją pamięci i pomaga utrzymać stabilność. Nie jest magicznym „dodatkowym RAM-em”, który można bezkarnie traktować jak pełnoprawną pamięć operacyjną. Jeśli konfiguracja swap jest nietrafiona, system może reagować zbyt gwałtownie albo przeciwnie — bardzo długo konać pod obciążeniem, zanim ktoś zorientuje się, że problem jest dużo głębszy.

Najczęstsze pytania, które pojawiają się przy diagnozie swapu: czy brak swapu szkodzi, jak rozpoznać zbyt mały lub zbyt duży swap, kiedy zmiana swappiness ma sens, co wybrać: swap file czy partycję, jak podejść do SSD, VPS-ów i maszyn wirtualnych, oraz kiedy tuning swapu jest tylko plastrem na wyciek pamięci albo chroniczny niedobór RAM.

Frazy pomocnicze: konfiguracja swap Linux, swappiness, swap file czy partycja, thrashing pamięci, brak swapu, zbyt mały swap, VPS pamięć RAM, swap na SSD, OOM killer, monitoring pamięci, hibernacja Linux, optymalizacja serwera

Gdy system zaczyna „mielić”, czyli co najpierw sprawdzić zanim ruszysz swap

Szybka diagnoza: problem swapu czy objaw czegoś innego

Najbardziej mylący moment to ten, w którym widać zajęty swap i odruchowo pojawia się pomysł: „trzeba zmienić konfigurację”. Tymczasem sam fakt, że część pamięci została przeniesiona do swapu, nie jest jeszcze błędem. System może całkiem rozsądnie przenosić rzadko używane strony pamięci, żeby zostawić więcej miejsca na aktywne procesy i cache dyskowy.

Znacznie ważniejsze od samej liczby w kolumnie Swap used jest to, czy system aktywnie i intensywnie swapuje, czy tylko kiedyś coś odłożył i spokojnie z tym żyje. Jeśli swap został użyty rano, a od tego czasu nie ma dużych operacji si/so w vmstat, system może działać normalnie. Jeśli jednak przy każdym skoku obciążenia pojawiają się opóźnienia, rośnie I/O, a interfejs lub usługi zaczynają odpowiadać z wyraźnym lagiem, wtedy problemem bywa nie sam swap, lecz thrashing pamięci.

Thrashing to sytuacja, w której system zbyt dużo czasu poświęca na przerzucanie stron pamięci między RAM a swapem, zamiast wykonywać realną pracę. W praktyce objawia się to tym, że CPU nie musi być dobite do 100%, a mimo to wszystko reaguje ospale. To trochę jak bieganie z dokumentami między piętrami zamiast usiąść i je przeczytać.

Co sprawdzić przed zmianą konfiguracji

Zanim zmienisz rozmiar swapu, parametr swappiness albo typ przestrzeni wymiany, zbierz kilka prostych obserwacji. Bez tego tuning będzie zgadywaniem, a zgadywanie przy pamięci zwykle kończy się elegancko tylko w notatkach, nie na produkcji.

• Użycie RAM – ile pamięci jest rzeczywiście zajęte przez procesy, a ile stanowi cache i bufory.
• Tempo swap in/swap out – pojedyncze użycie swapu to nie to samo co ciągła aktywność.
• Load average i opóźnienia I/O – wysoki load przy aktywnym dysku może wskazywać bardziej na problem z pamięcią i storage niż z CPU.
• OOM killer i logi – wpisy w dmesg, journalctl lub logach kernela pokazują, czy system ubijał procesy z powodu braku pamięci.
• Zachowanie konkretnych procesów – czy jeden proces stale rośnie, czy pamięć skacze chwilowo przy określonych zadaniach.

Do szybkiej analizy zwykle wystarczają: free, vmstat, top lub htop, iostat, sar, a przy dokładniejszym sprawdzeniu także /proc/meminfo i logi kernela. Nie trzeba od razu pisać własnego eksportera, chociaż wiadomo: czasem kusi.

To nie jest problem swapu, jeśli objawy wskazują gdzie indziej

Bywają sytuacje, w których swap dostaje niesłusznie po głowie. Jeśli CPU stale pracuje na granicy możliwości, a pamięć wygląda stabilnie, przyczyna leży raczej w obliczeniach, zbyt wielu wątkach albo nieefektywnym kodzie. Podobnie, jeśli storage jest przeciążone niezależnie od użycia RAM, tuning swapu nie naprawi wolnego backendu dyskowego.

Jeszcze częstszy przypadek to wyciek pamięci. Proces zjada coraz więcej RAM, po restarcie chwilowo jest dobrze, po czym sytuacja wraca. Zwiększenie swapu może tu tylko odsunąć moment awarii albo uczynić objawy mniej czytelnymi. W maszynach wirtualnych trzeba dodatkowo brać pod uwagę hosta: jeśli host jest przealokowany i sam wpada w presję pamięci, zmiany wewnątrz gościa nie zawsze przyniosą oczekiwany efekt.

Błąd 1 i 2: brak swapu albo swap zbyt mały

Dlaczego brak swapu bywa ryzykowny, ale nie zawsze

Całkowity brak swapu jest czasem prezentowany jako rozwiązanie „wydajnościowe”, zwłaszcza na serwerach z szybkim storage i rozsądną ilością RAM. W części środowisk to może działać poprawnie, ale tylko wtedy, gdy obciążenie jest przewidywalne, pamięci jest dużo w stosunku do potrzeb, a zespół akceptuje twardą politykę bez marginesu bezpieczeństwa.

Problem zaczyna się wtedy, gdy system doświadcza krótkich, ale realnych pików użycia pamięci. Klasyczne przykłady to: mały VPS, jednoczesny deploy i backup, kompilacja większego projektu, aktualizacja pakietów, kilka cięższych zadań cron lub po prostu desktop z przeglądarką, IDE i komunikatorami. Bez swapu nawet chwilowy wzrost zapotrzebowania może uruchomić OOM killera i zakończyć się ubijaniem procesów.

Skutek jest zwykle gwałtowny. System nie ma gdzie odłożyć mniej aktywnych stron pamięci, więc nie amortyzuje skoku obciążenia. Tam, gdzie umiarkowany swap dałby kilka dodatkowych minut stabilności albo pozwolił dokończyć zadanie, brak swapu kończy się brutalnym „stop”. Na VPS-ach i hostach z nierównym profilem zużycia RAM to częsty błąd konfiguracyjny.

Lepsze rozwiązanie to zwykle niewielki, ale realny swap, traktowany jako amortyzator, nie jako podstawowy zasób pamięci. Nie chodzi o to, by system stale na nim pracował, lecz by miał bezpiecznik w sytuacjach granicznych. Wyjątek od tej reguły ma sens w dobrze kontrolowanych środowiskach: serwerach z dużym zapasem RAM, prostym profilem aplikacji i świadomie ustawioną polityką bez swapu.

Objawy, skutek i lepsze rozwiązanie przy braku swapu

Objawy: nagłe OOM killery, zrywanie usług przy krótkich pikach pamięci, ubite procesy podczas aktualizacji, kompilacji lub równoległych zadań. Na desktopie — zamrażanie aplikacji albo brutalne zamknięcia, gdy otwartych jest zbyt wiele procesów potomnych przeglądarki.

Skutek: system działa szybko aż do momentu, w którym nagle przestaje działać stabilnie. To zdradliwy scenariusz, bo przez większość czasu wszystko wygląda dobrze, a awaria pojawia się tylko pod konkretną kombinacją obciążeń.

Lepsze rozwiązanie: dodać swap w rozmiarze dopasowanym do scenariusza. Dla małego VPS-a może to być bufor na sporadyczne skoki. Dla stacji roboczej — zabezpieczenie przy kompilacji i dużej liczbie aplikacji. Dla serwera aplikacyjnego — margines bezpieczeństwa, jeśli pamięć nie jest stale „na styk”.

Zbyt mały swap i złudne poczucie bezpieczeństwa

Drugi częsty błąd to konfiguracja, w której swap formalnie istnieje, ale jest tak mały, że kończy się dokładnie wtedy, gdy zaczyna być potrzebny. To typowe po bezrefleksyjnym użyciu starej regułki albo po pozostawieniu domyślnej wartości z obrazu systemu, bez związku z realnym obciążeniem.

Taki swap daje administratorowi i użytkownikowi złudne poczucie bezpieczeństwa. W teorii system ma przestrzeń wymiany, w praktyce nie ma wystarczającego bufora na skoki pamięci. Objawy są dość charakterystyczne: krótkie piki kończą się OOM mimo obecnego swapu, usługi restartują się przy niekorzystnej zbieżności zadań, a analiza po fakcie pokazuje, że swap został wyczerpany niemal natychmiast.

Najgorsze jest to, że taki błąd długo pozostaje niewidoczny. Przez większość dnia wszystko działa poprawnie, ale np. przy jednoczesnym deployu, backupie i większym ruchu aplikacja zaczyna się sypać. Właśnie w takich scenariuszach mały swap bardziej przeszkadza, niż pomaga, bo stwarza pozór zabezpieczenia.

Jak dobrać rozmiar swapu bez sztywnych regułek

Nie ma jednej uniwersalnej liczby dla wszystkich środowisk. Rozmiar swapu dobiera się do tego, po co ma istnieć. Jeśli ma jedynie stabilizować krótkie skoki pamięci, nie musi być ogromny. Jeśli system ma obsługiwać hibernację, wymagania rosną. Jeśli serwer działa z przewidywalnym limitem pamięci i mocno krytycznym SLA, nadmiar swapu może bardziej wydłużyć degradację niż pomóc.

Praktyczne kryteria wyglądają zwykle tak:

• Mały VPS z okazjonalnymi pikami RAM – swap powinien dać margines na krótkie skoki, ale nie zastępować pamięci na stałe.
• Stacja robocza z kompilacją, kontenerami i przeglądarką – przydaje się większy bufor, bo obciążenie bywa nierówne.
• Desktop z hibernacją – potrzeby swapu są determinowane nie tylko wydajnością, ale też funkcją usypiania stanu pamięci.
• Serwer bazodanowy o przewidywalnym limicie – zwykle lepiej unikać polegania na swapie jako miejscu pracy, a bardziej myśleć o ochronie przed anomaliami.

Jeśli system przez większość czasu działa dobrze, ale sporadycznie wysypuje się przy chwilowych skokach pamięci, zwiększenie swapu bywa sensowną korektą. Jeśli jednak swap stale się zapełnia i wraca problem responsywności, przyczyna leży głębiej niż sam rozmiar przestrzeni wymiany.

Błąd 3 i 4: za duży swap oraz traktowanie go jak protezy braku RAM

Kiedy duży swap maskuje prawdziwy problem

Duży swap potrafi uratować system przed natychmiastowym OOM, ale równie dobrze może zamienić szybką i czytelną awarię w długą, bolesną degradację wydajności. To szczególnie niebezpieczne wtedy, gdy ktoś traktuje swap jak tani substytut pamięci RAM, licząc, że „system sobie poradzi”. Technicznie poradzi sobie o tyle, o ile będzie w stanie nadal oddychać, ale często bardzo ciężko.

Objawy są charakterystyczne: maszyna nie pada od razu, usługi niby żyją, ale reakcje są coraz wolniejsze, opóźnienia rosną, a użytkownicy mają wrażenie, że wszystko działa „strasznie wolno”. Na wolniejszym HDD albo przeciążonym współdzielonym storage to bywa wręcz podręcznikowy przykład wydłużonej agonii systemu.

Skutek źle dobranego, zbyt dużego swapu jest więc podwójny. Po pierwsze, administrator może dłużej nie zauważyć, że system chronicznie cierpi na niedobór RAM. Po drugie, sam serwer lub desktop pracuje w stanie, który z punktu widzenia użytkownika bywa gorszy niż kontrolowana awaria i szybka diagnoza.

Lepsze rozwiązanie zaczyna się od prostego pytania: czy swap ma amortyzować krótkie skoki, czy ukrywa stały brak pamięci? Jeśli to pierwsze, większy swap ma sens. Jeśli to drugie, trzeba wrócić do architektury aplikacji, limitów pamięci, liczby workerów, ustawień bazy, cache albo po prostu zwiększenia RAM.

W praktyce dobrze działa prosta zasada: jeśli po zwiększeniu swapu system tylko dłużej cierpi, zamiast wrócić do stabilnej pracy, to problemem nie jest swap, tylko zbyt mało RAM albo zbyt agresywna konfiguracja usług. Klasyczny przypadek to host z za dużą liczbą workerów PHP, JVM ustawioną z przesadnym heapem albo baza danych, której cache zjada wszystko, co się da. Wtedy swap nie „naprawia” sytuacji — on ją rozciąga w czasie, czasem dość teatralnie.

Drugi sygnał ostrzegawczy to mylenie awaryjnego bufora z normalnym miejscem pracy. Jeśli serwer codziennie i regularnie wykonuje istotną część operacji przy dużym zużyciu swapu, to nie jest zdrowa równowaga, tylko trwała presja pamięci. Na desktopie objawia się to przycięciami po przełączeniu kart lub aplikacji. Na serwerze — skokami latency, długim odzyskiwaniem responsywności i obciążeniem storage, które nagle zaczyna być „bohaterem” problemu, choć nikt go o to nie prosił.

Rozsądniejsza ścieżka naprawy zależy od scenariusza. Gdy obciążenie jest chwilowe i rzadkie, swap może być większy, by dać systemowi oddech. Gdy presja pamięci jest stała, lepiej ciąć źródło problemu: ograniczyć liczbę procesów, ustawić sensowne limity dla kontenerów, poprawić rozmiar cache, rozdzielić role usług albo dołożyć RAM. Swap ma ratować przed skrajem, nie być planem podstawowym.

Błąd 5 i 6: zły typ swapu oraz zła lokalizacja nośnika

Partycja, plik czy zram — nie każdy typ swapu pasuje do każdego systemu

Błąd zaczyna się zwykle wtedy, gdy wybór typu swapu wynika z przyzwyczajenia, a nie z realnych potrzeb maszyny. Partycja swap bywa stabilna i przewidywalna, ale jest mniej elastyczna przy późniejszej zmianie rozmiaru. Plik swap łatwiej powiększyć lub zmniejszyć, co na VPS-ach i zwykłych instalacjach często okazuje się po prostu wygodniejsze. Z kolei zram działa inaczej: kompresuje dane w RAM i może poprawić zachowanie systemu przy krótkich skokach pamięci, ale nie zastępuje klasycznego swapu na dysku w każdym scenariuszu.

Typowy błąd to użycie jednego rozwiązania „bo tak się zawsze robiło”. Na lekkim laptopie z ograniczonym RAM zram potrafi dać bardzo sensowny efekt. Na serwerze, który potrzebuje realnego bufora poza pamięcią operacyjną, sam zram może nie wystarczyć. Z kolei sztywna partycja swap na środowisku, gdzie parametry często się zmieniają, utrudnia korekty i niepotrzebnie komplikuje administrację. Krótko mówiąc: wygoda, elastyczność i profil obciążenia mają tu większe znaczenie niż stary odruch.

Zła lokalizacja nośnika i skutki uboczne, które widać dopiero pod obciążeniem

Nawet poprawnie dobrany rozmiar i typ swapu nie pomogą wiele, jeśli przestrzeń wymiany trafi na słaby albo przeciążony nośnik. Swap na wolnym HDD, karcie SD, kiepskim pendrivie czy mocno obciążonym współdzielonym storage potrafi zamienić problem pamięci w problem całego systemu I/O. Objaw jest prosty: przy presji RAM wszystko zaczyna reagować z opóźnieniem, a czasem praktycznie staje, mimo że procesor wcale nie jest zajęty po sufit.

Na maszynach wirtualnych i tanich VPS-ach dochodzi jeszcze lokalny kontekst środowiska: storage bywa współdzielone, a jego wydajność nierówna zależnie od pory dnia i obciążenia sąsiadów. W takiej sytuacji swap może działać akceptowalnie przez tydzień, a potem nagle zacząć być wąskim gardłem. Jeśli system ma regularnie korzystać z przestrzeni wymiany, nośnik powinien być przewidywalny. Jeśli nie jest, lepiej traktować swap wyłącznie jako zabezpieczenie awaryjne i pilnować, by nie stawał się codziennym miejscem pracy.

Jak dobrać rozwiązanie do środowiska, zamiast kopiować cudzy schemat

Najpraktyczniejsze kryterium jest proste: czy potrzebujesz elastyczności, przewidywalności, czy ochrony przed krótkimi pikami. Od tego zależy, czy lepiej sprawdzi się plik swap, partycja, zram albo mieszanka tych opcji.

• Swap file zwykle wygrywa na VPS-ach, VM-kach i zwykłych serwerach Linuksa, gdzie liczy się szybka korekta rozmiaru bez grzebania w partycjach.
• Swap partition ma sens tam, gdzie układ dysku jest stały, środowisko jest przewidywalne, a prostota na poziomie bloku urządzenia jest ważniejsza niż wygoda zmian.
• zram pasuje do laptopów, desktopów i lżejszych maszyn z nierównym obciążeniem, gdzie kompresja w RAM potrafi ograniczyć przycięcia przy krótkich skokach pamięci.
• Połączenie zram + klasyczny swap bywa rozsądne na stacjach roboczych i niektórych hostach deweloperskich: najpierw kompresja, potem dopiero dysk.

Wyjątki oczywiście istnieją. Jeśli środowisko jest mocno ograniczone przez polityki platformy, system plików albo obraz maszyny, wybór może być zawężony. Nie ma w tym dramatu. Problem zaczyna się dopiero wtedy, gdy rozwiązanie zostało dobrane raz, dawno temu, a dziś nikt już nie pamięta dlaczego. Swap też nie lubi konfiguracji archeologicznej.

Błąd 7: nieprzemyślane ustawienie swappiness

Dlaczego kopiowanie jednej liczby bywa gorsze niż zostawienie domyślnej

vm.swappiness to jeden z tych parametrów, które bardzo kuszą prostą receptą: ustaw na 1, 10, 60 albo 100 i problem zniknie. Niestety tak to nie działa. Swappiness nie „naprawia” braku RAM; wpływa tylko na to, jak chętnie kernel będzie wypychał mniej aktywne strony pamięci do swapu.

Najczęstszy błąd to ślepe obniżenie swappiness do bardzo niskiej wartości, bo ktoś przeczytał, że „swap wtedy nie będzie używany”. Taki ruch czasem poprawia responsywność desktopu, ale w innym środowisku może sprawić, że system będzie zbyt długo trzymał wszystko w RAM i szybciej dojdzie do ostrych decyzji OOM. Z drugiej strony zbyt wysoka wartość potrafi powodować wcześniejsze i bardziej agresywne spychanie pamięci do swapu, co na wolniejszym storage daje efekt, którego nikomu nie życzymy.

Po czym poznać, że swappiness jest ustawione źle

Sam fakt użycia swapu nie jest jeszcze dowodem problemu. Sygnały ostrzegawcze pojawiają się wtedy, gdy zachowanie systemu nie pasuje do typu obciążenia:

• desktop zaczyna przycinać mimo wolnego RAM dostępnego „na papierze”,
• serwer przy krótkim piku zbyt szybko wchodzi w swap i podnosi latency,
• VM z małą ilością pamięci częściej wpada w presję i odzyskuje responsywność bardzo wolno,
• po zmianie swappiness objawy nie znikają, tylko przesuwają się w czasie.

Praktycznie dobrze jest spojrzeć nie tylko na zużycie swapu, ale też na tempo jego użycia, rosnące opóźnienia I/O i to, czy problem pojawia się pod konkretnym typem obciążenia. Jedna sprawa to 500 MB swapu zajęte przez dłuższy czas bez skutków ubocznych. Inna — nagłe intensywne przerzucanie stron przy każdej cięższej operacji.

Kiedy korekta ma sens

Na desktopie lub stacji roboczej z SSD/NVMe często testuje się niższe wartości, jeśli system zbyt wcześnie zaczyna swapować mniej aktywne procesy i robi się ociężały po przełączaniu aplikacji. Na serwerze aplikacyjnym, który ma przetrwać krótkie skoki i nie wykonywać codziennej pracy w swapie, również można zejść niżej niż domyślne ustawienia — ale dopiero po obserwacji zachowania pod realnym obciążeniem.

Na małych VM-kach i VPS-ach niski swappiness nie zawsze będzie dobrym pomysłem. Jeśli pamięci jest mało, a skoki są nieuniknione, zbyt twarde unikanie swapu może skończyć się szybciej zabitym procesem niż łagodniejszym zrzutem mniej aktywnych stron. Tu bardziej opłaca się myśleć kategoriami: jaki kompromis między responsywnością a przeżywalnością jest akceptowalny.

Błąd 8: mylenie normalnego użycia swapu z thrashingiem

Nie każdy zajęty swap oznacza katastrofę

To jedna z częstszych pomyłek przy diagnostyce. System może mieć zajęty swap i działać zupełnie poprawnie. Kernel przenosi mniej aktywne strony do przestrzeni wymiany, bo uznaje to za sensowne, a aktywny zestaw roboczy nadal mieści się w RAM. Sam wykres „swap used” bez kontekstu mówi niewiele.

Problem zaczyna się wtedy, gdy pojawia się thrashing, czyli sytuacja, w której system intensywnie przerzuca dane między RAM a swapem i traci czas głównie na obsługę pamięci, zamiast na realną pracę. Wtedy nie chodzi już o to, że swap jest użyty. Chodzi o to, że jest używany ciągle, nerwowo i pod presją.

Objawy, które odróżniają zdrowy bufor od realnego problemu

Jeśli chcesz odróżnić jedno od drugiego, patrz na zestaw objawów, nie na pojedynczą liczbę:

• Okazjonalne użycie swapu: brak wyraźnych przycięć, stabilne I/O, procesy odpowiadają normalnie, a zajętość swapu nie rośnie lawinowo przy każdej cięższej operacji.
• Thrashing: wysoki czas oczekiwania na I/O, długie lagi, procesy „żyją”, ale system reaguje z opóźnieniem, a aktywność swap in/swap out jest ciągła.
• Fałszywy trop: swap zajęty od dawna, ale bez ruchu i bez skutków wydajnościowych. W takim scenariuszu panika jest zbędna.

Na desktopie thrashing zwykle czuć natychmiast: okna zamierają, przełączenie karty w przeglądarce trwa podejrzanie długo, a dysk pracuje jakby chciał udowodnić swoją przydatność. Na serwerze wygląda to mniej widowiskowo, ale boleśniej dla użytkowników: rośnie latency, timeouty stają się częstsze, a aplikacja odzyskuje oddech dopiero po spadku presji pamięci.

Co zrobić zamiast patrzeć tylko na procenty

Jeśli podejrzewasz thrashing, sprawdzaj równolegle pamięć, I/O i zachowanie procesów. W praktyce pomagają tu m.in. vmstat, sar, free -h, top/htop, metryki PSI, statystyki cgroup i monitoring opóźnień dysku. Dopiero taki zestaw pokazuje, czy swap jest spokojnym buforem, czy aktywnym źródłem degradacji.

Błąd 9: decyzje podejmowane na ślepo, bez monitoringu i kontekstu

Dlaczego pojedynczy zrzut z terminala często wprowadza w błąd

Jednorazowe sprawdzenie free albo screenshot z panelu VPS-a rzadko wystarcza do sensownej decyzji. Problem ze swapem zwykle ujawnia się w czasie: podczas backupu, nocnej kompilacji, porannego ruchu, deployu albo po kilku dniach stopniowego narastania pamięciożerności procesu.

Bez monitoringu łatwo popełnić dwa klasyczne błędy. Pierwszy: uznać swap za winnego, chociaż przyczyną jest wyciek pamięci albo źle ustawione limity kontenera. Drugi: obniżyć swappiness lub zwiększyć swap, choć prawdziwy problem siedzi w storage albo zbyt agresywnym cache. Swap jest wtedy bardziej posłańcem niż sprawcą.

Minimum danych, które naprawdę pomagają

Nie trzeba od razu budować centrum kontroli lotów. Wystarczy zbierać kilka sensownych metryk:

• użycie RAM i swap w czasie, nie tylko stan bieżący,
• swap in / swap out,
• major page faults,
• opóźnienia I/O i obciążenie dysku,
• OOM events lub restarty procesów,
• zużycie pamięci per usługa, kontener, cgroup albo VM.

Dopiero na takim tle widać, czy masz do czynienia z krótkim skokiem, regularnym przeciążeniem, wyciekiem pamięci czy złą polityką limitów. To szczególnie ważne w środowiskach kontenerowych, gdzie host może wyglądać „w miarę dobrze”, a problem siedzi w jednym kontenerze duszonym przez memory limit.

Błąd 10: przenoszenie tej samej recepty między desktopem, serwerem, VPS-em i kontenerami

To samo ustawienie może być dobre w jednym miejscu i fatalne w innym

Konfiguracja swapu mocno zależy od środowiska. To, co poprawia komfort na laptopie z przeglądarką i IDE, nie musi mieć sensu na bazie danych, ciasnym VPS-ie albo hoście pod kontenery. Najgorsze decyzje zwykle biorą się z automatu: „u mnie zadziałało, więc ustawiam tak wszędzie”.

Dla porządku dobrze rozdzielić scenariusze:

• Desktop / stacja robocza – liczy się responsywność, nierówne obciążenie i czasem hibernacja. Tu zram i niższy swappiness częściej mają sens niż na produkcyjnym serwerze.
• Serwer aplikacyjny – swap bywa buforem bezpieczeństwa na skoki, ale nie powinien stawać się miejscem stałej pracy procesów.
• Serwer bazodanowy – zwykle lepiej unikać sytuacji, w której aktywny working set ląduje w swapie, bo latency szybko zaczyna boleć.
• Mały VPS – swap często ratuje przed natychmiastowym OOM, ale jakość storage i przewidywalność platformy mocno ograniczają jego użyteczność.
• VM – trzeba uważać na podwójne warstwy presji pamięci: gość może swapować, a host również może mieć swój problem z pamięcią.
• Kontenery – sam host może mieć swap, ale kluczowe są limity pamięci, zachowanie cgroup i to, czy aplikacja nie jest po prostu źle ograniczona.

Krótki przykład z praktyki: ten sam host deweloperski może działać całkiem dobrze z zram i umiarkowanym swap file, bo skoki obciążenia są krótkie i lokalne. Ten sam zestaw pomysłów wrzucony na produkcyjny serwer bazodanowy może tylko wydłużyć drogę do problemu, zamiast go rozwiązać.

Błąd 11: pominięcie hibernacji przy planowaniu swapu

Gdy wszystko wygląda dobrze, dopóki nie próbujesz uśpić systemu

Jeśli maszyna ma korzystać z hibernacji, swap przestaje być wyłącznie buforem bezpieczeństwa. Musi też pomieścić zapis stanu pamięci w scenariuszu usypiania. To zmienia kryteria doboru rozmiaru i czasem również typu swapu.

Typowy błąd wygląda niewinnie: system działa poprawnie na co dzień, swap jest mały, bo „przecież i tak rzadko używany”, a problem wychodzi dopiero przy próbie hibernacji. Efekt bywa różny: od nieudanej operacji po niestabilne wznowienie. Na desktopie i laptopie to ważniejsza kwestia niż na serwerze, ale właśnie dlatego łatwo ją przegapić przy kopiowaniu ustawień z maszyn, które hibernacji nie używają wcale.

Jeśli hibernacja jest wymagana, sprawdź nie tylko sam rozmiar swapu, ale też zgodność konfiguracji bootloadera, identyfikatora przestrzeni swap i mechanizmu resume. Samo „mam swap” nie wystarcza. W tym scenariuszu konfiguracja musi być spójna od początku do końca.

Co sprawdzić przed zmianą konfiguracji

Zanim zwiększysz swap, obniżysz swappiness albo przeniesiesz plik na inny nośnik, dobrze przejść przez krótki filtr decyzyjny. Pozwala uniknąć ruchów, które są technicznie poprawne, ale rozwiązują nie ten problem, co trzeba.

• Czy presja pamięci jest chwilowa czy stała? Chwilowe piki często uzasadniają korektę swapu. Stała presja zwykle wskazuje na zbyt mało RAM albo zbyt ciężką konfigurację usług.
• Czy objawem jest OOM, spadek responsywności czy wzrost I/O? Każdy z tych sygnałów sugeruje trochę inną przyczynę.
• Jaki jest nośnik pod swapem? NVMe i szybki SSD to inny świat niż wolny HDD lub nierówne storage na tanim VPS-ie.
• Czy system potrzebuje hibernacji? Jeśli tak, rozmiar i sposób konfiguracji swapu przestają być tylko kwestią wydajności.
• Czy problem siedzi w jednej usłudze? Jeden kontener, jeden worker albo jeden proces z wyciekiem pamięci potrafi zniekształcić cały obraz.
• Czy po zmianie da się zmierzyć efekt? Bez punktu odniesienia tuning łatwo zamienia się w zgadywanie.

Checklista decyzji po zmianach

• Swap istnieje tam, gdzie system realnie może wejść w presję pamięci.
• Rozmiar swapu odpowiada roli: bufor bezpieczeństwa, hibernacja albo oba scenariusze.
• Swap nie pełni funkcji stałego substytutu RAM.
• Wybrany typ ma sens operacyjny: plik, partycja, zram lub połączenie.
• Nośnik pod swapem nie staje się głównym wąskim gardłem przy skokach pamięci.
• vm.swappiness został ustawiony po obserwacji systemu, nie według internetowej mantry.
• Monitoring pokazuje różnicę między spokojnym użyciem swapu a thrashingiem.
• Konfiguracja jest dopasowana do środowiska: desktop, serwer, VPS, VM albo kontenery.
• Jeśli potrzebna jest hibernacja, przetestowano cały scenariusz resume.

Po wdrożeniu zmian dobrze zrobić prosty test obciążeniowy w swoim realnym scenariuszu, a nie tylko spojrzeć, czy system „wstał”. Na desktopie będzie to kilka cięższych aplikacji naraz i sprawdzenie responsywności. Na serwerze: backup, restart usług, build, większy import danych albo zwykły poranny pik ruchu. Jeśli po zmianie swap wprawdzie działa, ale rosną opóźnienia dysku i procesy dostają zadyszki, to znak, że problem tylko przesunął się o kilka metrów dalej.

Szczególnie zdradliwe są sytuacje, w których wszystko wygląda poprawnie przez większość dnia, a kłopot pojawia się raz na dobę albo raz w tygodniu. W praktyce to częsty obraz na małych VPS-ach i hostach pod kontenery: monitoring pokazuje spokój, po czym jedna aktualizacja, backup lub burst ruchu uruchamia karuzelę swapowania. Wtedy nie pomaga „magiczne” ustawienie jednego parametru. Trzeba zdecydować: dodać RAM, ograniczyć pamięciożerną usługę, przenieść swap na szybszy nośnik albo zmienić politykę limitów.

Najprostsza reguła wyboru jest dość przyziemna. Jeśli brakuje marginesu na krótkie piki, sens ma niewielki, sensownie umieszczony swap i ostrożny tuning. Jeśli system regularnie żyje dzięki swapowi, to nie jest tuning, tylko kredyt na wydajność z kiepskim oprocentowaniem. W takim układzie lepiej ciąć zużycie pamięci albo dołożyć RAM, zamiast negocjować z fizyką i liczyć, że tym razem się uda.

Dobrze ustawiony swap jest cichy i nudny — i właśnie o to chodzi. Ma pomagać systemowi przeżyć gorszy moment, a nie codziennie grać główną rolę.