Videre til indhold 
Jeg viser, hvordan du indstiller vm.swappiness, så web- og databasetjenester på hosting-servere reagerer hurtigere og forårsager mindre I/O. Med klare trin, fornuftige startværdier og overvågning får du mere ud af den eksisterende RAM og reducerer Forsinkelser og forhindrer unødvendig swapping.
Centrale punkter
Disse punkter giver dig et hurtigt overblik over, hvordan du kan finjustere indstillingerne med det samme.
- Swappiness-adfærd: Bestemmer, hvor tidligt kernen flytter RAM til swap.
- I forhold til arbejdsbyrden: Tilpas værdierne til applikationstypen, f.eks. database eller web.
- Midlertidig test: Tjek det først i praksis, og fastlæg det derefter permanent.
- Swap-layout: Tænk på størrelse, omfang og prioriteter.
- Overvågning: Overvåg og juster I/O, RAM og responstider.
Hvad vm.swappiness er, og hvordan det fungerer
Kernel-parameteren vm.swappiness bestemmer, hvor aggressivt Linux flytter hukommelsessider fra RAM til swap. Du finder den aktuelle værdi i pseudofilsystemet under /proc/sys/vm/swappiness og kan ændre den under kørsel eller permanent. En høj værdi medfører tidligere udskiftning, mens en lav værdi holder indholdet længere i RAM. Målet er at opnå en god balance mellem RAM-udnyttelse, sidecache og kontrolleret swap-adfærd. Jeg husker på, at RAM er meget hurtigere end enhver SSD, så jeg foretrækker Arbejdshukommelse klart før swap.
Hvorfor swappiness er vigtig på hosting-servere
På web- og applikationsservere er det indstillingen af Udskiftning om reaktionstid og gennemstrømning. Aggressiv swapping skaber ekstra I/O-belastning og bremser forespørgsler, især ved databasetunge arbejdsbelastninger. For lave værdier medfører derimod risikoen for senere OOM-hændelser, som brat afbryder processer. Derfor vurderer jeg ud over RAM og swap også typiske belastningsspidser, cacher og forespørgselsmønstre. Ved at reducere latenstider forhindrer man hakken og holder transaktionerne mærkbart flydende.
Anbefalinger baseret på arbejdsbelastning
En enkelt værdi passer sjældent til alle scenarier, derfor starter jeg med gennemprøvede intervaller og tilpasser dem derefter til måledataene. Databaser har gavn af meget lave indstillinger, mens rene webservere ofte kan klare lidt højere værdier. Test- eller udviklingssystemer kan køre tættere på standarden, fordi brugervenlighed spiller en større rolle. Følgende skema bruger jeg som en pragmatisk indgang til Hosting-Arbejdsbelastninger. Derefter overvåger jeg I/O, swap-udnyttelse og responstider og finjusterer efter behov.
| Arbejdsbyrde | Anbefalet Swappiness | Mål |
|---|---|---|
| Databaser (MySQL, PostgreSQL) | 0–10 | Bevar bufferen i RAM, hold latenstiderne lave |
| Realtid/lav latenstid | 0–10 | Undgå I/O-spidsbelastninger ved hjælp af swap |
| Webserver med cacher | 10–20 (i nogle tilfælde 10–30) | Flyt kolde sider ud, aktive forespørgsler i RAM’en |
| Udvikling/Test | 30–60 | Komfort og stabilitet frem for forsinkelse |
Kontroller den aktuelle værdi
Inden jeg ændrer værdierne, aflæser jeg status og dokumenterer Baseline. Til det bruger jeg enten `cat /proc/sys/vm/swappiness` eller `sysctl vm.swappiness`; begge metoder giver et tal som f.eks. 60. Samtidig tjekker jeg RAM- og swap-udnyttelsen med `free -h`. Med swapon –show kan jeg se størrelse, prioritet og medium for de aktive swap-enheder. Disse udgangsdata hjælper mig med at vurdere effekterne senere tildele for at være i stand til det.
Test det midlertidigt i stedet for at ændre det med det samme
Jeg installerer Swappiness først som en prøve for at se, hvordan det fungerer under reelle Belastning kan ses. Kommandoen sysctl vm.swappiness=10 virker med det samme, men varer kun indtil genstart. Under testene holder jeg øje med top eller htop, tjekker vmstat og iostat og måler tjenesternes responstider. Hvis swap-frekvensen falder, og latenstiderne forbliver stabile, fortsætter jeg i fornuftige trin. Først når målingerne er overbevisende, skriver jeg værdien permanent fast.
Konfigurer permanent
Hvis testværdien passer, indtaster jeg den i en sysctl-konfiguration og genindlæser indstillingerne. I /etc/sysctl.conf tilføjer jeg linjen vm.swappiness=10 og aktiverer den med sysctl -p. Jeg foretrækker at opbevare en separat fil i /etc/sysctl.d/, f.eks. 99-swappiness.conf, og indlæser den med sysctl –system. Det er nemt at versionere og integrere i automatisering. En mere detaljeret oversigt over relaterede parametre findes i dette indlæg om indstilling af sysctl, der hjælper mig med at strukturere ændringerne og Klarhed bringer.
Swap-størrelse, hukommelseslayout og datamedier
Swappiness virker aldrig isoleret, derfor vurderer jeg størrelsen og placeringen af Bytte altid med. For lidt swap bliver hurtigt fyldt op, mens for stor swap forlænger I/O-faser under belastning. På SSD eller NVMe er swap hurtigere end på HDD, men RAM er stadig flere størrelsesordener hurtigere. Flere swap-enheder med prioriteter hjælper med at udnytte det hurtigste medie først. Hvis du vil dykke dybere ned i fordele og ulemper, finder du i denne oversigt over Swap i hosting nyttige tanker til Øvelse.
Arbejdsgang i praksis: Trin for trin
Jeg starter med en statusopgørelse: registrerer den aktuelle Swappiness-værdi, RAM- og swap-udnyttelse, CPU og I/O og gemmer det som Reference sikre. Derefter klassificerer jeg arbejdsbelastningen: hovedsageligt database, web med cache, blandet drift eller containerbaseret. Herefter fastlægger jeg et mål: 0–10 for databaser, for web typisk 10–20, og for blandede belastninger går jeg forsigtigt frem. Jeg indstiller værdien midlertidigt, observerer flere belastningsfaser og sammenligner målinger. Hvis billedet stemmer overens gentagne gange, fastlægger jeg værdien, dokumenterer ændringen og kontrollerer den efter kerne-, hardware- eller Udgivelse-Skift igen.
Særlige scenarier: Containere, virtuelle maskiner og cloud
I containere og virtuelle maskiner øger jeg swappiness på både værts- og gæsteniveau sammen . Orkestreringsplatforme som Kubernetes drager som regel fordel af meget lave indstillinger på arbejdsknudepunkterne for at holde pod-latenser lave. I VM’er indstiller jeg passende værdier internt, men sørger for, at hypervisoren ikke modarbejder dette. I elastiske cloud-opsætninger hjælper konservative værdier med at udjævne spidsbelastninger, indtil skaleringen slår igennem. Jeg undgår, at en enkelt container på grund af intensiv swap-adfærd belaster hele Platform bremser.
Overvågning og fejlfinding
Typiske advarselstegn på en uhensigtsmæssig swappiness ser jeg i form af høj I/O-belastning, selvom der stadig er ledig RAM, svingende responstider og træge databaseforespørgsler. Sådanne mønstre tjekker jeg med vmstat, iostat, sar samt målinger fra min observability-stack. Hvis systemet viser stor brug af swap trods ledig RAM, sætter jeg som regel swappiness-værdien lavere. Hvis jeg ser OOM-logfiler eller afbrydelser ved knap RAM, hæver jeg swappiness-værdien moderat eller justerer swap-opsætningen. Den følgende tabel kategoriserer symptomer på en sandsynlig Årsag og angiver en første retning.
| Symptom | Sandsynlig årsag | Næste skridt |
|---|---|---|
| Høj I/O når der er ledig RAM | Swappiness for høj | Reducere værdien, måle effekten |
| OOM-hændelser under belastning | Swappiness for lav eller for lidt swap | Hæv værdien, kontroller swap-størrelsen |
| Tunge forespørgsler trods CPU-reserve | Databasebuffer flyttet til disk | Værdi mellem 0 og 10, analyser DB-bufferen |
| Belastningsspidser uden CPU-flaskehals | Swap-forårsagede I/O-spidsbelastninger | Sænk swappiness, kontroller cache-hits |
At forstå finmaskede måleparametre
For at vurdere swappiness objektivt kigger jeg nærmere på kerne-tællerne. I /proc/vmstat angiver pswpin og pswpout henholdsvis antallet af indlæste og udlagrede sider. pgscan_kswapd_* og pgsteal_* viser, hvor aggressivt reclaimeren arbejder. Hvis der er mange pgmajfault (Major Page Faults), tyder det på I/O-tunge genindlæsninger. Jeg læser disse værdier gentagne gange eller med sar -B og sar -W for at se frekvenser, ikke kun øjebliksbilleder. Med vmstat 1 kan jeg se si/so (swap in/out) og tilordne spidsbelastninger til reelle hændelser. Derudover giver /proc/pressure/memory en vurdering af, hvor meget opgaver påvirkes af hukommelsespres blok (PSI). Hvis nogle eller alle disse værdier stiger, er det et klart tegn på for aggressiv reclaim eller uhensigtsmæssig swappiness.
Swappiness 0 vs. 1: hvad kernen egentlig gør
Man antager ofte, at Swappiness=0 deaktiverer swap fuldstændigt. Det er ikke helt korrekt. 0 signalerer til kernen, at den skal undgå swap så vidt muligt og kun bruge det, når der er reel pladsmangel. I praksis er en værdi på 1–10 tilstrækkelig til at opnå en meget tilbageholden adfærd, mens 0 i enkelte versioner lejlighedsvis kan føre til forsinkede, men til gengæld voldsomme reclaim-faser. Til tidsfølsomme tjenester indstiller jeg som regel 1–5 og holder øje med, om pswpout/pswpin forbliver praktisk talt på nul. Hvis der opstår OOM-hændelser ved 0 under spidsbelastninger, hæver jeg værdien lidt, så kernen tidligere og blidt aflaster presset i stedet for at gøre det brat at bryde ind.
Sådan udnytter du Zswap og ZRAM bedst muligt
Ud over klassisk swap på harddisken bruger jeg, afhængigt af profilen, enten Zswap eller ZRAM. Zswap komprimerer de sider, der er flyttet til swap-området, og opbevarer dem først i RAM, før de flyttes til harddisken, hvis det bliver nødvendigt. Det reducerer I/O og udjævner ventetider, men belaster CPU'en. På værter med stor CPU-reserve er det en mere indbringende Afvejning. ZRAM stiller komprimeret swap til rådighed direkte i RAM – ideelt til spidsbelastninger eller meget små virtuelle maskiner, hvor jeg foretrækker at bruge komprimeret RAM frem for langsom I/O. Vigtigt: Jeg vælger bevidst et af koncepterne og prioriterer således, at den hurtigste vej betjenes først. Swappiness forbliver herved et styringsredskab: selv med Zswap/ZRAM ønsker jeg at undgå unødvendige reclaim-bølger.
Sidecache, vfs_cache_pressure og cache-hits
Swappiness interagerer med sidecachen, der opbevarer filer og inoder i RAM. Med vm.vfs_cache_pressure styrer jeg, hvor aggressivt kernen rydder disse cacher over for anonyme sider. For høje værdier får metadatacacher til at forsvinde for hurtigt, hvilket bremser webserverne. Jeg starter som regel med 50–100, måler cache-hit-raterne og observerer, hvordan latenstiderne for statiske ressourcer og API-svar udvikler sig. Målet er at holde hyppigt brugt indhold i RAM'en uden at sjældent anvendte sider tilstopper arbejdshukommelsen. Hvis hitraten forbliver god og I/O-belastningen lav, fungerer samspillet optimalt; ellers justerer jeg swappiness og vfs_cache_pressure i Tandem.
Undgå »dirty writeback« og I/O-spidsbelastninger
Skrivestier påvirker latenstiderne på samme måde som swap. Med vm.dirty_background_ratio/bytes og vm.dirty_ratio/bytes bestemmer jeg, hvor meget »snavset« cache der dannes, før kernen skriver til disk. Jeg foretrækker *_bytes frem for procenter for at fastsætte definerede øvre grænser – især i konfigurationer med stor RAM, hvor procenter kan skabe enorme bølger af writeback. Mål: kontinuerlig, planlægbar skrivning i stedet for sporadiske bølger, der sammen med swap skaber I/O-låse. Jeg overvåger iostat og writeback-køerne og holder værdierne på et niveau, så SSD/NVMe udnyttes konstant, men ikke kørt over blive.
NUMA, Zone Reclaim og store værter
På systemer med NUMA spiller hukommelseslokalisering en rolle. Hvis vm.zone_reclaim_mode er aktiveret, kan kernen mere aggressivt genvinde hukommelse på den lokale NUMA-node, hvilket utilsigtet kan udløse spidsbelastninger i genvindingen. For mange hosting-arbejdsbelastninger deaktiverer jeg Zone Reclaim og overlader placeringen til scheduleren for at opnå en mere stabil drift. Derudover tjekker jeg Transparent Huge Pages (THP): Databaser reagerer ofte bedre på THP=never eller madvise, fordi uplanlagt defragmentering og THP-tildelinger kan udløse latensspidser. Swappiness kan være perfekt – men hvis THP eller NUMA-politikker blander sig, forbliver Hakkende bevægelse.
Container- og Cgroups-enheder
Med Cgroups v2 har jeg ud over host-swappiness yderligere indstillingsmuligheder: memory.high udløser en blid genvinding, memory.max sætter strenge øvre grænser, og memory.swap.max begrænser swap pr. arbejdsbelastning. På den måde forhindrer jeg, at enkelte containere bremser værten via swap. Jeg indstiller lave swappiness-værdier på noden og prioriterer kritiske arbejdsbelastninger via `memory.low`, så deres hotsets forbliver længere i RAM. I Kubernetes holder jeg øje med, hvordan noden håndterer swap, og tester ændringer først i ikke-produktionspuljer. Det er vigtigt at have det samlede overblik: Værtsparametre, Cgroup-grænser og orkestratoren skal passe sammen, ellers flyttes presset blot fra et niveau til andre.
Implementering, automatisering og tilbagefald
Jeg implementerer ændringer i Swappiness på samme kontrollerede måde som enhver anden ydeevneoptimering: først på en lille gruppe næsten identiske noder (Canary), derefter gradvist i større omfang. Systemd-sysctl eller konfigurationsstyring integrerer værdierne på en reproducerbar måde. Jeg dokumenterer start- og målværdier, tidspunkter, involverede værter og Metrikker. I tilfælde af et tilbageslag planlægger jeg på forhånd den modsatte ændring (f.eks. sysctl vm.swappiness=60) og gemmer de tidligere sysctl-filer. I vedligeholdelsesvinduer måler jeg bevidst typiske belastningsscenarier, så jeg ikke forveksler ændringer med udsving i tidspunktet på dagen eller trafikken. Kun på den måde forbliver beslutningerne pålidelige og i teamet forståelig.
Almindelige misforståelser og anti-mønstre
- „Swappiness=0 deaktiverer swap“: Nej, kernen bruger stadig swap – men kun i meget begrænset omfang.
- „Jo flere swaps, desto mere sikkerhed“: For meget swap forlænger belastningsperioder og skjuler RAM-flaskehalse i stedet for at løse dem.
- „Med NVMe er swapping ligegyldigt“: NVMe er hurtigt, men flere størrelsesordener langsommere end RAM. Latenstiderne er stadig mærkbare.
- „En værdi for alle servere“: Arbejdsbelastningerne varierer meget. Uden målinger er optimering et spørgsmål om tilfældigheder.
- „Swappiness løser ethvert forsinkelsesproblem“: Problemer skyldes ofte cache-hits, writeback, THP, forespørgselsplaner eller netværksstier.
Resumé til hurtig start
Jeg indstiller typisk vm.swappiness til 10–20 for webservere og til 0–10 for databaser, tester effekten og overvåger I/O, ventetider og Bytte-andel. Den endelige værdi fastlægger jeg via sysctl i /etc/sysctl.d/ og sørger for, at ændringerne kan spores. Samtidig sørger jeg for et velafbalanceret swap-layout: passende størrelse, hurtigt medie, fornuftige prioriteter. Hvad angår belastningen på hukommelsen, holder jeg desuden øje med side-cachen og dens adfærd; denne oversigt giver en god indføring i Fjernelse fra sidecachen, som hjælper mig med at analysere årsagerne og Sammenhæng . Med denne fremgangsmåde opnår jeg pålidelige svartider, forhindrer overbelastning af swap-området og udnytter den tilgængelige RAM effektivt.
