Överbelastad grenkontakt på mörk betongvägg med flera kablar som konkurrerar om samma uttag, dramatisk sidbelysning
Guider

CPU steal time: den dolda mätaren som avslöjar om din VPS är översåld

Din VPS delar fortfarande hårdvara med grannar

En VPS säljs ofta med budskapet att du äntligen lämnar den delade hostingens kaos bakom dig. Du får egna resurser, eget minne, eget utrymme. Det stämmer delvis. RAM:et är hårdvarureserverat i de flesta moderna virtualiseringsplattformar, men vCPU:erna delar ändå fysiska kärnor med alla andra virtuella maskiner på samma server. Hur väl hypervisorn fördelar den resursen avgör om din VPS presterar som den borde.

Det är här CPU steal time (på svenska ungefär "stulen processortid") kommer in. Måttet är enkelt. Det visar hur stor andel av tiden din virtuella CPU var redo att köra kod, men hypervisorn valde att schemalägga någon annans VM istället. Ju högre siffra, desto mer tid väntar din server i kön medan grannen tar CPU:n. Det är ett direkt mått på kontention och, i förlängningen, på hur hårt din leverantör har översålt den fysiska servern.

Märk att steal inte mäter att din VM slösar tid. Det mäter tid som nekades din VM. Det är en avgörande distinktion. Steal är leverantörens problem, inte ditt.

Diagram som visar hur tre virtuella maskiners vCPU:er delar en fysisk CPU-kärna. Hypervisorns schemaläggare avgör vem som får köra, och tidslinjen längst ner visar tidsskivor där den egna VM:en väntar, vilket registreras som steal time i verktyg som top och vmstat.
Steal syns som randiga väntskivor i tidslinjen, tiden din VM nekades, inte tid den själv slösade bort.

Så mäter du steal time på 30 sekunder

Alla Linuxbaserade VPS:er exponerar steal-värdet via kärnan. Du behöver ingen extrainstallation, inga agenter, inga plugins. De vanligaste verktygen räcker.

top ger snabbaste överblicken

Kör top i din terminal. På den andra raden (som börjar med %Cpu(s):) syns ett antal procentsatser. Leta efter kolumnen märkt st. Det är din steal time just nu.

%Cpu(s):  4.2 us,  1.1 sy,  0.0 ni, 92.1 id,  0.3 wa,  0.0 hi,  0.8 si,  1.5 st

Värdet uppdateras löpande. Om du vill se det under last, kör något CPU-intensivt i ett parallellt fönster (till exempel en komprimeringssats) och titta hur st förändras när servern arbetar på riktigt.

vmstat visar historik per sekund

vmstat 1 skriver ut en ny rad varje sekund. Den sista kolumnen heter st och visar steal för den gångna sekunden. Kör det i ett par minuter under normalt trafikflöde och notera variationen. En stabil nolla eller ettare är bra. Plötsliga hopp till 15 till 25 procent under belastningstoppar är ett varningstecken.

vmstat 1 60

Vill du spara resultatet för att jämföra vid ett annat tillfälle, pipar du enkelt till en fil.

vmstat 1 300 >> steal-log.txt

sar och mpstat för djupare analys

Har du sysstat-paketet installerat (apt install sysstat på Debian eller Ubuntu) öppnar sig sar och mpstat. Med sar -u 5 12 mäter du CPU-användningen i 12 intervaller om 5 sekunder, och med mpstat -P ALL 1 ser du steal per kärna. Det är användbart om du misstänker att en specifik vCPU är mer drabbad än andra, vilket kan hända på servrar med ojämn schemaläggning.

Red Hat och opensource.com ger en bra teknisk bakgrund om du vill förstå hur hypervisorn rapporterar värdet till gästkärnan.

Vad siffran faktiskt betyder

Steal time är ett procentvärde och ska läsas i sitt sammanhang. Här är tumreglerna vi lutar oss mot, och de stämmer väl med vad oberoende genomgångar som Scout APM redovisar.

Steal timeBedömning
Under 5 %Normalt. Liten eller ingen påverkan.
5–10 %Märkbar kontention. Bevaka trenden, agera inte än.
10–20 %Tydlig seghet. Din VPS levererar sannolikt under sina specifikationer.
Över 20 %Allvarlig översäljning. Kontakta leverantören eller byt server.

Den viktigaste tumregeln är tidsdimensionen. Steal över 10 procent under ungefär 20 minuter är ett tydligt tecken på att din VPS körs långsammare än den borde. Det är inte ett tillfälligt utbrott utan ett strukturellt problem med hur servern är konfigurerad.

Korrelationen är nyckeln. Stiger st samtidigt som din webbplats svarar trögt och laddningstiderna ökar? Då är det steal, inte din kod. Om steal däremot är noll men sajten ändå är seg, leta istället på I/O-wait (wa-kolumnen) eller i din applikationskod. Vår guide om att felsöka en seg VPS går igenom de andra vanliga orsakerna.

KVM garanterar inte att du är skyddad

En vanlig missuppfattning är att KVM-baserade VPS:er automatiskt är välskyddade mot steal. Det är en halvsanning. KVM är ett robust hypervisor-lager som hanterar minnesisolering i hårdvara, och det är klart överlägset äldre containerbaserade lösningar som OpenVZ där minne och processer delar kärna på ett mjukare sätt.

Men vCPU:er är en annan sak. Även i KVM schemaläggs de virtuella processorkärnorna via Linuxkärnans CFS (Completely Fair Scheduler). Om leverantören packar 80 vCPU:er på en server med 16 fysiska kärnor, konkurrerar alla 80 om samma resurser. KVM hindrar inte det. Det är affärslogik, inte teknik, som styr hur tätt en server befolkas.

Resultatet är vad som brukar kallas noisy neighbor, en stökig granne. Grannen på samma fysiska server kan inte bara ta CPU-cykler från dig, utan de intensiva accesserna kan även spola din data ur processorns cache (L2 och L3). Nästa gång din process körs måste den hämta data från RAM igen, vilket är tiotals gånger långsammare. Det syns inte i steal-siffran, men det påverkar din faktiska genomströmning. Samma delade-hårdvara-logik gäller lagringen, och där slår begränsningen ännu mer abrupt. Vi går igenom det i genomgången av disk-I/O-tak på VPS.

Vad "dedikerade vCPU:er" faktiskt innebär

Många leverantörer marknadsför VPS-planer med "dedikerade vCPU:er" som en premiumfunktion. Det är ett ord som förtjänar att granskas. I bästa fall innebär det att varje vCPU mappas exklusivt mot en fysisk kärnhalva via CPU-pinning i hypervisorn, och att leverantören säljer färre vCPU:er per fysisk kärna än konkurrenterna. I sämsta fall är det ett marknadsföringsuttryck utan teknisk täckning.

Det enda sättet att verifiera är att mäta. En VPS med "dedikerade" vCPU:er som visar 15 procent steal under normaltrafik levererar inte vad etiketten lovar.

Testa en VPS innan du binder dig

Det bästa du kan göra när du utvärderar en ny VPS-leverantör är att faktiskt starta en testserver och mäta steal under last. Det tar under en timme och kostar i regel en handfull kronor. Här är ett enkelt testprotokoll.

  1. Starta en VPS på det plan du funderar på att köpa.
  2. Öppna vmstat 1 i ett terminalfönster och låt det rulla.
  3. Kör en CPU-intensiv last i ett annat fönster. Ett enkelt sätt är stress --cpu 2 --timeout 120 (kräver paketet stress).
  4. Notera steal-kolumnen under och efter belastningstestet.
  5. Låt vmstat rulla ytterligare 10 till 15 minuter under normal last och se om steal-värdet håller sig stabilt.

Gör testet vid olika tidpunkter på dygnet. Steal är sällan konstant. Det varierar med hur många grannar som är aktiva. Mitt i natten kan en översåld server se utmärkt ut, men under kontorstid kan bilden vara en helt annan.

Visar testet steal stabilt under 5 procent även under last är det ett gott tecken. Visar det 10 till 15 procent under ditt eget belastningstest, utan att du ens vet hur många grannar som är igång parallellt, är det ett rött flagg.

Svensk kontext: vad du kan förvänta dig av olika leverantörstyper

Vi pekar inte ut specifika leverantörer utan egna mätdata att stå på. Men det finns ett generellt mönster som håller. Leverantörer som äger sin egen hårdvara och driver egna datacenter har ett starkare incitament att inte översälja, eftersom de bär kostnaden för kunders klagomål och avhopp direkt. Aktörer som återsäljer kapacitet från ett mellanlager kan ha sämre insyn i hur tätt varje fysisk server är packad. Det är ett av skälen till att vi generellt lyfter fram svenska VPS-leverantörer med egna datacenter.

Det är inte en regel utan undantag. En liten leverantör med egna servrar kan översälja precis lika hårt om marginalerna pressas. Men det är en rimlig startpunkt när du bedömer trovärdigheten i ett VPS-erbjudande. Steal time-testet ersätter dessutom alla spekulationer med hårda siffror.

Om steal-mätningen visar rött

Hittar du konsekvent hög steal har du i praktiken tre vägar framåt. Den första är att kontakta leverantören och be dem migrera din VM till en mindre belastad fysisk server. En seriös leverantör gör det utan krångel. Den andra är att uppgradera till ett plan med färre vCPU:er men på en dedikerad maskin, om leverantören erbjuder det. Den tredje är att byta leverantör och ta med dig lärdomen om att mäta steal innan nästa kontrakt tecknas.

Vad du inte ska göra är att lägga mer pengar på ett dyrare delat plan i hopp om att siffran förbättras. Steal beror på hur servern är packad, inte på ditt plans nominella resursnivå. Att uppgradera från 2 vCPU till 4 vCPU hos samma leverantör, på samma typ av server, löser sällan problemet om grundorsaken är översäljning.