Hoppa till innehåll 
Jag visar hur du ställer in vm.swappiness så att webb- och databastjänster på webbhotellsservrar reagerar snabbare och orsakar mindre I/O. Med tydliga steg, lämpliga startvärden och övervakning får du ut mer av det befintliga RAM-minnet och minskar Fördröjningar och förhindrar onödig swapping.
Centrala punkter
Dessa punkter ger dig en snabb översikt över inställningar som du kan använda direkt.
- Swappiness-beteende: Styr hur tidigt kärnan flyttar RAM-minne till swap-utrymmet.
- Relation till arbetsbelastning: Anpassa värdena efter applikationstyp, t.ex. databas eller webb.
- Testa tillfälligt: Kontrollera först i praktiken, fastställ sedan permanent.
- Swap-layout: Tänk på storlek, omfattning och prioriteringar.
- Övervakning: Övervaka och justera I/O, RAM och svarstider.
Vad vm.swappiness är och hur det fungerar
Kärnparametern vm.swappiness bestämmer hur aggressivt Linux flyttar minnessidor från RAM till swap. Du hittar det aktuella värdet i pseudofilsystemet under /proc/sys/vm/swappiness och kan ändra det under körning eller permanent. Ett högt värde leder till tidigare utlagring, medan ett lågt värde håller innehållet kvar längre i RAM-minnet. Målet är att uppnå en bra balans mellan RAM-utnyttjande, sidcache och kontrollerat swap-beteende. Jag håller följande i åtanke: RAM-minnet är mycket snabbare än vilken SSD som helst, så jag föredrar Arbetsminne klart före swappen.
Varför swappiness är viktigt på webbhotellsservrar
På webb- och applikationsservrar avgör inställningen av Swappiness om reaktionstid och genomströmning. Aggressiv swapping skapar extra I/O-belastning och bromsar förfrågningar, framför allt vid databasintensiva arbetsbelastningar. För låga värden medför däremot risken för senare OOM-händelser, som avbryter processer abrupt. Därför utvärderar jag, förutom RAM och swap, även typiska belastningstoppar, cacher och förfrågningsmönster. Den som minskar latensen förhindrar hackande och håller transaktionerna märkbart vätska.
Rekommendationer utifrån arbetsbelastning
Ett enda värde passar sällan för alla scenarier, därför börjar jag med beprövade intervall och anpassar sedan utifrån mätdata. Databaser mår bra av mycket låga inställningar, medan rena webbservrar ofta tål något högre värden. Test- eller utvecklingssystem kan köras närmare standardvärdena, eftersom användarvänligheten spelar en större roll. Följande schema använder jag som en pragmatisk utgångspunkt för Hosting-Arbetsbelastningar. Därefter övervakar jag I/O, swap-användning och svarstider och justerar inställningarna efter behov.
| Arbetsbelastning | Rekommenderad swappiness | Mål |
|---|---|---|
| Databaser (MySQL, PostgreSQL) | 0–10 | Hålla buffertar i RAM-minnet, minimera latensen |
| Realtid/låg latens | 0–10 | Undvika I/O-toppar genom att använda swap |
| Webbserver med cacher | 10–20 (ibland 10–30) | Flytta kalla sidor till lagringsenheten, aktiva förfrågningar i RAM-minnet |
| Utveckling/Testning | 30–60 | Komfort och stabilitet före latens |
Kontrollera aktuellt värde
Innan jag ändrar värdena läser jag av statusen och dokumenterar den Baslinje. Jag använder antingen `cat /proc/sys/vm/swappiness` eller `sysctl vm.swappiness`, och båda metoderna ger ett tal som 60. Samtidigt kontrollerar jag RAM- och swap-användningen med `free -h`. Med swapon –show kan jag se storlek, prioritet och medium för de aktiva swap-enheterna. Dessa utgångsdata hjälper mig att senare analysera effekterna fördela för att kunna göra det.
Testa tillfälligt istället för att göra en permanent ändring direkt
Jag testar Swappiness först för att se hur det går i verkliga Last att se. Kommandot sysctl vm.swappiness=10 träder i kraft omedelbart, men gäller bara fram till nästa omstart. Under testerna följer jag top eller htop, kontrollerar vmstat och iostat och mäter tjänsternas svarstider. Om swapfrekvensen minskar och latenserna förblir stabila går jag vidare i rimliga steg. Först när mätvärdena är övertygande skriver jag in värdet permanent fast.
Konfigurera permanent
Om testvärdet stämmer lägger jag in det i en sysctl-konfiguration och laddar om inställningarna. I /etc/sysctl.conf lägger jag till raden vm.swappiness=10 och aktiverar den med sysctl -p. Jag tycker att det blir snyggare att ha en egen fil i /etc/sysctl.d/, till exempel 99-swappiness.conf, och ladda den med sysctl –system. Det går bra att versionshantera och integrera i automatisering. En fördjupad översikt över relaterade parametrar finns i det här inlägget om sysctl-trimning, som hjälper mig att strukturera ändringarna och Klarhet ger.
Swap-storlek, minneslayout och lagringsmedia
Swappiness verkar aldrig isolerat, därför bedömer jag storleken och läget på Byta alltid med. För lite swap blir snabbt fullt, medan en överdimensionerad swap förlänger I/O-faserna under belastning. På SSD eller NVMe är swap snabbare än på HDD, men RAM ligger fortfarande flera storleksordningar före. Flera swap-enheter med prioriteringar hjälper till att använda det snabbaste mediet först. Den som vill fördjupa sig i för- och nackdelarna hittar i denna översikt över Swap vid webbhotell användbara tankeställare för Övning.
Arbetsflöde i praktiken: steg för steg
Jag börjar med att kartlägga läget: noterar aktuellt Swappiness-värde, RAM- och swap-användning, CPU och I/O och sparar detta som Referens säkerställa. Därefter klassificerar jag arbetsbelastningen: främst databas, webb med cache, blandad drift eller containeriserad. Därefter fastställer jag ett mål: för databaser 0–10, för webb oftast 10–20, för blandade belastningar går jag försiktigt fram. Jag ställer in värdet tillfälligt, observerar flera belastningsfaser och jämför mätvärden. Om bilden stämmer upprepade gånger fastställer jag värdet, dokumenterar ändringen och kontrollerar den efter kärn-, hårdvaru- eller Release-Byt igen.
Särskilda scenarier: containrar, virtuella maskiner och molnet
I containrar och virtuella maskiner utvärderar jag swappiness på värd- och gästnivå tillsammans . Orkestreringsplattformar som Kubernetes drar oftast nytta av mycket låga inställningar på arbetarnoderna för att hålla latensen i podarna låg. I virtuella maskiner ställer jag in lämpliga värden internt, men ser till att hypervisorn inte motverkar detta. I elastiska molnmiljöer hjälper konservativa värden till att jämna ut toppar tills skalningen träder i kraft. Jag undviker att en enskild container genom intensivt swap-beteende belastar hela Plattform bromsar.
Övervakning och felsökning
Typiska varningssignaler på olämplig swappiness ser jag i form av hög I/O-belastning trots ledigt RAM-minne, varierande svarstider och tröga databasfrågor. Jag kontrollerar sådana mönster med vmstat, iostat, sar samt mätvärden från min observability-stack. Om systemet visar hög swap-användning trots ledigt RAM-minne sänker jag oftast swappiness-värdet. Om jag ser OOM-loggar eller avbrott vid brist på RAM-minne höjer jag swappiness-värdet måttligt eller justerar swap-inställningarna. Följande tabell sorterar symtom på en trolig Orsak och ger en första riktning.
| Symptom | Sannolik orsak | Nästa steg |
|---|---|---|
| Hög I/O när det finns ledigt RAM-minne | Swappiness för hög | Minska värdet, mäta effekten |
| OOM-händelser under belastning | Swappiness för låg eller för lite swap | Höj värdet, kontrollera swapstorleken |
| Långsamma sökfrågor trots CPU-reserv | Databasbuffert flyttad | Värde mellan 0 och 10, analysera DB-buffert |
| Belastningstoppar utan flaskhals i processorn | Swap-orsakade I/O-toppar | Minska swappiness, kontrollera cache-träffar |
Att förstå finfördelade mätvärden
För att objektivt utvärdera swappiness tittar jag närmare på kärnans räknare. I /proc/vmstat anger pswpin och pswpout antalet inlästa respektive utlagrade sidor. pgscan_kswapd_* och pgsteal_* visar hur aggressivt återvinningsprogrammet arbetar. Om pgmajfault (Major Page Faults) hopar sig tyder det på I/O-tunga omladdningar. Jag läser av dessa värden upprepade gånger eller med sar -B och sar -W för att se frekvenser, inte bara ögonblicksbilder. Med vmstat 1 kan jag se si/so (Swap in/out) och koppla toppar till faktiska händelser. Dessutom ger /proc/pressure/memory en uppskattning av hur starkt uppgifter påverkas av minnespress block (PSI). Om dessa värden stiger något eller helt, har jag en tydlig indikation på att återvinningen är för aggressiv eller att swappiness-värdet är olämpligt.
Swappiness 0 vs. 1: vad kärnan egentligen gör
Man antar ofta att Swappiness=0 inaktiverar swap helt. Det stämmer inte riktigt. Värdet 0 signalerar till kärnan att undvika swap så långt det går och endast använda det vid verklig minnesbrist. I praktiken räcker ett värde mellan 1 och 10 för att uppnå ett mycket återhållsamt beteende, medan 0 i vissa versioner ibland kan leda till sena, men däremot kraftiga, återvinningsfaser. För tjänster där latensen är avgörande använder jag oftast värden mellan 1 och 5 och observerar om pswpout/pswpin i praktiken förblir nära noll. Om värdet 0 leder till OOM-händelser under belastningstoppar höjer jag värdet något, så att kärnan avlastar trycket tidigare och mjukare, istället för att göra det abrupt. att bryta sig in.
Att använda Zswap och ZRAM på ett meningsfullt sätt
Förutom klassisk swap på hårddisken använder jag, beroende på profil, antingen Zswap eller ZRAM. Zswap komprimerar de sidor som har flyttats ut och lagrar dem först i RAM-minnet innan de vid behov flyttas till lagringsenheten. Detta minskar I/O-belastningen och jämnar ut latenserna, men kräver dock CPU-resurser. På värddatorer med stor CPU-reserv är detta en lönsammare Avvägning. ZRAM tillhandahåller komprimerad swap direkt i RAM-minnet – perfekt för sporadiska belastningar eller mycket små virtuella maskiner, där jag hellre använder komprimerat RAM-minne än långsam I/O. Viktigt: Jag väljer medvetet ett av koncepten och prioriterar så att den snabbaste vägen betjänas först. Swappiness förblir ett styrverktyg: även med Zswap/ZRAM vill jag undvika onödiga återvinningsvågor.
Sidcache, vfs_cache_pressure och cache-träffar
Swappiness samverkar med sidcachen, som lagrar filer och inoder i RAM-minnet. Med vm.vfs_cache_pressure styr jag hur aggressivt kärnan rensar dessa cacher när det gäller anonyma sidor. För höga värden gör att metadatacacherna försvinner för snabbt, vilket bromsar webbservrarna. Jag börjar oftast med 50–100, mäter cache-träfffrekvenserna och observerar hur latenserna för statiska resurser och API-svar utvecklas. Målet är att behålla ofta använt innehåll i RAM-minnet utan att sällan använda sidor tar upp för mycket utrymme i minnet. Om träfffrekvensen förblir god och I/O-belastningen låg fungerar samspelet bra; i annat fall justerar jag swappiness och vfs_cache_pressure i Tandem.
Undvika ”dirty writeback” och I/O-toppar
Skrivvägar påverkar latensen lika mycket som swap. Med vm.dirty_background_ratio/bytes och vm.dirty_ratio/bytes bestämmer jag hur mycket ”smutsig” cache som ska bildas innan kärnan skriver ut data. Jag föredrar *_bytes framför procent för att sätta definierade övre gränser – särskilt i konfigurationer med stort RAM-minne, där procenttal kan generera enorma skrivvågor. Mål: kontinuerlig, planerbar skrivning istället för sporadiska toppar som tillsammans med swap skapar I/O-låsningar. Jag övervakar iostat och writeback-köerna och håller värdena så att SSD/NVMe utnyttjas konstant, men inte köra över bli.
NUMA, Zone Reclaim och stora värdar
På system med NUMA spelar minneslokalitet en roll. Om vm.zone_reclaim_mode är aktiverat kan kärnan på ett mer aggressivt sätt återvinna minne på den lokala NUMA-noden, vilket oavsiktligt kan utlösa toppar i återvinningen. För många hosting-arbetsbelastningar inaktiverar jag Zone Reclaim och överlåter placeringen till schemaläggaren för att uppnå ett stabilare beteende. Dessutom kontrollerar jag Transparent Huge Pages (THP): Databaser reagerar ofta bättre på THP=never eller madvise, eftersom oplanerad defragmentering och THP-tilldelningar kan utlösa latensspikar. Swappiness kan vara perfekt – men om THP eller NUMA-policyer stör, förblir Hakkningar.
Finjusteringar av container- och cgroups-inställningar
Med Cgroups v2 har jag, förutom host-swappiness, ytterligare reglage: memory.high utlöser en mjuk återvinning, memory.max sätter hårda övre gränser och memory.swap.max begränsar swap per arbetsbelastning. På så sätt förhindrar jag att enskilda containrar bromsar ner värden genom swap. Jag ställer in låga Swappiness-värden på noden och ger kritiska arbetsbelastningar prioritet via memory.low, så att deras hotsets stannar kvar längre i RAM-minnet. I Kubernetes håller jag koll på hur noden hanterar swap och testar först ändringar i icke-produktionspooler. Det är viktigt att ha en helhetsbild: värdparametrar, Cgroup-gränser och orkestratorn måste stämma överens, annars flyttas belastningen bara från en nivå till andra.
Införande, automatisering och återfall
Jag rullar ut ändringar i Swappiness på samma kontrollerade sätt som alla andra prestandaoptimeringar: först på en liten grupp nästan identiska noder (Canary), sedan stegvis i större skala. Systemd-sysctl eller konfigurationshantering integrerar värdena på ett reproducerbart sätt. Jag dokumenterar start- och målvärden, tidpunkter, berörda värddatorer och Mätetal. För att hantera ett eventuellt återfall planerar jag i förväg en motåtgärd (t.ex. sysctl vm.swappiness=60) och sparar de tidigare sysctl-filerna. Under underhållsperioder mäter jag medvetet typiska belastningsscenarier för att inte förväxla förändringar med fluktuationer i tid på dygnet eller trafikvolym. Endast på så sätt förblir besluten tillförlitliga och inom teamet begriplig.
Vanliga missuppfattningar och antimönster
- „Swappiness=0 stänger av swap“: Nej, kärnan fortsätter att använda swap – men endast i mycket begränsad utsträckning.
- „Ju mer swap, desto säkrare“: För mycket swap förlänger belastningsperioder och döljer RAM-flaskhalsar istället för att lösa dem.
- „Med NVMe spelar swapping ingen roll“: NVMe är snabbt, men flera storleksordningar långsammare än RAM. Fördröjningarna är fortfarande märkbara.
- „Ett värde för alla servrar“: Arbetsbelastningarna varierar kraftigt. Utan mätningar blir optimeringen en slumpfråga.
- „Swappiness löser alla fördröjningar“: Problem beror ofta på cache-träffar, writeback, THP, frågeplaner eller nätverksvägar.
Sammanfattning för snabb start
Jag brukar ställa in vm.swappiness till 10–20 för webbservrar och till 0–10 för databaser, testar effekten och observerar I/O, latenser och Byta-andel. Det slutgiltiga värdet skriver jag in i /etc/sysctl.d/ via sysctl och ser till att ändringarna går att spåra. Samtidigt ser jag till att swap-layouten är väl avvägd: lämplig storlek, snabbt lagringsmedium, rimliga prioriteringar. När det gäller minnesbelastning håller jag dessutom koll på sidcachen och dess beteende; den här översikten ger en bra introduktion till Rensning av sidcache, som hjälper mig att analysera orsakerna och Sammanhang finns. Med denna metod uppnår jag tillförlitliga svarstider, förhindrar överbelastning av swap-minnet och utnyttjar det befintliga RAM-minnet effektivt.
