CPU:s IPC och klockfrekvens: Hur man jämför webbhotellsprocessorer på rätt sätt

CPU IPC: Instruktioner per takt

CPU IPC står för Instructions per Cycle, det vill säga instruktioner per taktcykel. För ett avgränsat mätintervall divideras vanligtvis antalet avslutade maskininstruktioner med antalet CPU-cykler som räknats inom samma intervall. Ett IPC-värde på 2 innebär i detta sammanhang i genomsnitt två avslutade instruktioner per räknad cykel.

Värdet är ett Utförandets egenskaper, inte ett fast mått för alla uppgifter som en processor utför. Samma system kan uppnå ett annat IPC-värde vid en beräkning med lättillgängliga data än vid en databasfråga, som ofta måste vänta på data från huvudminnet. Även den aktuella datamängden och den programdel som beaktas påverkar resultatet.

En cache lagrar ofta använda data nära processorn. Om en kärna istället måste vänta på långsammare minnesåtkomst kan exekveringsenheterna tillfälligt stå oanvända. På samma sätt påverkar beroenden mellan instruktioner och förgreningar i programflödet hur mycket arbete som kan utföras samtidigt. Ett lågt IPC-värde är därför en anledning till vidare undersökning, men ännu ingen entydig diagnos.

En maskininstruktion är dessutom ingen standardiserad enhet för en avslutad webbförfrågan. Kompilator, instruktionsuppsättning och vektorisering kan leda till att olika program behöver olika många instruktioner för samma uppgift. En högre IPC i sig bevisar därför varken en kortare svarstid eller fler förfrågningar per sekund.

För att kunna göra en jämförelse är det avgörande vilken applikation och vilket mätområde som ligger till grund för värdet. Ett IPC-värde utan dessa uppgifter lämnar det oklart om systemen överhuvudtaget utför samma arbete. Mer grundläggande information om samspelet mellan klockfrekvens, kärnor och minneshierarki hittar du i artikeln om CPU-arkitektur inom webbhotell.

Att förstå serverns klockfrekvens och boost

Klockfrekvensen anger hur många cykler en CPU genomgår per sekund. En gigahertz, förkortat GHz, motsvarar en miljard cykler per sekund. Värdet i sig säger dock ingenting om hur många instruktioner ett program hinner utföra under dessa cykler eller hur mycket användbart arbete det utför med dem.

I datablad anges ofta en Grundfrekvens och en maximal boost. Basfrekvensen fungerar som ett specifikationsvärde; boost avser en högre möjlig frekvens under lämpliga förhållanden. Ingen av dessa uppgifter ersätter en observation av den faktiskt uppnådda klockfrekvensen under den konkreta användningen och vid respektive belastning.

Ett exempel är AMD EPYC 9655: För denna modell anger AMD 96 kärnor, 192 trådar, en basklockfrekvens på 2,6 GHz och en maximal boost på upp till 4,5 GHz. Dessa värden beskriver processorns specifikationer och frekvens. De utgör varken ett uppmätt IPC-värde eller ett bevis på en viss hosting-genomströmning.

För EPYC-9005-serien definierar AMD maximal boost som den högsta frekvensen som en enskild kärna kan uppnå under normala driftsförhållanden för servern. De upp till 4,5 GHz som 9655 uppnår är alltså ingen garanti för att alla 96 kärnor kan hålla denna klockfrekvens kontinuerligt. Prestanda- och temperaturgränser påverkar beteendet under belastning.

För en kortvarig enskild uppgift kan en tillfälligt högre klockfrekvens vara relevant; vid en långvarig parallell belastning är det däremot intressant att se vilken prestanda systemet levererar under hela drifttiden. Andra modeller i serien har andra frekvenser och antal kärnor. En jämförelse som enbart baseras på det högsta GHz-värdet skulle bortse från dessa skillnader och den konkreta tillämpningen.

Kärnor, trådar och virtuella processorer

En process är, förenklat uttryckt, en pågående programinstans. I den utför en eller flera trådar instruktioner. En fysisk CPU-kärna har den hårdvara som krävs för att utföra sådant arbete; beroende på processor ser operativsystemen en eller flera logiska CPU-trådar per kärna. Logiska trådar i samma kärna delar därvid delar av dess hårdvara.

En uppgift med en starkt seriell del kan inte fördelas godtyckligt på flera kärnor. I det fallet är det avgörande hur snabbt den körande tråden utför det konkreta arbetet. Oberoende webbförfrågningar kan däremot ofta bearbetas parallellt: då kan ytterligare tillgängliga kärnor bidra till den totala genomströmningen, förutsatt att inga andra resurser utgör en begränsning.

Antalet logiska trådar är inte detsamma som antalet oberoende fysiska kärnor. EPYC 9655 har till exempel 96 fysiska kärnor och 192 trådar enligt tillverkaren. De 192 trådarna innebär varken en fördubbling av prestandan jämfört med 96 trådar eller en viss genomströmning för en webbserver.

När det gäller en virtuell server tillhandahåller leverantören gästoperativsystemet vCPU:er klar. En vCPU är inte automatiskt en fysisk kärna som kan användas exklusivt: hur den tilldelas värdmaskinens hårdvara kan variera beroende på erbjudandet, och beräkningstiden kan delas med andra gäster eller begränsas genom begränsningar.

Fråga innan valet av konkret resurs: Är CPU-tid garanterad eller delas den? Finns det permanenta prestandabegränsningar och hur tilldelas vCPU:er? Ett stort antal vCPU:er hjälper en parallell applikation endast i den mån det faktiskt finns tillräckligt med beräkningstid tillgänglig; för en seriell del ersätter det inte snabb exekvering på en tråd.

Beräkna IPC och klockfrekvens tillsammans

IPC och klockfrekvens beskriver olika aspekter av CPU:ns prestanda. För ett lämpligt avgränsat mätområde kan deras inverkan approximativt sammanföras: Instruktioner per sekund motsvarar IPC multiplicerat med det effektiva antalet CPU-cykler per sekund. IPC avser här de utförda instruktionerna och de räknade cyklerna inom samma tidsintervall.

Illustrativt räkneexempel, ingen mätning: Om man antar en konstant värde på 2,0 instruktioner per cykel och 3,0 GHz blir det enligt beräkningen 6,0 miljarder instruktioner per sekund. Även 1,5 IPC vid 4,0 GHz ger 6,0 miljarder. I detta exempel kompenserar alltså den högre klockfrekvensen för den lägre IPC:n i beräkningen.

Att instruktionsfrekvenserna är desamma innebär dock inte att de båda systemen bearbetar lika många webbförfrågningar. För samma uppgift kan program behöva olika många instruktioner beroende på kompilator, instruktionsuppsättning och vilka instruktioner som används. En instruktion motsvarar därför inte en enhetlig mängd utfört applikationsarbete.

Inte heller en webbplats svarstid framgår direkt av produkten. En tråd kan vänta på data från lagringsmediet eller på ett nätverkssvar; under tiden förklarar dess instruktionshastighet inte hela den tid som förflutit. När det gäller en virtuell maskin tillkommer dessutom att den inte nödvändigtvis får tillgång till CPU-tid hela tiden.

För att kunna göra en jämförelse måste det därför framgå vilken kod och vilken tidsperiod som har beaktats. Formeln hjälper till att klassificera den aktiva körningen; för beslutet om webbhotell krävs dessutom avslutade uppgifter och deras svarstider inom ramen för en jämförbar förfrågningsprofil.

Klassificera datablad och nyckeltal

Ett datablad ger användbara ledtrådar för valet av en CPU för webbhotell. Uppgifterna besvarar dock olika frågor: IPC beskriver ett beteende inom respektive mätområde, medan frekvensuppgifter och antal kärnor däremot specificerar egenskaper hos en processormodell. Först i kombination med applikationen blir dessa uppgifter användbara jämförelsekriterier.

EPYC 9655 visar hur sådana uppgifter hänger ihop: Enligt AMD har modellen 96 kärnor och 192 trådar, en basklockfrekvens på 2,6 GHz och en maximal boost på upp till 4,5 GHz. De 4,5 GHz är inte en garanterad klockfrekvens för alla kärnor under kontinuerlig belastning och inte heller en uppmätt hosting-genomströmning.

En rangordning baserad på högsta GHz-värde skulle dölja hur mycket arbete olika processorer utför per cykel och per uppgift. En rangordning baserad på antalet kärnor bortser däremot från att inte alla applikationer kan fördela sitt arbete lika bra parallellt. Båda uppgifterna är utgångspunkter, inte färdiga bedömningar av prestanda.

Var därför uppmärksam på följande när det gäller erbjudanden: Modellvariant och på vilka resurser som faktiskt kan utnyttjas. För att kunna göra en tillförlitlig jämförelse behöver du dessutom en lämplig belastningsprofil och resultat från jämförbar programvara och konfiguration. Specifikationer för olika modeller bör inte blandas ihop med ett maximivärde som antas gälla för hela produktfamiljen.

Välj hosting-CPU utifrån belastningsprofil

Vilken processor som är lämplig för webbhotell beror på vad servern ska utföra. En lång enskild uppgift ställer andra krav än många oberoende webbförfrågningar. Tabellen översätter typiska belastningsprofiler till ett prioriterat mått och en fråga som bör klargöras innan valet görs.

Vid en enskild uppgift är prestandan hos den tråd som utför uppgiften särskilt viktig om en större del av arbetet sker seriellt. Fler kärnor förkortar inte automatiskt denna del. En kort maximal prestandaförbättring räcker inte heller som bevis för en långvarig uppgift: det avgörande är den uppmätta körtiden under de avsedda förhållandena.

Däremot kan många oberoende förfrågningar bearbetas parallellt. Här spelar inte bara prestandan per tråd någon roll, utan också hur många resurser som är tillgängliga samtidigt och hur svarstiderna utvecklas när belastningen ökar. Summan av de nominella GHz-värdena ersätter inte en jämförelse av Total genomströmning vid samma parallellitet.

I en databas med stora arbetsdatauppsättningar kan minnesåtkomst bromsa körningen om nödvändiga data inte hämtas effektivt från cacheminnena. Ett lågt IPC-värde kan vara anledning till vidare undersökningar, men bevisar inte i sig att det föreligger en minnesflaskhals. Kontrollera därför även frågorna, datamängden och minneskonfigurationen innan du byter ut processorn.

När det gäller VPS tillkommer dessutom Resursåtagande Viktigt: En vCPU är inte automatiskt en exklusiv fysisk kärna. Undersök tilldelningen, eventuella CPU-begränsningar och hur resurserna delas med andra gäster. Först med dessa uppgifter går det att på ett meningsfullt sätt jämföra ett applikationstest med ett erbjudande på en dedikerad server.

Planera jämförande användningstester

En meningsfull jämförelse utgår från din applikation, inte från ett isolerat CPU-värde. Ange samma programvaruversion, samma datamängd och samma konfiguration för båda webbhotellserbjudandena. SPEC betecknar den egna applikationen på den egna infrastrukturen som den ideala måttstocken för produktvalet.

Definiera sedan en Förfrågningsprofil, som så väl som möjligt återspeglar den framtida användningen: till exempel vilka sidor eller API-ändpunkter som anropas och hur många förfrågningar som kommer in samtidigt. Se till att parallelliteten och resursbegränsningarna är jämförbara mellan de olika körningarna. Om ett erbjudande anger andra gränsvärden, dokumentera dem uttryckligen istället för att enbart tillskriva skillnaden till CPU:n.

Planera in en uppvärmningsfas så att till exempel applikationen hinner starta och cacheminnena hinner fyllas. Därefter hjälper flera tillräckligt långa körningar till att skilja ut kortvariga fluktuationer från en återkommande skillnad. Dokumentera även om andra uppgifter kördes på systemen under mätningen.

Registrera, förutom genomströmningen, även Fördelning av svarstider och felen. Ett högre genomsnittligt antal avslutade förfrågningar per sekund är i sig inte särskilt meningsfullt om enskilda förfrågningar får vänta mycket länge eller ofta misslyckas. Jämför därför även höga percentiler för svarstiden vid samma parallellitetsgrad.

Publicerade SPEC-CPU2017-resultat kan ge ytterligare vägledning. SPECspeed mäter den tid som krävs för att utföra uppgifter, medan SPECrate mäter genomströmningen; de två måtten är inte direkt utbytbara med varandra. Jämför resultat för samma mått och beakta systemkonfigurationen och programvaran. CPU-sviten återspeglar inte nätverket och I/O för en komplett värdtjänst.

Kontrollera IPC och frekvens under drift

För att skapa en egen Linux-testmiljö kan du använda perf för att registrera de avslutade instruktionerna och cyklerna i ett befintligt, testat program. I följande exempel är testprogramm En platshållare: Ersätt den med ditt testprogram och, om nödvändigt, dess argument. Kommandot är ett förslag på hur man kan mäta, inte ett redan utfört test.

perf stat -e '{instructions,cycles}' -- testprogramm

De krökta parenteserna sammanfattar händelserna till en Mätargrupp tillsammans. De ska registreras samtidigt, vilket kan minska fel som uppstår vid tidsförskjuten multiplexering. Dela antalet räknade instruktioner med antalet räknade cykler för att få fram IPC för detta mätintervall; perf kan även visa detta värde direkt.

Om händelserna är tillgängliga och får läsas beror på hårdvara, kärna, behörigheter och, i förekommande fall, virtualiseringsmiljön. En händelsegrupp som inte är tillgänglig eller inte kan räknas samman ger ingen tillförlitlig jämförelse. Ändra inte säkerhetsinställningarna enbart för detta exempel.

Även en frekvensindikator behöver sättas in i sitt sammanhang: scaling_cur_freq Enligt kärndokumentationen motsvarar detta i många fall det tillstånd som drivrutinen senast begärde, och inte nödvändigtvis den faktiska hårdvaruklockfrekvensen. Värdet, som inte alltid är tillgängligt, cpuinfo_cur_freq ska däremot visa den aktuella frekvensen som fastställts av hårdvaran. Mer om CPU-regulator på webbhotellsservrar förklarar hur frekvensskalningen styrs.

Ett lågt IPC-värde är en indikation på att ytterligare undersökningar behövs, men utgör inte en färdig diagnos. Minnesåtkomst kan bromsa körningen; man måste också kontrollera vilken del av programmet som har mätts och om det finns andra faktorer som påverkar. Jämför därför räknarvärdet med applikationens beteende och dess dataåtkomst.

Identifiera flaskhalsar och besluta om uppgradering

Börja med ett konkret symptom: Blir förfrågningarna långsamma under hög belastning, ökar felfrekvensen eller tar en enskild uppgift för lång tid? Notera när problemet uppstår och vilka processer som körs samtidigt. Först då går det att undersöka om mer CPU-kapacitet överhuvudtaget kan minska den aktuella fördröjningen.

Kontrollera först den tillgängliga och den använda CPU-tid. En uppgift som kräver kontinuerlig hög beräkningskapacitet kan dra nytta av snabbare exekvering eller större utnyttjbar parallellitet. En hög belastning i sig förklarar dock varken vilken kod som orsakar den eller om svarstiden främst uppstår där. Jämför därför resultatet med genomströmningen och svarstiderna under samma belastningsfas.

Undersök därefter minnesbehovet och dataåtkomsten. Om en databas ofta måste hämta data utanför CPU-cachen kan den bli tvungen att vänta på minnet; ett lågt IPC-värde kan tyda på detta, men bevisar inte orsaken. Även brist på arbetsminne, åtkomst till lagringsenheter eller långsamma externa tjänster kan påverka den observerade fördröjningen.

När det gäller en VPS ingår Resursåtagande När det gäller diagnosen: Undersök hur vCPU:erna tilldelas, eventuella CPU-begränsningar och hur resurserna delas med andra gäster. En dedikerad server erbjuder en annan tilldelning av fysiska resurser, men även där avgör applikationen, konfigurationen och belastningsprofilen resultatet. Jämför om möjligt de båda erbjudandena med samma applikationstest.

Överväg en CPU-uppgradering om mätningarna visar på en CPU-flaskhals och den nya prisplanen faktiskt tillhandahåller den beräkningstid som behövs. Om fördröjningen främst beror på minnet, lagringsenheten eller en extern tjänst är det mer meningsfullt att undersöka just dessa områden närmare. Dokumentera utgångsläget så att du senare kan utvärdera en förändring på ett jämförbart sätt.

Tolka inte uppgifter om maximal boost som en garanterad kontinuerlig klockfrekvens för alla kärnor, och betrakta inte ett IPC-värde som en universell egenskap hos processorn. På samma sätt räcker inte ett enda utnyttjandevärde för en fullständig diagnos av flaskhalsar. Beslutet fattas utifrån den konkreta uppgiften och de faktiskt tillgängliga resurserna, inte utifrån ett enda toppvärde.