CPU-IPC og klokfrekvens: Sådan sammenligner du hosting-processorer korrekt

CPU IPC: Instruktioner pr. takt

CPU IPC står for Instructions per Cycle, altså instruktioner pr. taktcyklus. For et afgrænset måleområde divideres antallet af afsluttede maskininstruktioner normalt med antallet af CPU-cyklusser, der er talt i det samme område. En IPC på 2 betyder i denne sammenhæng i gennemsnit to afsluttede instruktioner pr. talt cyklus.

Værdien er en Udførelsesmæssige egenskaber, ikke et fast tal, der gælder for alle en processorens opgaver. Det samme system kan opnå en anden IPC ved en beregning med let tilgængelige data end ved en databaseforespørgsel, der ofte må vente på data fra hovedhukommelsen. Også det pågældende datasæt og den betragtede programdel påvirker resultatet.

En cache opbevarer ofte anvendte data tæt på CPU’en. Hvis en kerne i stedet skal vente på langsommere hukommelsesadgange, kan eksekveringsenhederne til tider stå ubenyttede hen. Ligeledes påvirker afhængigheder mellem instruktioner og forgreninger i programforløbet, hvor meget arbejde der kan udføres samtidigt. En lav IPC er derfor anledning til yderligere undersøgelse, men endnu ikke en entydig diagnose.

En maskininstruktion er desuden ikke en standardiseret enhed for en afsluttet webforespørgsel. Kompilator, instruktionssæt og vektorisering kan medføre, at forskellige programmer kræver et forskelligt antal instruktioner til den samme opgave. En højere IPC alene er derfor ikke i sig selv bevis på hverken en kortere svartid eller flere forespørgsler pr. sekund.

For at kunne sammenligne er det afgørende, hvilken anvendelse og hvilket måleområde der ligger bag værdien. Et IPC-tal uden disse oplysninger giver ikke noget svar på, om systemerne overhovedet udfører det samme arbejde. Du kan finde yderligere grundlæggende oplysninger om samspillet mellem taktfrekvens, kerner og hukommelseshierarki i artiklen om CPU-arkitektur inden for hosting.

Forståelse af serverens klokfrekvens og boost

Klokfrekvensen angiver, hvor mange cyklusser en CPU gennemløber pr. sekund. En gigahertz, forkortet GHz, svarer til en milliard cyklusser pr. sekund. Værdien i sig selv siger ikke noget om, hvor mange instruktioner et program udfører i disse cyklusser, eller hvor meget nyttigt arbejde det udfører med dem.

I databladene står der ofte en Grundfrekvens og en maksimal boost. Grundfrekvensen fungerer som en specifikationsværdi; boost betegner en højere mulig frekvens under passende betingelser. Ingen af disse angivelser erstatter en observation af den faktisk opnåede taktshastighed under den konkrete anvendelse og den tilhørende belastning.

Et eksempel er AMD EPYC 9655: For denne model angiver AMD 96 kerner, 192 tråde, en basisfrekvens på 2,6 GHz og en maksimal boost-frekvens på op til 4,5 GHz. Disse værdier beskriver processorens specifikationer og frekvens. De er hverken en målt IPC eller et bevis på en bestemt hosting-gennemstrømning.

For EPYC-9005-serien definerer AMD maksimal boost som den højeste frekvens, en enkelt kerne kan nå under normale serverdriftsforhold. De op til 4,5 GHz, som 9655 kan nå, er således ingen garanti for, at alle 96 kerner kan opretholde denne frekvens vedvarende. Ydelses- og temperaturgrænser påvirker adfærden under belastning.

Ved en kortvarig enkeltopgave kan en midlertidigt højere takthastighed være relevant; ved langvarig parallel belastning er det derimod interessant at se, hvilken ydelse systemet leverer over hele driftsperioden. Andre modeller i serien har andre frekvenser og antal kerner. En sammenligning, der udelukkende baseres på den højeste GHz-værdi, ville udelade disse forskelle og den konkrete anvendelse.

Kerner, tråde og virtuelle CPU'er

En proces er, forenklet sagt, en kørende programinstans. Her udfører en eller flere tråde instruktioner. En fysisk CPU-kerne råder over den nødvendige hardware til at udføre dette arbejde; operativsystemer registrerer, afhængigt af processoren, en eller flere logiske CPU-tråde pr. kerne. Logiske tråde i samme kerne deler dermed dele af dens hardware.

En opgave med et stærkt serielt afsnit kan ikke fordele denne del vilkårligt på mange kerner. Her er det afgørende, hvor hurtigt den udførende tråd klarer det konkrete arbejde. Uafhængige webforespørgsler kan derimod ofte behandles parallelt: I så fald kan yderligere tilgængelige kerner bidrage til den samlede gennemstrømning, forudsat at andre ressourcer ikke udgør en begrænsning.

Antallet af logiske tråde skal ikke forveksles med antallet af uafhængige fysiske kerner. EPYC 9655 har for eksempel 96 fysiske kerner og 192 tråde ifølge producenten. De 192 tråde betyder hverken en fordobling af ydeevnen i forhold til 96 tråde eller en bestemt gennemstrømning for en webserver.

I forbindelse med en virtuel server stiller udbyderen følgende til rådighed for gæstoperativsystemet vCPU'er klar. En vCPU er ikke nødvendigvis en fysisk kerne, der kan bruges eksklusivt: Hvordan den er tilknyttet værtshardwaren kan variere afhængigt af tilbuddet, og regnetiden kan deles med andre gæster eller være begrænset af forskellige begrænsninger.

Spørgsmål, der skal stilles inden valget af den konkrete ressourcetildeling: Er CPU-tid garanteret, eller deles den? Er der permanente ydeevnebegrænsninger, og hvordan tildeles vCPU'er? Et højt antal vCPU'er hjælper kun en parallel applikation i det omfang, der faktisk er tilstrækkelig regnetid til rådighed; for en seriel del kan det ikke erstatte hurtig udførelse på en tråd.

IPC og takt beregnes sammen

IPC og taktfrekvens beskriver forskellige aspekter af CPU’ens ydeevne. For et passende afgrænset måleområde kan deres indvirkning tilnærmelsesvis sammenkædes: instruktioner pr. sekund svarer til IPC ganget med det effektive antal CPU-cyklusser pr. sekund. IPC henviser her til de afsluttede instruktioner og de tællede cyklusser inden for samme tidsrum.

Illustrativt regneeksempel, ikke en måling: Hvis man antager en konstant på 2,0 instruktioner pr. cyklus og 3,0 GHz, giver det regnemæssigt 6,0 milliarder instruktioner pr. sekund. Selv 1,5 IPC ved 4,0 GHz giver 6,0 milliarder. I dette eksempel udligner den højere klokfrekvens altså den lavere IPC i beregningen.

At instruktionshastighederne er ens, betyder dog ikke, at begge systemer behandler det samme antal webforespørgsler. Til den samme opgave kan programmer kræve et forskelligt antal instruktioner afhængigt af kompilatoren, instruktionssættet og de anvendte instruktioner. En instruktion er derfor ikke et ensartet mål for den udførte applikationsarbejde.

Heller ikke et websteds responstid fremgår direkte af produktet. En tråd kan vente på data fra lagringsmediet eller på et svar fra netværket; i mellemtiden forklarer dens instruktionshastighed ikke den samlede forløbne tid. I tilfælde af en virtuel maskine kommer det dertil, at den ikke nødvendigvis får CPU-tid hele tiden.

For at kunne foretage en sammenligning skal det derfor fremgå, hvilken kode og hvilket tidsrum der er taget højde for. Formlen hjælper med at indplacere den aktive udførelse; til beslutningen om hosting er det desuden nødvendigt at have oplysninger om afsluttede opgaver og deres svartider under en sammenlignelig forespørgselsprofil.

Indplacering af datablad og nøgletal

Et datablad giver nyttige anvisninger til valg af en hosting-CPU. Oplysningerne besvarer dog forskellige spørgsmål: IPC beskriver en adfærd inden for det pågældende måleområde, mens frekvensangivelser og antal kerner derimod specificerer egenskaberne ved en bestemt processormodel. Først i sammenhæng med den konkrete anvendelse bliver disse oplysninger til brugbare sammenligningskriterier.

EPYC 9655 viser, hvordan sådanne specifikationer hænger sammen: Ifølge AMD har modellen 96 kerner og 192 tråde, en basisfrekvens på 2,6 GHz og en maksimal boost-frekvens på op til 4,5 GHz. De 4,5 GHz er ikke en garanteret frekvens for alle kerner under vedvarende belastning og heller ikke en målt hosting-gennemstrømning.

En rangliste baseret på den maksimale GHz-hastighed ville ikke vise, hvor meget arbejde de forskellige processorer udfører pr. cyklus og pr. opgave. En rangliste baseret på antallet af kerner overser derimod, at ikke alle programmer kan fordele deres arbejde lige godt parallelt. Begge oplysninger er udgangspunkter, ikke endelige vurderinger af ydeevnen.

Vær derfor opmærksom på følgende i tilbuddene: Modelvariant og på, hvilke ressourcer der rent faktisk kan udnyttes. For at kunne foretage en pålidelig sammenligning skal du desuden have en passende belastningsprofil og resultater baseret på sammenlignelig software og konfiguration. Specifikationerne for de forskellige modeller bør ikke blandes sammen med et maksimumsværdi, der antages at gælde for hele produktfamilien.

Vælg hosting-CPU ud fra belastningsprofil

Hvilken CPU der er egnet til hosting, afhænger af, hvad serveren skal udføre. En lang enkeltopgave stiller andre krav end mange uafhængige webforespørgsler. Tabellen omsætter typiske belastningsprofiler til en primær måleparameter og et spørgsmål, der bør afklares, inden valget træffes.

Ved en enkeltopgave er den udførende tråds ydeevne særlig vigtig, hvis en større del af arbejdet udføres serielt. Flere kerner forkorter ikke automatisk denne del. En kortvarig maksimal hastighedsforøgelse er heller ikke tilstrækkeligt bevis for en opgave, der kører i lang tid: Det afgørende er den målte køretid under de fastlagte betingelser.

Derimod kan mange uafhængige forespørgsler behandles sideløbende. Her er det ikke kun ydeevnen pr. tråd, der tæller, men også hvor mange ressourcer der er tilgængelige samtidigt, og hvordan svartiderne udvikler sig, når belastningen stiger. Den samlede nominelle GHz-værdi kan ikke erstatte en sammenligning af Samlet gennemstrømning ved samme grad af parallelitet.

I en database med et stort arbejdsdatasæt kan hukommelsesadgange bremse udførelsen, hvis de nødvendige data ikke hentes effektivt fra cachen. En lav IPC kan være anledning til yderligere undersøgelser, men er ikke i sig selv bevis på en hukommelsesflaskehals. Kontroller derfor også forespørgsler, datamængden og hukommelseskonfigurationen, inden du udskifter CPU'en.

Ved VPS er der desuden Tilsagn om ressourcer Vigtigt: En vCPU er ikke automatisk en eksklusiv fysisk kerne. Man skal undersøge tildelingen, eventuelle CPU-begrænsninger og delingen med andre gæster. Først med disse oplysninger kan man på en meningsfuld måde sammenligne en applikationstest med et tilbud på en dedikeret server.

Planlægge sammenlignelige anvendelsestests

En meningsfuld sammenligning tager udgangspunkt i din applikation, ikke i et isoleret CPU-tal. Vælg den samme softwareversion, det samme datasæt og den samme konfiguration for begge hostingtilbud. SPEC betegner din egen applikation på din egen infrastruktur som den ideelle målestok for produktvalg.

Definer derefter en Forespørgselsprofil, der så godt som muligt afspejler den senere brug: for eksempel hvilke sider eller API-endepunkter der kaldes, og hvor mange forespørgsler der modtages samtidigt. Sørg for, at paralleliteten og ressourcebegrænsningerne er sammenlignelige mellem de forskellige gennemløb. Hvis et tilbud angiver andre begrænsninger, skal du dokumentere dem udtrykkeligt i stedet for blot at tilskrive forskellen til CPU’en.

Sørg for at indregne en opvarmningsfase, så applikationen f.eks. er kommet i gang, og cacherne har haft tid til at fyldes op. Derefter kan flere tilstrækkeligt lange gennemløb hjælpe med at skelne mellem kortvarige udsving og en tilbagevendende forskel. Dokumenter også, om der kørte andre opgaver på systemerne under målingen.

Udover gennemstrømningen skal du registrere Fordeling af svartider og fejlene. Et højere gennemsnit af afsluttede forespørgsler pr. sekund er i sig selv ikke særlig nyttigt, hvis enkelte forespørgsler har meget lange ventetider eller oftere mislykkes. Sammenlign derfor også høje percentiler for svartiden ved samme parallelitet.

Offentliggjorte SPEC-CPU2017-resultater kan give yderligere vejledning. SPECspeed måler den tid, der kræves til at udføre opgaver, mens SPECrate måler gennemstrømningen; de to målemetoder kan ikke umiddelbart sammenlignes med hinanden. Sammenlign resultater baseret på samme målemetode, og vær opmærksom på systemkonfigurationen og softwaren. CPU-suiten afspejler ikke netværk og I/O i en komplet hosting-tjeneste.

Kontroller IPC og frekvens under drift

Hvis du vil oprette dit eget Linux-testmiljø, kan du bruge perf til at registrere de afsluttede instruktioner og cyklusser i et eksisterende, testet program. I det følgende eksempel er testprogramm En pladsholder: Erstat den med dit testprogram og eventuelt dets argumenter. Kommandoen er et forslag til en måling, ikke en test, der allerede er udført.

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

De krøllede parenteser sammenfatter begivenhederne til en Tællergruppe sammen. De skal registreres samtidigt, hvilket kan mindske fejl som følge af tidsforskudt multiplexing. Del de tællede instruktioner med de tællede cyklusser for at få IPC for dette måleinterval; perf kan også udskrive denne værdi direkte.

Om begivenhederne er tilgængelige og må læses, afhænger af hardware, kerne, rettigheder og eventuelt virtualiseringsmiljøet. En begivenhedsgruppe, der ikke er tilgængelig eller ikke kan medregnes, giver ikke et pålideligt sammenligningsgrundlag. Du bør ikke ændre sikkerhedsindstillingerne udelukkende på grund af dette eksempel.

Selv en frekvensangivelse kræver en sammenhæng: scaling_cur_freq svarer ifølge kernel-dokumentationen i mange tilfælde til den tilstand, som driveren senest har anmodet om, og ikke nødvendigvis til den faktisk opnåede hardwarefrekvens. Den værdi, der ikke er tilgængelig overalt cpuinfo_cur_freq skal derimod vise den aktuelle frekvens, der er målt på hardwaresiden. Mere om CPU-regulator på hosting-servere forklarer styringen af frekvensskaleringen.

En lav IPC-værdi er et fingerpeg om, at der bør foretages yderligere undersøgelser, men udgør ikke en endelig diagnose. Adgang til hukommelsen kan bremse udførelsen; man skal ligeledes undersøge, hvilken del af programmet der er blevet målt, og om der er andre påvirkende faktorer. Sammenlign derfor tællerværdien med applikationens adfærd og dens dataadgang.

Identificer flaskehalse og træf beslutning om opgradering

Start med et konkret symptom: Bliver forespørgsler langsomme under belastning, stiger fejlfrekvensen, eller tager en enkelt opgave for lang tid? Notér, hvornår problemet opstår, og hvilke opgaver der kører samtidig. Først da kan man undersøge, om mere CPU-kapacitet overhovedet kan reducere den pågældende forsinkelse.

Kontroller først den tilgængelige og den anvendte CPU-tid. En vedvarende beregningsintensiv opgave kan drage fordel af hurtigere udførelse eller større udnyttelig parallelitet. En høj udnyttelsesgrad alene forklarer dog hverken, hvilken kode der forårsager den, eller om responstiden primært opstår dér. Sammenlign derfor resultatet med gennemstrømningen og responstiderne for den samme belastningsfase.

Undersøg derefter hukommelsesbehovet og dataadgangen. Hvis en database ofte skal hente data uden for CPU-cachen, kan den komme til at vente på hukommelsen; en lav IPC kan være et tegn på dette, men beviser ikke årsagen. Også begrænset RAM, adgang til lagringsmedier eller langsomme eksterne tjenester kan påvirke den observerede forsinkelse.

Når det gælder en VPS, hører Tilsagn om ressourcer Med hensyn til diagnosen: Spørg ind til tildelingen af vCPU’er, eventuelle CPU-begrænsninger og delingen med andre gæster. En dedikeret server tilbyder en anden fordeling af fysiske ressourcer, men også her er det applikationen, konfigurationen og belastningsprofilen, der afgør resultatet. Sammenlign om muligt begge tilbud ved hjælp af den samme applikationstest.

Overvej en CPU-opgradering, hvis målingerne viser, at der er en CPU-flaskehals, og den nye prisplan rent faktisk giver den nødvendige regnetid. Hvis forsinkelsen hovedsageligt skyldes hukommelsen, lagringsmediet eller en ekstern tjeneste, er det mere fornuftigt at undersøge disse områder nærmere. Notér udgangstilstanden, så du senere kan vurdere en ændring på et sammenligneligt grundlag.

Man bør ikke opfatte de maksimale boost-værdier som en garanteret vedvarende hastighed for alle kerner, og en IPC-værdi bør ikke betragtes som en universel egenskab ved CPU’en. Ligeledes er et enkelt udnyttelsestal ikke tilstrækkeligt til en fuldstændig diagnose af flaskehalse. Beslutningen træffes på baggrund af den konkrete opgave og de faktisk tilgængelige ressourcer, ikke på baggrund af et enkelt spidsværdi.