Heeft mijn VPS swap nodig en hoe groot moet dit zijn?

Heeft uw VPS swap nodig?

De meeste cloud-images worden geleverd zonder swap, en op een kleine VPS is het antwoord meestal ja: voeg een swap-bestand toe. Swap zorgt er niet voor dat een server met 1 GB RAM zich gedraagt als een server met 2 GB RAM. Het geeft de kernel een plek om inactieve anonieme pagina's op te slaan. Hierdoor blijft de page cache bruikbaar en wordt de OOM killer (out of memory killer, de kernel-routine die een proces kiest en beëindigt om geheugen vrij te maken) een laatste redmiddel in plaats van de eerste optie.

Kort gezegd: op een server die enkele langlopende services draait, is een klein swap-bestand de schijfruimte waard. Op een server waar één proces regelmatig probeert meer geheugen te alloceren dan de machine in totaal heeft, zal swap u niet redden; het maakt het falen alleen trager en moeilijker te detecteren. De rest van deze handleiding gaat over het onderscheid tussen deze twee scenario's en over de twee kostenposten die specifiek zijn voor een VPS.

Elk onderstaand commando vereist root-rechten op uw eigen server. Voer ze daarom daar uit in plaats van de output van de server van iemand anders te kopiëren.

Wat swap daadwerkelijk doet, en wat niet

Linux-geheugen bestaat in twee soorten. File-backed pages zijn kopieën van zaken die al op schijf staan: uw programma's en elk bestand dat u onlangs hebt gelezen. Deze verzameling vormt de page cache. Anonymous pages zijn geheugen zonder onderliggend bestand: heap en stack, plus het grootste deel van wat een database tijdens runtime toewijst.

Wanneer het geheugen tekortschiet, moet de kernel pagina's vrijmaken. Een schone file-backed page is goedkoop om vrij te maken, omdat de kopie op schijf nog bestaat en de pagina later opnieuw kan worden ingelezen. Een anonymous page is dat niet, omdat de enige kopie zich in het RAM bevindt. Zonder swap heeft de kernel twee keuzes voor anonymous memory: behouden, of het proces dat het bezit beëindigen.

Een server zonder swap voert nog steeds paging uit. Het voert alleen paging uit op het verkeerde geheugen. Onder druk verkleint de kernel de page cache, waarbij file pages worden verwijderd die kort daarna weer nodig zijn, inclusief de uitvoerbare code van de actieve programma's. Die pagina's komen terug als major page faults. U ziet schijfleesacties in de bi-kolom van vmstat en een stijgende pgmajfault-teller in /proc/vmstat, terwijl si en so de hele tijd op nul blijven staan. Het systeem is aan het thrashing en de swap-tellers rapporteren niets.

Wat swap niet doet, is capaciteit toevoegen. Als de working set, oftewel de pagina's die daadwerkelijk worden aangesproken, groter is dan het RAM, dan verandert swap een out-of-memory kill in een zeer trage server. Soms is dat de afweging die u wilt maken, omdat een trage server nog benaderbaar is voor reparatie, terwijl een beëindigde database dat niet is. Soms is het erger, omdat een trage server health checks blijft falen terwijl alle verbindingen open blijven staan. Bepaal wat u wilt voordat u swap toevoegt.

Waarom worden cloud-images geleverd zonder swap?

Dit is een bewuste keuze. Eén image moet op elk abonnement van een provider kunnen opstarten. Een vaste swap-partitie zou op kleine abonnementen schijfruimte verspillen en op grote abonnementen overbodig zijn. De snelheid van swap hangt bovendien af van de opslag onder de guest, wat de image vooraf niet kan weten. Daarnaast optimaliseren image-bouwers voor voorspelbaar gedrag; een proces dat direct stopt is eenvoudiger te diagnosticeren in een serverpark dan een machine die in de lucht blijft maar elk verzoek met seconden vertraging beantwoordt.

Deze redenen gelden voor wegwerpmachines. Een VPS die u behoudt is een ander verhaal. U repareert deze in plaats van hem te vervangen, dus een paar seconden paging is meestal te verkiezen boven een beëindigde service. Beschouw de ontbrekende swap als een standaardinstelling die is gemaakt voor de use-case van iemand anders.

Swapfile of swap-partitie op een VPS?

Gebruik een bestand. Een partitie vereist het wijzigen van de grootte van een actief root-bestandssysteem op een schijf die al gepartitioneerd is; dit brengt reële risico's met zich mee zonder voordeel. Een bestand wordt aangemaakt en verwijderd met standaardcommando's, en u kunt de grootte later aanpassen zonder de partitietabel te wijzigen.

Snelheid is niet de doorslaggevende factor. Tijdens swapon leest de kernel de extent-map van het bestand eenmalig en stuurt vervolgens I/O rechtstreeks naar het block device. Het bestandssysteem staat daardoor niet bij elke page-in of page-out in de weg. Op dezelfde schijf presteren een swapfile en een swap-partitie identiek.

Er zijn twee beperkingen om rekening mee te houden. Plaats swap niet op een netwerkbestandssysteem zoals NFS. Op btrfs moet copy-on-write zijn uitgeschakeld en compressie uitstaan; daarom levert btrfs een eigen hulpprogramma voor het aanmaken van een swapfile.

Een swap-bestand toevoegen op Ubuntu of Debian

Controleer wat er aanwezig is voordat u wijzigingen aanbrengt.

swapon --show
free -h
findmnt -no FSTYPE /

Een lege uitvoer van swapon --show betekent dat er helemaal geen swap is, wat de normale status is van een verse cloud-image. findmnt toont het type root-bestandssysteem, en dat bepaalt hoe u het bestand aanmaakt. Op ext4, wat de meeste cloud-images gebruiken, is fallocate veilig.

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

De chmod komt bewust vóór mkswap. Sla dit over en mkswap meldt u het volgende: mkswap: /swapfile: insecure permissions 0644, fix with: chmod 0600 /swapfile. Een swap-bestand dat voor iedereen leesbaar is, geeft elke gebruiker op de server toegang tot het geheugen dat andere processen hebben weggeschreven. Een correcte mkswap bevestigt vervolgens de grootte, met een regel zoals Setting up swapspace version 1, size = 2 GiB (2147479552 bytes).

Op xfs of btrfs kan het laatste commando falen met swapon: /swapfile: swapon failed: Invalid argument. Op XFS gebeurt dit omdat fallocate ongeschreven extents achterlaat; schrijf daarom de bytes direct.

sudo dd if=/dev/zero of=/swapfile bs=1M count=2048 status=progress

Op btrfs is de oorzaak copy-on-write, en de huidige btrfs-progs stelt de juiste vlaggen voor u in.

sudo btrfs filesystem mkswapfile --size 2g /swapfile

Hoe dan ook, rond af met chmod 600, mkswap waar van toepassing, en swapon, en bevestig daarna het resultaat.

swapon --show
free -h

swapon --show hoort /swapfile te tonen met type file en de door u gevraagde grootte, en free -h hoort een Swap-rij te tonen met vrijwel niets in gebruik. Nul swap in gebruik bij een verse installatie is correct. De kernel verplaatst alleen pagina's naar swap wanneer daar een reden voor is.

Zorg dat het bestand behouden blijft na een herstart en test de regel direct.

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
sudo swapoff /swapfile
sudo swapon -a
swapon --show

swapon -a leest /etc/fstab, dus een foutieve regel faalt direct, terwijl u meekijkt. Een typefout die u niet test, is een fout die u tegenkomt tijdens een ongeplande herstart, wanneer de server opstart zonder de swap waarvan u dacht dat deze aanwezig was.

Om swap later te verwijderen, voert u sudo swapoff /swapfile uit, verwijdert u de regel uit fstab en voert u daarna sudo rm /swapfile uit. swapoff moet eerst elke weggeschreven pagina teruglezen in het RAM-geheugen; op een zwaar belaste server kan dit daarom falen met swapoff: /swapfile: swapoff failed: Cannot allocate memory. Maak wat geheugen vrij en probeer het opnieuw.

Hoe groot moet het swap-bestand zijn?

De taak houdt koude anonieme pagina's vast, dus de relevante grootte is hoeveel van uw toegewezen geheugen daadwerkelijk inactief is, niet hoeveel RAM het plan heeft. Inactief geheugen groeit niet mee met de grootte van het plan, waardoor de vermenigvuldiger afneemt naarmate de plannen groter worden. Dit is de regel die deze handleiding hanteert.

[
  {
    "label": "1 GB plan",
    "swap_gb": 2,
    "swap_x_ram": 2
  },
  {
    "label": "2 GB plan",
    "swap_gb": 2,
    "swap_x_ram": 1
  },
  {
    "label": "4 GB plan",
    "swap_gb": 2,
    "swap_x_ram": 0.5
  },
  {
    "label": "8 GB plan",
    "swap_gb": 4,
    "swap_x_ram": 0.5
  },
  {
    "label": "16 GB plan",
    "swap_gb": 4,
    "swap_x_ram": 0.25
  }
]

Op het kleinste plan is dat 2 GB aan swap, wat 2 keer het RAM-geheugen is, omdat een server met 1 GB zo weinig speelruimte heeft dat één piek de OOM killer activeert. Aan de bovenkant van de tabel stopt het bestand bij 4 GB, of 0.25 keer het RAM-geheugen, omdat het swappen van zoveel data op gedeelde opslag zo lang duurt dat de server effectief onbereikbaar is terwijl dit gebeurt. Verlaag deze getallen als uw schijfruimte beperkt is, aangezien het bestand daadwerkelijk schijfruimte in beslag neemt.

De klassieke reden om swap gelijk aan of groter dan het RAM-geheugen in te stellen is slaapstand (hibernation), waarbij de volledige geheugeninhoud naar de swap wordt geschreven. Een VPS gaat niet in de slaapstand, dus die regel is niet op u van toepassing.

Wat verandert vm.swappiness daadwerkelijk?

vm.swappiness is geen percentage van het RAM-geheugen en het is geen drempelwaarde. Het is de relatieve kostenfactor die de kernel toekent aan het vrijmaken van anonieme pagina's in vergelijking met bestandspagina's. De standaardwaarde is 60. Verlaag deze waarde en de kernel geeft de voorkeur aan het verwijderen van de page cache. Verhoog deze waarde en de kernel geeft de voorkeur aan het verplaatsen van anoniem geheugen naar swap.

Dit is een afweging in beide richtingen. Bij vm.swappiness = 10 houdt een database meer van zijn toewijzingen in het geheugen vast, maar betaalt hiervoor door bestanden die zojuist uit de cache zijn verwijderd opnieuw in te lezen. Op een server die hoofdzakelijk bestanden serveert, is dit de verkeerde richting, omdat de page cache daar het nuttige werk verricht.

Het instellen op 0 schakelt swap niet uit. Het instrueert de kernel om anonieme reclaim te vermijden totdat het geheugen bijna op is, wat de OOM killer eerder activeert in plaats van uitstelt. Als u geen swap wilt, verwijder dan het swap-bestand.

sysctl vm.swappiness
printf 'vm.swappiness = 10\n' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system
sysctl vm.swappiness

Een kale sysctl -w blijft van kracht tot de volgende herstart en wordt daarna niet meer toegepast; schrijf het bestand daarom onder /etc/sysctl.d/. Kernels vanaf versie 5.8 accepteren waarden van 0 tot 200. Waarden boven 100 zijn alleen zinvol wanneer swap ongeveer even snel is als RAM, wat het geval is bij zram.

zram: swap die CPU kost in plaats van schijfruimte

zram is een gecomprimeerd block device dat zich in het RAM bevindt. Gebruik het als swap; een pagina die anders naar de schijf zou zijn geschreven, wordt gecomprimeerd en blijft in het geheugen. Er vindt geen disk I/O plaats en er wordt geen schijfquotum verbruikt. De kosten zijn CPU-tijd bij elke page-in en page-out, plus het RAM-geheugen dat de gecomprimeerde pagina's bevat en dat uw applicaties niet langer kunnen gebruiken.

Compressieratio's tussen 2:1 en 3:1 zijn de cijfers die doorgaans worden gerapporteerd voor anonieme pagina's. Uw eigen waarde wordt weergegeven door zramctl in de kolommen DATA en COMPR. Meet dit in plaats van uit te gaan van het gemiddelde, aangezien sommige workloads data bevatten die nauwelijks comprimeert.

sudo apt install zram-tools

Stel ALGO=zstd en PERCENT=25 in via /etc/default/zramswap, herstart vervolgens de service en controleer het resultaat.

sudo systemctl restart zramswap
zramctl
swapon --show

PERCENT is een percentage van het totale RAM-geheugen; een waarde van 25 op een systeem met 4 GB reserveert dus maximaal 1 GB voor gecomprimeerde pagina's. Begin met een lage waarde en verhoog deze alleen als zramctl laat zien dat het device volloopt. De instelling PRIORITY in hetzelfde bestand bepaalt welke swap de kernel als eerste vult: een hogere waarde krijgt voorrang. Een swapfile op schijf die met het standaard swapon is toegevoegd, krijgt een negatieve prioriteit, waardoor zram eerst wordt gebruikt en het bestand de overflow opvangt. swapon --show toont beide waarden in de kolom PRIO. Op distributies die systemd-zram-generator gebruiken in plaats van zram-tools, bevinden dezelfde instellingen zich in /etc/systemd/zram-generator.conf.

zram is geschikt voor een systeem met CPU-capaciteit over en weinig vrije schijfruimte. Het is de verkeerde keuze wanneer CPU-kracht de schaarse hulpbron is, omdat het compressieproces concurreert met de applicatie om dezelfde rekenkracht.

Twee swap-valkuilen die alleen op een VPS voorkomen

De eerste valkuil is schijfruimte. Een swap-bestand van 2 GB neemt direct 2 GB van uw abonnement in beslag zodra u het aanmaakt, omdat de ruimte vooraf moet worden toegewezen. df -h / daalt direct met dit volledige bedrag en herstelt pas weer als u het bestand verwijdert. Op een klein abonnement is dit een aanzienlijk deel, en een vol root-bestandssysteem veroorzaakt veel meer problemen dan swap ooit heeft opgelost. Het bestand telt ook mee in de uitvoer van du, wat belangrijk is om te onthouden wanneer u zoekt naar vrije ruimte en df en du geven verschillende resultaten over schijfgebruik.

De tweede valkuil is latentie. Uw swap-I/O gaat naar opslag die de host deelt met andere gasten, en u kunt hun belasting niet zien vanuit uw eigen gastomgeving. U ziet alleen het effect: een 'page-in' die normaal snel verloopt, duurt soms veel langer, en het proces dat hierop wacht, stopt totdat de pagina is geladen. Dit is dezelfde redenering als bij CPU steal time op een gedeelde host, maar dan toegepast op de schijfwachtrij in plaats van de run-wachtrij. Meet dit op uw eigen systeem, want elk gepubliceerd latentiecijfer beschrijft de situatie van andermans buren.

Hoe stelt u vast of swapping uw prestaties negatief beïnvloedt?

Gebruikte swap is geen probleem. Swap-verkeer wel. Een server met enkele honderden megabytes aan data in swap zonder paging-activiteit heeft simpelweg geheugen verplaatst dat urenlang niet is aangeraakt; dit is het gewenste resultaat.

Let op de snelheden in plaats van de totalen.

vmstat 1 5

si en so zijn kibibytes per seconde die worden geswapt (in en uit). Op een gezond systeem blijven deze waarden op of nabij nul, ongeacht wat de kolom swpd aangeeft. Aanhoudende so terwijl si tegelijkertijd stijgt, betekent dat pagina's worden weggeschreven en direct weer worden opgehaald; dit is thrashing.

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  3 1048572  38210   4096  61440  912 1180  2210  1290 1402 2890  9  7 12 72  0

Dit voorbeeld toont een systeem met problemen, en het duidelijkste signaal staat niet in de swap-kolommen. Het is wa op 72, wat betekent dat de CPU het grootste deel van de tijd wachtte op I/O, en b op 3, wat betekent dat drie processen geblokkeerd zijn.

PSI (pressure stall information) beantwoordt de vraag directer.

cat /proc/pressure/memory

some avg10=8.42 avg60=5.11 avg300=2.03 total=1284729
full avg10=3.10 avg60=1.94 avg300=0.71 total=498210

some avg10=8.42 betekent dat gedurende de laatste 10 seconden ten minste één taak 8,42 procent van de tijd stilstond in afwachting van geheugen. full telt de tijd waarin elke niet-inactieve taak stilstond; een aanhoudende full-waarde is dus meetbare schade in plaats van een waarschuwing. Als het bestand niet bestaat, heeft uw kernel PSI standaard uitgeschakeld en is psi=1 vereist in de kernel command line.

Om te zien welke processen pagina's in swap hebben staan:

sudo awk '/^Name:/{n=$2} /^VmSwap:/ && $2+0 > 0 {printf "%10d kB  %s\n", $2, n}' /proc/[0-9]*/status | sort -rn | head

En om te achterhalen of de OOM killer al actief is geweest:

sudo journalctl -k --grep "Out of memory"

Een treffer ziet eruit als Out of memory: Killed process 2199 (mysqld) total-vm:1275860kB, anon-rss:129252kB, file-rss:0kB, shmem-rss:0kB, UID:114 pgtables:504kB oom_score_adj:0, en het servicelogboek voor diezelfde seconde vermeldt Main process exited, code=killed, status=9/KILL. Als u deze regels heeft gezien op een systeem zonder swap, is het toevoegen van een swap-bestand de meest kostenefficiënte volgende stap.

Wanneer swap de verkeerde oplossing is

Swap biedt uitstel bij tijdelijke of inactieve geheugendruk. Het doet niets voor een proces dat blijft groeien totdat het crasht, en het maakt het lastiger om die fout te monitoren, omdat de machine de extra minuten besteedt aan paging in plaats van snel te falen en opnieuw op te starten.

Begrens het proces in plaats daarvan. Een systemd-service accepteert MemoryMax= en MemorySwapMax= in een drop-in-bestand; dit is de manier waarop u geheugen en CPU voor een service beperkt met systemd zonder de applicatie aan te passen. Containers hebben dezelfde instellingen één niveau hoger, en door deze in te stellen voorkomt u dat één Compose-service de hele server verbruikt. Beide methoden zorgen voor een beëindiging met een naam in een logboek dat u kunt terugvinden, in plaats van de kernel het slachtoffer te laten kiezen op basis van een score.

Voer dit uit terwijl de server nieuw en rustig is. Het aanmaken van het swap-bestand en het instellen van een geheugenlimiet kost enkele minuten, en dit hoort bij de rest van de werkzaamheden tijdens de eerste tien minuten op een nieuwe VPS.

FAQ

Zorgt het toevoegen van swap ervoor dat mijn 1 GB VPS zich gedraagt als een 2 GB VPS?

Nee. Swap is aanzienlijk trager dan RAM, en de kernel verplaatst alleen pagina's naar swap die als inactief worden beschouwd. Het biedt extra ruimte voor pieken en een plek om geheugen te parkeren dat is toegewezen maar niet wordt gebruikt. Als uw workload actief meer geheugen leest en schrijft dan de machine bezit, verandert swap een out-of-memory kill in constante paging. De server blijft dan weliswaar draaien, maar reageert te traag voor gebruik. Voeg in dat geval RAM toe of beperk het proces dat groeit.

Hoeveel swap heeft een 1 GB of 2 GB VPS nodig?

2 GB is voor beide voldoende; het is niet nodig om dit verder te schalen naarmate het RAM toeneemt. Swap bevat inactieve anonieme pagina's, en de hoeveelheid werkelijk inactief geheugen op een server groeit niet mee met de totale hoeveelheid RAM. De oude regel van twee keer de hoeveelheid RAM is afkomstig van slaapstand (hibernation), waarbij het volledige geheugenbeeld naar schijf wordt geschreven; een VPS gaat echter nooit in slaapstand. Meer dan 4 GB toewijzen leidt meestal alleen tot een langere en tragere uitval op opslag die u deelt met andere gasten.

Is het instellen van vm.swappiness op 0 de juiste manier om swappen te stoppen?

Nee, en het doet niet wat de naam suggereert. vm.swappiness = 0 schakelt swap niet uit. Het instrueert de kernel om het vrijmaken van anonieme pagina's te vermijden totdat het geheugen bijna op is, wat een OOM-kill eerder waarschijnlijker dan onwaarschijnlijker maakt. Het verplaatst bovendien alle reclaim-activiteit naar de page cache, waardoor bestandslezingen vaker terugvallen op de schijf. Als u helemaal geen swap wilt, voer dan sudo swapoff -a uit en verwijder de regel uit fstab. Als u minder wilt swappen, probeer dan vm.swappiness = 10 en vergelijk de kolommen si en so in vmstat voor en na de wijziging.

Moet ik zram gebruiken in plaats van een swap-bestand?

Gebruik zram wanneer u CPU-capaciteit over heeft en weinig schijfruimte, en gebruik een swap-bestand wanneer het omgekeerde waar is. zram comprimeert pagina's en houdt deze in het RAM, waardoor disk-I/O volledig wordt vermeden. Dit kost echter CPU-kracht bij elke lees- en schrijfactie, en de ruimte die het inneemt is RAM dat niet langer beschikbaar is voor applicaties. Op een VPS met een beperkt CPU-budget legt dit beslag op de resource waar u al een tekort aan heeft. Het is gebruikelijk om beide te draaien: geef zram een hogere prioriteit met PRIORITY in /etc/default/zramswap en houd een swap-bestand op schijf als reserve voor overloop.

Waarom werd de OOM-killer geactiveerd terwijl free aangaf dat er geheugen beschikbaar was?

free rapporteert een momentopname, terwijl een geheugentoewijzing in een fractie van een seconde plaatsvindt. Een proces dat sneller om een groot blok geheugen vraagt dan het systeem kan vrijmaken, wordt beëindigd, zelfs als het gemiddelde verbruik er acceptabel uitzag. Lees het kernel-logboek met sudo journalctl -k --grep "Out of memory"; hierin staat welk proces is beëindigd en wat de resident size op dat moment was. Controleer vervolgens of de beëindiging werd veroorzaakt door een cgroup-limiet in plaats van door de gehele machine, aangezien een container of een systemd-unit met een ingestelde MemoryMax= wordt beëindigd bij het bereiken van de eigen limiet, terwijl de host nog vrij geheugen heeft.