Azure SQL MI vs. VM Performance Gap: Migration Estimator Tool

Det er en almindelig og frustrerende historie for teams, der flytter til Azures PaaS-databasetjenester. Du har en arbejdsbyrde, der kører perfekt på en 16-kernet Azure SQL Virtual Machine (IaaS). Du beslutter dig for at migrere til en Azure SQL Managed Instance (PaaS) for at reducere administrationsomkostninger. Du vælger en instans med 16 kerner og forventer lignende ydeevne. I stedet bliver applikationen langsommere til en gennemgang, og forespørgsler timeout.

Efter test finder du ud af, at kun en 32-core Managed Instance giver den stabilitet, du har brug for. Dette er en 2x omkostningsstigning, og det giver ingen mening. Er PaaS-tjenesten simpelthen mindre kraftfuld?

Svaret er nej. Problemet er, at en "vCore" i PaaS ikke er det samme som en "vCore" i IaaS. I PaaS er en vCore et bundt af ressourcer, og din arbejdsbyrde rammer ikke en CPU-grænse. Det rammer tre andre "skjulte" ressourcevægge, der er styret af platformen.

IaaS vs. PaaS Performance Model

At forstå "hvorfor" starter med ét koncept: ressourcestyring. På din IaaS VM styrer du alt. SQL Server-instansen kan "trække" alle de ressourcer, den har brug for, fra hardwaren. I PaaS "skubber" (allokerer) platformen en specifik kvote af ressourcer til din instans for at sikre stabilitet for alle. Din ustabilitet er platformen, der lykkes med sit arbejde med at håndhæve disse kvoter.

IaaS (VM): Uhæmmet "Pull"-model

Din kontrol:

• Operativsystem
• SQL Server Engine
• Host Caching
• Alle ressourceallokering

Din SQL Server "trækker" al den RAM, I/O og CPU den kan fra hardwaren. Det er kun begrænset af VM'ens fysiske SKU.

PaaS (MI): Styret "Push"-model

Azure Control (Governance):

• Hukommelsesforhold
• Log gennemløb
• I/O-latens og IOPS
• HA/backups (overhead)

Azure "skubber" en målt kvote af ressourcer til din instans. Når du rammer en grænse, sænker platformen din arbejdsbyrde.

De fire flaskehalse, du rammer

Din arbejdsbyrde er ikke CPU-bundet. Det er ressourcebundet. Klik på fanerne nedenfor for at se de nøjagtige grænser, du rammer på en 16-kernet General Purpose MI.

1. Hukommelse
2. Log gennemløb
3. Lager I/O
4. CPU hardware

Flaskehals 1: ~46 GB hukommelsesunderskud

Dette er den største enkeltkilde til præstationskløften. Din IaaS VM er sandsynligvis en hukommelsesoptimeret serie (som Edsv5), som giver dig et 8:1 hukommelse-til-vCore-forhold. MI General Purpose (Gen5) niveauet har et fast, lavere forhold på 5,1 GB pr. vCore.

Dette skaber et massivt hukommelsesunderskud. Dine forespørgsler, indstillet til 128 GB RAM, har pludselig kun 81,6 GB. Dette forårsager:

• Hukommelsestilskudsproblemer:Forespørgsler venter på hukommelse, hvilket forårsager højRESOURCE_SEMAPHOREventer.
• TempDB spild:Motoren skriver mellemresultater tiltempdbi stedet for at behandle in-memory, skabe et nyt I/O-problem.
• Udsættelser fra bufferpuljen:Bufferpuljen (din datacache) er mindre, hvilket fører til flere fysiske disklæsninger, som er langsomme på dette niveau.

Bemærk, at i PaaS,Max Memoryer forudkonfigureret og kan ikke justeres af brugeren. Skalering til 32 vCores "retter" dette ved i øvrigt at give dig 163,2 GB RAM (32 * 5,1), som endelig overstiger dine originale 128 GB.

Diagram: Samlet RAM-sammenligning

Flaskehals 2: Transaktionsloggen "Wall"

På din IaaS VM er logskrivehastighed kun begrænset af din disk (f.eks. 200+ MiB/s). MI General Purpose-niveauet håndhæver en hård guvernør på instansniveau på logskrivningsgennemløb for at garantere dets serviceniveau.

Her er den enkle matematik for Standard-serien (Gen5) niveauet:

• 16-kerne MI Cap:16 vCores * 4,5 MiB/s pr. vCore =72 MiB/s
• 32-core MI Cap:32 vCores * 4,5 MiB/s = 144 MiB/s (men rammer instansen max) =96 MiB/s

Din arbejdsbyrde (forværret aftempdbspild) genererer mere end 72 MiB/s logskrivning. Platformen drosler den, hvilket forårsager højLOG_RATE_GOVERNORventer. 96 MiB/s cap er det absolutte maksimum for *hele forekomsten* på denne hardware, også kendt somINSTANCE_LOG_GOVERNOR. Skalering til 32 vCores giver dig 24 MiB/s ekstra frihøjde, hvilket er lige nok til at stabilisere arbejdsbyrden.

Diagram: Log Write Throughput Cap

Flaskehals 3: Storage IOPS, Throughput og Latency

En velkonfigureret IaaS VM har en optimeret I/O-sti. MI General Purpose tier er designet til omkostningseffektivitet, ikke rå I/O-ydeevne. Det handler ikke kun om latens; IOPS og gennemløb er også styret.

• IaaS VM:Bruger en lokal kortvarig SSD tiltempdb(<1ms latency) og Premium SSD'er til data, ofte medSkrivebeskyttet værtscacheder serverer læsninger fra værtens lokale SSD.
• MIN GP-niveau:Bruger en lokal SSD tiltempdb(hvilket er godt), men alle dine data og logfiler er tændtekstern Azure Blob Storage. Dette har en indbygget latenstid på 5-10ms for hver enkelt I/O-operation. Der er ingen værtscache.

Når dit hukommelsestryk (flaskehals 1) tvinger forespørgsler til at spilde og læse fra disk, er disse læsninger nu 5-10 gange langsommere. Ydermere er I/O i GP tier styret affilstørrelse, ikke vCores. En større diskfil giver dig mere IOPS og gennemløb, op til et maksimum. Dette er endnu en fælde: en 16-kerne MI med små filer vil have forfærdelig I/O-ydeevne, uanset dets vCore-antal.

Infografik: I/O Read Latency Path

IaaS VM (med værtscache)

App

VM Host Cache

Disk
< 1 ms

PaaS MI (generelt formål)

App

Gateway

MI-forekomst

Fjernopbevaring
5-10 ms

Flaskehals 4: Selve CPU-hardwaren

Endelig er en "vCore" ikke en standardiseret enhed. Den underliggende fysiske hardware har betydning. Det er meget sandsynligt, at din IaaS VM og PaaS MI kører på forskellige hardwaregenerationer.

Standard-serien (Gen5)-hardwaren, der bruges af basisniveauet General Purpose, er ældre og langsommere end den hardware, du typisk bruger til en præstationsorienteret IaaS VM. Dette kan resultere i en 30-40 % reduktion i single-thread CPU-ydelse, selv før man overvejer de andre flaskehalse.

Vi har oprettet et dedikeret afsnit nedenfor for at forklare dette mere detaljeret.Klik her for at springe til afsnittet CPU Hardware Generationer.

Sådan finder du flaskehalse: Tjek dine ventestatistikker

Gæt ikke. Du kan bekræfte disse nøjagtige problemer ved at forespørge SQL Servers Dynamic Management Views (DMV'er). Kør følgende forespørgsler på din 16-kerne MI *under* præstationstesten.

Forespørgsel 1: Se efter Top Vent-statistikker

Denne forespørgsel viser dig, hvad dine forespørgsler bruger mest tid på at vente på. Høje værdier for ventetiden nedenfor er dine rygende våben.

SELECT TOP 10
    wait_type,
    wait_time_ms / 1000.0 AS wait_time_sec,
    (wait_time_ms * 100.0) / SUM(wait_time_ms) OVER() AS pct_wait_time
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN (
    -- Filter out common "benign" waits
    'CLR_SEMAPHORE', 'LAZYWRITER_TIMER', 'SQLTRACE_BUFFER_FLUSH',
    'SLEEP_TASK', 'WAITFOR', 'REQUEST_FOR_DEADLOCK_SEARCH'
)
ORDER BY wait_time_ms DESC;
                            

• HøjRESOURCE_SEMAPHORE:Dette er dit hukommelsesproblem. Forespørgsler venter på tilgængelige hukommelsesbevillinger. Dette bekræfter flaskehals 1.
• HøjLOG_RATE_GOVERNOR:Dette er dit problem med loggasregulering. Platformen begrænser aktivt din transaktionsloggennemstrømning. Dette bekræfter flaskehals 2.
• HøjPAGEIOLATCH_SH/PAGEIOLATCH_EX:Dette er dit I/O-problem. Forespørgsler venter på, at data bliver læst fra (eller skrevet til) disk. Dette er et symptom på både lav hukommelse (flaskehals 1) og lagring med høj latens (flaskehals 3).

'TempDB'-faktoren i almindelighed

En almindelig misforståelse er, at fordi GP-niveauet bruger en lokal SSD til "tempdb", er dens ydeevne ubegrænset. Dette er ikke sandt.

Mens den lokale SSD giver fremragendelatenstid(som på din IaaS VM), denIOPS og gennemløbfor 'tempdb' er *også* styret baseret på dit vCore-antal. Når dine hukommelsessultne forespørgsler (flaskehals 1) begynder at sprede sig til `tempdb`, genererer de en enorm mængde I/O. Denne I/O rammer hurtigt "tempdb"-styringsgrænserne og skaber en ny flaskehals.

Din arbejdsbyrde bliver en kædereaktion af fiasko:

1. Lav hukommelsefår forespørgsler til at anmode om hukommelsesbevillinger.
2. Vent statistikviseRESOURCE_SEMAPHORE.
3. Spørgsmål Spiltil 'tempdb' for at undgå at vente.
4. TempDB I/Ospidser, der rammer den lokale SSD's IOPS/gennemstrømningshætte.
5. Log aktivitetogså pigge fra spild, rammerLOG_RATE_GOVERNORkasket.

Hele forekomsten bliver droslet, ikke kun af én grænse, men af ​​tre separate ressourceregulatorer på samme tid.

At vælge dit våben: Et dybere kig på serviceniveauer

Roden til problemet er et arkitektonisk misforhold. Du sammenligner en IaaS VM, der er bygget til ydeevne, med en PaaS-tier (General Purpose), der er bygget til omkostningseffektivitet. Her er den arkitektoniske forskel.

Generelt formål: Afkoblet opbevaring

Dette niveau adskiller compute (vCores, RAM) fra lager (datafiler). Dine data lever på ekstern Azure Blob Storage, som er omkostningseffektiv og holdbar, men har højere latenstid.

• Bedst til:De fleste forretningsapplikationer, udvikling og arbejdsbelastninger, der ikke er I/O-intensive.
• Nøgletræk:5-10 ms lagerforsinkelse.
• Fælden:Ydeevne afhænger af filstørrelse, ikke vCores.

Forretningskritisk: Koblet opbevaring

Dette lag samler databehandling og lagring på den samme maskine. Dine data lever på en superhurtig lokal SSD, ligesom din IaaS VM. Dette giver den bedste ydeevne og laveste latenstid.

• Bedst til:Højtydende OLTP, rapportering og I/O-intensive arbejdsbelastninger.
• Nøgletræk:1-2ms lagerforsinkelse.
• Fordelen:Arkitektonisk identisk med en højtydende VM.

CPU-hardwaregenerationer forklaret

Ikke alle vCores er skabt lige. Den underliggende fysiske hardwaregenerering dikterer "hastigheden" af din vCore. Din IaaS VM er sandsynligvis på nyere, hurtigere hardware end basis-PaaS-niveauet.

Azure SQL Managed Instance tilbyder forskellige "hardware-serier", der knytter sig til disse generationer. Du er sandsynligvis på "Standard-serien (Gen5)" hardware, som er den ældste og langsomste.

Denne tabel viser, at GP-forekomsten med 16 kerner kører på en CPU, der er betydeligt langsommere (2,5 GHz) end din IaaS VM (3,0-3,5 GHz). Denne langsommere clockhastighed påvirker direkte forespørgselsbehandlingstiden, hvilket forværrer hukommelsen og I/O-problemerne. Business Critical-laget kører på den samme hurtige "Premium-serie" (Ice Lake) hardware som moderne IaaS VM'er.

Real-World Performance Mapping: IaaS VM til PaaS MI

Stop med at tænke 1:1 på vCores. Den rigtige måde at migrere på er at matche din arbejdsbyrdes *profil*. Her er en simpel guide til at kortlægge en højtydende IaaS VM til den korrekte PaaS-tier.

Denne tabel gør problemet indlysende. Din 16-core IaaS VM var sandsynligvis en "E-serie" (hukommelsesoptimeret) VM, som kortlægges direkte tilForretningskritiskniveau, ikke generelle formål. Du testede det forkerte niveau fra starten.

Interaktiv PaaS SKU Estimator

Brug denne enkle lommeregner til at få en startanbefaling til din IaaS til PaaS-migrering. Indtast din *nuværende* IaaS VMs kernespecifikationer.

IaaS vCores

IaaS RAM (GB)

Primær arbejdsbyrde

Vælg profil...
Generelt / Udvikler/Test
Høj I/O (OLTP)
Høj hukommelse (Analytics/BI)

Estimer PaaS SKU

"Aha!" Moment: Sammenligning af niveauer

Dataene gør problemet klart. GP-instansen med 32 kerner "retter" problemet ved at forcere hukommelses- og loghastighedsgrænserne. Men dette er ineffektivt. Du køber 16 ekstra vCores bare for at få RAM og I/O, der fulgte med din originale 16-core VM.

Foreslået læsning:On-premises DNS → Azure DNS Migration Tool Estimator Checkliste

Tabel 1: Den ineffektive sammenligning (dit testscenarie)

Løsningen: Test Business Critical Tier

General Purpose-laget er ikke den arkitektoniske ækvivalent til din højtydende VM. DeForretningskritisk (BC)tier er. Før du betaler for en 32-core GP-instans, bør du teste en16-core forretningskritiskeksempel. Her er grunden til, at det er den korrekte "æbler-til-æbler" sammenligning.

Tabel 2: Den korrekte arkitektoniske sammenligning

Som tabellen viser, er en 16-core Business Critical-instans et meget tættere match. Den bruger hurtige, lokale SSD'er til data (hvilket eliminerer 5-10 ms latency) og har et loghastighedsloft (192 MiB/s), der er 2,6x højere end 32-core GP-instansens loft. Hukommelsen (112 GB) er også meget tættere på dine originale 128 GB og kan være tilstrækkelig. Dette niveau er bygget til højtydende, I/O-intensive arbejdsbelastninger som din.

Hvad med Hyperscale?

Hyperscale er en anden mulighed, men den er arkitektonisk anderledes. Den er designet til massiv skala (op til 100 TB) og ekstremt hurtige backups og gendannelser. Den har en unik logtjeneste og et niveaudelt cachesystem. Selvom dens ydeevne er fremragende, kan den være overkill. Forretningskritisk er den mere direkte "løft og skift"-ydelse svarende til en højspecifik IaaS VM. Test Business Critical først; hvis din database er usædvanlig stor (10s af TB'er), så bliver Hyperscale det næste logiske trin at evaluere.

Executive Summary

• En PaaS vCore er ikke bare en CPU; det er enbundt af målte ressourcer(CPU, RAM, I/O).
• Din 16-core GP-instans er langsom, fordi den erudsultet af hukommelse(~46 GB underskud) ogdroslet på log skriver(72 MiB/s cap).
• Dine problemer forværres af fjernlagring med høj latens og ældre, langsommereCPU hardware(Gen5).
• Den 32-kernede GP "fix" fungerer efteri øvrigtgiver dig nok hukommelse (163,2 GB) og log frihøjde (96 MiB/s) til at stoppe gassen.
• Du betaler for 16 ekstra vCores, som du sandsynligvis ikke har brug for.
• Den vigtigste anbefaling:Før du godkender 32-core General Purpose-instansen, skal du teste din arbejdsbyrde på en 16-coreForretningskritiskeksempel. Det er den korrekte arkitektoniske ækvivalent til din IaaS VM og vil sandsynligvis opfylde dine præstationsbehov mere effektivt.

Endelige tanker: Det handler om arkitektur, ikke vCores

At flytte fra IaaS til PaaS er et arkitektonisk skift, ikke et simpelt hardwareskift. Mysteriet "16-core VM vs. 32-core MI" er et klassisk tilfælde af en arkitektonisk uoverensstemmelse. Problemet er ikke, at Azure SQL PaaS er "langsommere"; det er, at General Purpose-laget er bygget til et andet formål end din højtydende IaaS VM.

General Purpose er designet til omkostningseffektivitet med afkoblet opbevaring, hvilket gør den perfekt til tusindvis af applikationer. Men din arbejdsbyrde, som var indstillet til 128 GB RAM og sub-millisekunder I/O, hører til på et niveau, der leverer disse ressourcer. Det niveau er forretningskritisk.

Stop med at fokusere på vCore-antal og begynd at fokusere på den rigtige arkitektur. Brug DMV-forespørgslerne til at finde dine specifikke flaskehalse. Vi er overbeviste om, at når du tester en 16-core Business Critical-instans, vil dine ydeevneproblemer forsvinde, og du vil have fundet den sande, omkostningseffektive PaaS, der svarer til din kraftfulde VM.

Ofte stillede spørgsmål

En 16-core Business Critical-instans er dyrere end en 32-core General Purpose. Hvordan er det en bedre aftale?

Det handler om "rigtig størrelse" og effektivitet. Med 32-core GP-instansen betaler du for 16 ekstra vCores (og deres tilhørende softwarelicenser), som din arbejdsbyrde sandsynligvis ikke engang har brug for. Du køber dem *kun* for at få den hukommelse og loghastighed, der følger med dem. BC-forekomsten med 16 kerner "tilpasser" din implementering: du betaler for de 16 vCores, du faktisk har brug for, og du får den højtydende lagring og hukommelse, der er passende til den pågældende arbejdsbyrde. Det er den mere effektive og arkitektonisk korrekte løsning.

Min arbejdsbyrde er stadig langsom på Business Critical. Hvad nu?

Dette er sjældent, hvis du kommer fra en sammenlignelig VM, men det betyder, at du har fundet en ny flaskehals. Tjek først dine DMV'er for ventetider. Hvis du ikke længere er I/O- eller log-bundet, er du muligvis ægte CPU-bundet. I dette tilfælde skal du muligvis skalere op til 20 eller 24 vCores. For det andet, tjek din hukommelse. Hvis du serRESOURCE_SEMAPHOREvent, overvej "Memory-Optimized" hardware-serien i BC-tier, som giver et meget højere 1:8 hukommelse-til-vCore-forhold, ligesom din originale VM.

Kan jeg ikke bare optimere mine forespørgsler til at arbejde på den 16-kernede GP?

Du kan og bør altid optimere forespørgsler. Optimering har dog sine grænser. Hvis din applikations logik grundlæggende kræver store datascanninger, sortering af store datasæt i `tempdb` eller udførelse af komplekse joinforbindelser, der kræver meget hukommelse, vil ingen mængde tuning løse et 46 GB hukommelsesunderskud eller en flaskehals på 5-10 ms lagerforsinkelse. Du vil optimere *omkring* en platformsgrænse i stedet for at løse rodproblemet.