Un server nu crapa intotdeauna imediat cand ramane fara RAM.
Uneori incepe sa foloseasca swap si, pentru o vreme, pare ca inca duce. Procesele sunt pornite, serviciile raspund partial, load-ul creste, dar nimic nu pare complet mort.
Doar ca swap-ul nu rezolva lipsa de memorie. O amana.
RAM-ul este rapid. Swap-ul este pe disc. Chiar si pe SSD/NVMe, diferenta se simte cand sistemul incepe sa mute constant pagini intre memorie si swap. In loc sa ai un crash clar, ajungi sa ai latenta mare, requesturi blocate, timeout-uri si aplicatii care par inghetate.
Asta este partea neplacuta: swap-ul poate transforma o problema evidenta intr-una mai greu de prins.
Din exterior se vede simplu:
pagini care se incarca greu
requesturi care stau la coada
timeout-uri intre proxy, aplicatie si backend
load mare, dar CPU care nu pare neaparat blocat la 100%
SSH lent
procese care exista, dar nu mai raspund cum trebuie
aplicatii care isi revin dupa restart, apoi revin la aceeasi stare
De aici apare si confuzia clasica: “CPU-ul nu e full, deci nu e de la resurse”.
Nu neaparat.
CPU usage, RAM usage, swap usage si I/O wait trebuie citite impreuna. Un server poate sa nu fie limitat de CPU, dar sa fie sufocat de memorie si disc. Daca vezi swap folosit constant si „si/so” active in vmstat, sistemul nu doar are ceva swap ocupat, ci chiar face swapping. Acolo incepe degradarea serioasa.
Faptul ca apare swap folosit nu inseamna automat incident. Mai important este daca swap-ul creste, daca exista swap in/swap out constant si daca apar semne de I/O wait sau OOM.
Cauzele sunt de obicei destul de banale:
prea multe procese
prea multi worker-e pentru memoria disponibila
joburi grele rulate in acelasi timp cu traficul normal
importuri, indexari sau cron-uri prost programate
cache dimensionat gresit
memory leak
trafic peste capacitatea reala a serverului
containere sau servicii fara limite clare
Ce nu as face este sa tratez swap-ul ca pe o extensie normala de RAM. Daca un sistem are 8 GB RAM si 16 GB swap, nu inseamna ca are 24 GB memorie utila pentru workload. Inseamna ca, atunci cand RAM-ul nu ajunge, serverul incepe sa plateasca diferenta in latenta.
Marirea swap-ului poate fi o masura temporara, dar nu trebuie sa fie concluzia investigatiei. Altfel risti sa obtii un sistem care nu mai cade imediat, dar devine suficient de lent incat pentru utilizator tot indisponibil este.
Mitigarea reala este in alta parte: mai putini worker-e, joburi grele separate, limite mai clare, optimizare in aplicatie, mai multa memorie unde workload-ul o cere si monitorizare pe swap, I/O wait, OOM si latenta, nu doar pe CPU si disk space.
Swap-ul este util. E bine sa existe. Poate salva sistemul in anumite momente.
Dar trebuie privit ca un airbag, nu ca motor.
Daca ajungi sa rulezi zilnic in swap, problema nu este ca ai nevoie de un airbag mai mare. Problema este ca sistemul merge deja peste ce poate duce confortabil.