Disk-I/O på VPS: varför lagringen faller av en klippa trots NVMe
Din VPS känns snabb de första timmarna. Sedan, under en längre databas-migrering eller ett plötsligt trafikberg, segnar allt. Lagringen svarar inte som förut. Det är inte ett nätverksproblem och det är inte ett minnesproblem. Det är disk-throttling, och det beter sig inte som de flesta andra prestandaproblem på delade plattformar.
CPU-stöld (på engelska CPU steal) är gradvis och skvalpande. Du tappar några procent här och där, och beteendet är relativt förutsägbart. Disk-I/O-begränsning är annorlunda. Den faller av en klippa. Full fart, full fart, full fart, sedan ingenting. Eller rättare sagt, en bråkdel av det du hade. Det är den bärande mekanismen den här artikeln handlar om, och den avgör vilket VPS-paket som faktiskt håller under last.
Burst-kreditsystemet och prestandaklippan
Det vanligaste sättet att förstå disk-throttling på molnplattformar är att titta på AWS egna dokumentation för EBS gp2-volymer. Amazon Web Services bygger sitt äldre gp2-format på en burst-kreditmodell. Volymen samlar på sig I/O-krediter när den inte används hårt, och får tömma dem under korta intensiva perioder.
En typisk gp2-volym startar med ungefär 5,4 miljoner I/O-krediter i sin pott. Det räcker till runt 30 minuter på 3 000 IOPS (in-/utmatning per sekund). Medan krediterna finns ger disken bra prestanda. Men när potten är tömd begränsas volymen till baslinjen, som är storleksberoende och kan landa på några hundra IOPS för en liten volym. Latensen (väntetiden på disk) skjuter i höjden. Inte gradvis, utan som ett trappsteg nedåt.
Det är exakt det mönstret vi känner igen. Disk snabb första timmen, sedan segnar under uthållig last. Klassiskt burst-symptom.
AWS officiella dokumentation för EBS gp2 och gp3 beskriver mekaniken i detalj. Värt att läsa om du kör på AWS eller om du vill förstå hur liknande system kan se ut hos andra hyperscalers. Blue Matador har också en bra genomgång av hur EBS Burst Balance fungerar i praktiken, med konkreta exempel på vad som händer när balansen tar slut.
Nyare volymstyper som gp3 slopar burst-modellen och levererar istället ett fast IOPS-värde uthålligt. Det är en grundläggande arkitekturskillnad, inte bara en uppgradering. Med gp3 vet du vad du köper.
NVMe på prislappen är inte alltid NVMe i din VM
Att en VPS-leverantör skriver "NVMe-lagring" i sitt marknadsföringsmaterial säger ganska lite om den faktiska prestandan din VM ser. Tekniken kan se ut på flera olika sätt, med stor skillnad i vad du faktiskt får.
Lokal NVMe kontra nätverksansluten lagring
Det bästa scenariot är lokal NVMe direkt på den fysiska noden din VM kör på. Låg densitet, korta svarstider, ingen nätverkslänk mellan CPU och lagringen. Det är vad många mindre leverantörer och aktörer med egna datacenter kan erbjuda.
Det vanligare scenariot i stor skala är nätverksansluten NVMe-lagring (exempelvis SAN eller distribuerade lagringssystem). Hårdvaran är fortfarande NVMe, men det är NVMe-enheter bakom en nätverksfabrik med hög densitet. Latensen per operation är högre, och IOPS-taket delas mellan fler virtuella maskiner på nätverket.
Båda kallas "NVMe" i marknadsföringen. Skillnaden i praktiken kan vara en faktor 3 till 5 i latens vid låg belastning, och mer vid hög.
Virtualiseringsskiktet lägger på latens
Ovanpå hårdvarans egna egenskaper lägger virtualiseringen ett extra lager. KVM med virtio-blk eller virtio-scsi (de vanligaste I/O-drivrutinerna i Linux-baserade VPS-miljöer) introducerar ungefär 10 till 30 μs extra latens per I/O-operation jämfört med att köra direkt mot hårdvaran. Det låter litet, men vid tusentals operationer per sekund summerar det.
Det går inte att komma runt det faktum att en VPS-disk är delad hårdvara, precis som en delad CPU. Virtualiseringsskiktet existerar och kostar latens. Det är inte ett problem i sig, men det är bakgrunden man behöver ha i huvudet när man läser prestandasiffror i ett säljblad.
Tre tal, ett marknadsförs
Det finns tre dimensioner av diskprestanda som spelar roll för en riktig applikation. IOPS (in-/utmatning per sekund), latens (väntetiden per operation) och genomströmning (diskgenomströmning i MB/s). Leverantörer marknadsför nästan uteslutande IOPS-siffror, och de mäts på ett sätt som är generöst mot dem.
| Dimension | Vad det mäter | Hur det mäts i marknadsföring | Hur din app använder det |
|---|---|---|---|
| IOPS | Antal I/O-operationer per sekund | Syntetiskt test, ködjup 32 eller högre | Ködjup 1 till 2, sällan mer |
| Latens | Tid per enskild operation | Sällan nämnd | Avgörande för hur appen känns |
| Genomströmning | MB/s vid sekventiell läsning | Nämns ibland för NVMe-känsla | Viktigt för stora filer, ej för databaser |
"100 000 IOPS" i ett säljblad är mätt vid ködjup 32 eller högre, alltså med 32 parallella I/O-operationer i kö. En webbapplikation, ett WordPress-system eller en PostgreSQL-databas kör typiskt ködjup 1 till 2. Den väntar på att varje operation ska bli klar innan nästa skickas.
Vid ködjup 1 är latensen per operation det som avgör hur snabbt det faktiskt känns. Det är latensen användaren upplever, det är latensen som avgör om din databas svarar på 2 ms eller 20 ms. IOPS är vad marknadsföringen säljer.
Det betyder inte att IOPS är irrelevant. Vid hög parallell last, som batch-jobb eller backup, spelar IOPS-taken roll. Men för interaktiva applikationer är p99.9-latensen (99,9-percentilen av svarstider) ett ärligare mått på hur lagringen beter sig i verkligheten.
Vad du faktiskt bör mäta
Om du vill bilda dig en ärlig uppfattning om VPS-diskens prestanda innan du binder dig, finns det ett enkelt verktyg. fio (Flexible I/O Tester) låter dig specificera ködjup och mätperiod exakt. Kör ett test med ködjup 1 och mät latensen, inte IOPS-toppen. Titta på p99.9-latensen i resultatet, inte snittet.
fio:s officiella dokumentation förklarar hur du konfigurerar jobfiles och vilka mätvärden som är relevanta. Det är det ärliga måttet på vad din applikation faktiskt kommer att uppleva.
Om din disk är seg just nu och du vill diagnosticera det steg för steg har vi en separat guide om att felsöka en seg VPS med iostat, iotop och liknande verktyg. Det är en annan uppgift än att välja rätt VPS från början.
Europeisk och svensk kontext
Burst-kreditmodellen är i grunden en hyperscaler-företeelse. AWS, Azure och Google Cloud har byggt sina lagringssystem med burst-mekanismer, delvis för att det tillåter hög densitet och bättre resursutnyttjande över en stor flotta av kunder.
Många svenska och europeiska VPS-leverantörer, särskilt de med egna datacenter och hårdvara, väljer en annan modell. Istället för burst-krediter sätter de ett fast IOPS-tak per instans. Det taket är lägre än burst-topparna hos en hyperscaler, men det är förutsägbart. Ingen klippa. Du vet exakt vad du betalar för och vad du får.
Förutsägbarhet har ett värde som sällan syns i jämförelsetabeller. En VPS med 5 000 IOPS uthålligt är för de flesta applikationer mer värdefull än en med "upp till 16 000 IOPS burst" som kraschar ner till 500 IOPS efter 20 minuter av last.
Aktörer med lokal NVMe direkt på noden, utan nätverksfabrik emellan, tenderar att ge lägre och mer konsekvent latens. Det är inte alltid billigare, men det är ofta mer ärlig hårdvara för priset.
Vad du bör fråga leverantören
Innan du väljer VPS-plan är det tre frågor som skapar klarhet om diskprestandan.
- Är IOPS-taket uthålligt eller burst-baserat? Vad är baslinjen efter burst?
- Är lagringen lokal NVMe på noden, eller nätverksansluten (SAN, distribuerad lagring)?
- Vilket I/O-gränssnitt används i virtualiseringen, virtio-blk eller virtio-scsi?
En leverantör som svarar tydligt på de frågorna vet vad de säljer. Om svaret är vagt, eller om frågan om burst kontra uthållig prestanda möts med tystnad, är det i sig ett svar.
Disk-I/O-prestanda på en VPS är inte mystisk. Den är delad hårdvara med gränser, precis som allt annat i molnet. Skillnaden är att gränserna är binära på ett sätt som CPU-steal aldrig är. Vet du vilka gränser du köper, och har du mätt latensen vid ködjup 1, köper du rätt.