Zswap este una dintre acele funcții Linux care poate face un sistem să pară mai fluid sub presiune de memorie, dar poate și să consume CPU inutil dacă este configurată după rețete copiate de pe forumuri. Ideea de bază este simplă: paginile care ar ajunge în swap sunt comprimate și ținute într-un pool din RAM, înainte să fie scrise pe dispozitivul de swap. Practic, zswap funcționează ca un cache comprimat pentru swap.
Pentru utilizatorii avansați, întrebarea importantă nu este „care este valoarea perfectă?”, ci „ce compromis are sens pentru workload-ul meu?”. Alegerea compressorului, a allocatorului/pool-ului și a valorii swappiness trebuie făcută după comportamentul aplicațiilor, cantitatea de RAM, viteza stocării și costul CPU.
Cum gândești compressorul: latență sau rată de compresie
Documentația kernelului arată că zswap folosește un compressor configurabil, ales implicit la compilarea kernelului, dar care poate fi schimbat prin parametri de boot sau prin sysfs. În kerneluri moderne, opțiunile întâlnite frecvent includ zstd, lz4, lzo și altele, în funcție de configurația distribuției.
Alegerea nu trebuie făcută după „zstd e cel mai bun” sau „lz4 e cel mai rapid”, fără context. Dacă ai un laptop sau workstation unde aplicațiile deschid multe taburi, IDE-uri, containere și procese interactive, latența contează mult. Acolo, un compressor rapid precum lz4 poate reduce senzația de blocaj când sistemul începe să recupereze pagini din zswap.
Dacă ai un sistem cu RAM limitată, dar CPU suficient, unde scopul este să ții cât mai multe pagini în memorie comprimată, zstd poate fi atractiv datorită compresiei mai bune. Costul este mai mult CPU la comprimare și decomprimare. Pentru workload-uri cu presiune rară de memorie, acest cost poate fi acceptabil. Pentru workload-uri care intră constant în swap, devine o taxă permanentă.
Regula practică: testează cu același set de aplicații, nu cu benchmarkuri izolate. Urmărește timpul de răspuns, încărcarea CPU, numărul de pagini respinse de zswap și cât de des se ajunge la swap real pe disc.
Zpool-ul: ce alegi când distribuția încă îl expune
În documentația actuală a kernelului, zswap este descris ca folosind zsmalloc pentru gestionarea pool-ului comprimat. zsmalloc este proiectat pentru scenarii de memorie redusă și evită alocările de pagini de ordin mare, care pot eșua mai ușor sub presiune. Asta îl face potrivit pentru obiecte comprimate de dimensiuni variabile, cum sunt paginile din zswap.
Pe sisteme mai vechi sau în ghiduri mai vechi vei vedea discuții despre zbud, z3fold și zsmalloc. Aici trebuie atenție: nu toate opțiunile sunt disponibile în toate kernelurile, iar unele informații de pe forumuri pot fi depășite. Înainte să copiezi o setare precum zswap.zpool=…, verifică ce expune sistemul tău în /sys/module/zswap/parameters/ și ce suport are kernelul distribuției tale.
Dacă sistemul folosește deja zsmalloc și nu expune alternativă, nu forța concluzii din ghiduri vechi. În schimb, concentrează-te pe compressor, max_pool_percent, shrinker_enabled și swappiness.
Swappiness: nu este un buton „mai mult sau mai puțin swap”
Kernelul definește swappiness ca o estimare a costului relativ dintre swap și cache-ul de filesystem, pe o scară de la 0 la 200. Valoarea implicită este 60. Documentația Linux menționează explicit că pentru swap în memorie, precum zram sau zswap, pot fi luate în calcul valori peste 100, mai ales când accesul la swap este mai ieftin decât I/O-ul de filesystem.
Asta nu înseamnă că 180 este automat „mai bine”. Pentru desktop interactiv cu SSD rapid, o valoare moderată poate fi suficientă. Pentru sistem cu zswap eficient, aplicații multe și pagini reci care pot fi comprimate bine, o valoare mai mare poate ajuta kernelul să mute mai devreme pagini inactive în zswap și să păstreze cache util. Pentru aplicații sensibile la latență, baze de date sau workload-uri care refolosesc agresiv memoria, valori prea mari pot crea activitate inutilă.
Gândește swappiness ca un semnal de politică, nu ca o comandă rigidă. Testează incremental: de exemplu, compară 60, 100 și 133 în aceleași condiții. Dacă sistemul devine mai fluid fără creștere deranjantă de CPU și fără scrieri excesive în swap real, direcția este bună. Dacă apar pauze, consum CPU mare sau thrashing, ai mers prea departe.
Parametrii care contează în testare
max_pool_percent controlează cât din RAM poate ocupa pool-ul comprimat. Kernelul precizează că pool-ul nu este prealocat; crește la nevoie și are o limită. O limită mai mare poate ajuta când datele se comprimă bine, dar poate reține prea multă memorie în zswap.
accept_threshold_percent introduce o formă de histerezis: după ce pool-ul se umple, zswap poate refuza pagini până când există suficient spațiu. Scopul este evitarea situației în care sistemul tot bagă și scoate pagini din pool fără beneficiu real.
shrinker_enabled poate permite evacuarea proactivă a paginilor reci din zswap către swap, când există presiune. Pentru sisteme unde zswap se umple cu date reci, poate fi util. Pentru workload-uri unde swap-ul pe disc este foarte lent, trebuie testat atent.
Concluzia practică este simplă: zswap nu se optimizează după valori universale. Pentru interactivitate, începe cu un compressor rapid și swappiness moderat spre ridicat. Pentru economie de RAM, testează zstd și un pool ceva mai generos. Pentru servere sau aplicații critice, măsoară latența și comportamentul sub presiune înainte să păstrezi setarea. Cea mai bună configurație este cea care reduce I/O-ul real și păstrează sistemul predictibil, nu cea care arată bine într-un comentariu de forum.
