Utforsk ytelsesscenarioer

  • 5 minutter

Hvis du vil bestemme hvordan du bruker ytelsesverktøy og -funksjoner, er det viktig å se på ytelsen for Azure SQL gjennom scenarioer.

Forstå vanlige ytelsesscenarioer

En vanlig teknikk for feilsøking av SQL Server-ytelse er å undersøke om et ytelsesproblem er kjører (høy CPU) eller Venter på (venter på en ressurs). Diagrammet nedenfor viser et beslutningstre for å avgjøre om et ytelsesproblem for SQL Server kjører eller venter, og hvordan du bruker ytelsesverktøy til å finne årsaken og løsningen.

diagram over kjøring kontra venting.

Først kan du se på den totale ressursbruken. For en standard SQL Server-distribusjon kan du bruke verktøy som Performance Monitor i Windows eller øverst i Linux. For Azure SQL kan du bruke følgende metoder:

  • Azure Portal/PowerShell/varsler

    Azure Monitor har integrerte måledata for å vise ressursbruk for Azure SQL. Du kan også konfigurere varsler for å se etter ressursbeleggbetingelser.

  • sys.dm_db_resource_stats

    For Azure SQL Database kan du se på denne DMV-en for å se CPU, minne og I/U-ressursbruk for databasedistribusjonen. Denne DMV-en tar et øyeblikksbilde av disse dataene hvert 15. sekund.

  • sys.server_resource_stats

    Denne DMV-en fungerer akkurat som sys.dm_db_resource_stats, men den brukes til å se ressursbruk for SQL-administrert forekomst for CPU, minne og I/U. Denne DMV-en tar også et øyeblikksbilde hvert 15. sekund.

  • sys.dm_user_db_resource_governance

    For Azure SQL Database returnerer denne DMV de faktiske konfigurasjons- og kapasitetsinnstillingene som brukes av ressursstyringsmekanismer i den gjeldende databasen eller det elastiske utvalget.

  • sys.dm_instance_resource_governance

    For Azure SQL Managed Instance returnerer denne DMV lignende informasjon som sys.dm_user_db_resource_governance, men for den gjeldende SQL-administrerte forekomsten.

Løping

Hvis du har fastslått at problemet er høy CPU-utnyttelse, kalles dette et scenario som kjører. Et scenario som kjører, kan involvere spørringer som bruker ressurser gjennom kompilering eller kjøring. Bruk følgende verktøy for videre analyse:

  • Spørringslager

    Bruk de mest brukte ressursrapportene i SSMS, katalogvisninger for spørringslager eller spørringsytelsesinnsikt i Azure-portalen (bare Azure SQL Database) for å finne ut hvilke spørringer som bruker mest CPU-ressurser.

  • sys.dm_exec_requests

    Bruk denne DMV-en i Azure SQL til å få et øyeblikksbilde av tilstanden til aktive spørringer. Se etter spørringer med tilstanden RUNNABLE og en ventetype for SOS_SCHEDULER_YIELD for å se om du har nok CPU-kapasitet.

  • sys.dm_exec_query_stats

    Denne DMV-en kan brukes omtrent som spørringslager for å finne de mest brukte ressursspørringene. Den er bare tilgjengelig for spørringsplaner som bufres, mens Spørringslager gir en vedvarende historisk ytelsespost. Med denne DMV-en kan du også finne spørringsplanen for en bufret spørring.

  • sys.dm_exec_procedure_stats

    Denne DMV-en gir informasjon omtrent som sys.dm_exec_query_stats, bortsett fra at ytelsesinformasjonen kan vises på det lagrede prosedyrenivået.

    Når du har funnet ut hvilke spørringer eller spørringer som bruker mest ressurser, må du kanskje undersøke om du har nok CPU-ressurser for arbeidsbelastningen. Du kan feilsøke spørringsplaner med verktøy som lett spørringsprofilering, SET-setninger, spørringslager eller utvidet sporing av hendelser.

Under

Hvis problemet ikke ser ut til å være en høy CPU-ressursbruk, kan det være at ytelsesproblemet innebærer å vente på en ressurs. Scenarioer som involverer venting på ressurser inkluderer:

  • I/U venter
  • Lås venting
  • Latch venter
  • Begrensninger for bufferutvalg
  • Minnetilskudd
  • Planbufferutkasting

Hvis du vil utføre analyser om ventescenarioer, vil du vanligvis se på følgende verktøy:

  • sys.dm_os_wait_stats

    Bruk denne DMV-en til å se de øverste ventetypene for databasen eller forekomsten. Dette kan veilede deg om hvilken handling du skal gjøre videre, avhengig av de øverste ventetypene.

  • sys.dm_exec_requests

    Bruk denne DMV-en til å finne bestemte ventetyper for aktive spørringer for å se hvilken ressurs de venter på. Dette kan være et standard blokkeringsscenario som venter på låser fra andre brukere.

  • sys.dm_os_waiting_tasks

    Du kan bruke denne DMV-en til å finne ventetyper for en bestemt oppgave for en bestemt spørring som kjører for øyeblikket, kanskje for å se hvorfor det tar lengre tid enn normalt. sys.dm_os_waiting_tasks inneholder den direktesendte ventestatistikken som sys.dm_os_wait_stats aggregater over tid.

  • Spørringslager

    Spørringslager inneholder rapporter og katalogvisninger som viser en aggregasjon av de øverste ventetidene for kjøring av spørringsplan. Det er viktig å vite at en ventetid på CPU- tilsvarer en som kjører problem.

Scenarioer som er spesifikke for Azure SQL

Det finnes noen ytelsesscenarioer, både kjører og venter, som er spesifikke for Azure SQL. Disse inkluderer log governance, worker limits, waits encountered for Business Critical service tiers, og venter spesifikt på en Hyperscale-distribusjon.

Loggstyring

Azure SQL kan bruke log rate governance til å håndheve ressursgrenser for bruk av transaksjonslogg. Du trenger kanskje denne håndhevelsen for å sikre ressursgrenser og for å oppfylle den lovede serviceavtalen. Loggstyring kan ses fra følgende ventetyper:

  • LOG_RATE_GOVERNOR: venter på Azure SQL Database
  • POOL_LOG_RATE_GOVERNOR: venter på elastiske bassenger
  • INSTANCE_LOG_GOVERNOR: venter på Azure SQL Managed Instance
  • HADR_THROTTLE_LOG_RATE*: venter på ventetid for forretningskritisk og georeplikering

Arbeidergrenser

SQL Server bruker et arbeidsutvalg med tråder, men har begrensninger på maksimalt antall arbeidere. Programmer med et stort antall samtidige brukere kan nærme seg arbeidergrensene som håndheves for Azure SQL Database og SQL Managed Instance:

  • Azure SQL Database har begrensninger basert på tjenestenivå og størrelse. Hvis du overskrider denne grensen, får en ny spørring en feilmelding.
  • For øyeblikket bruker SQL Managed Instance max worker threads, slik at arbeidere som er forbi denne grensen, kan se THREADPOOL vente.

Business Critical HADR venter

Hvis du bruker et forretningskritisk tjenestenivå, kan det hende du uventet ser følgende ventetyper:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Selv om disse ventetidene kanskje ikke gjør programmet tregere, forventer du kanskje ikke å se disse. De er vanligvis spesifikke for å bruke en alltid på tilgjengelighetsgruppe. Forretningskritiske nivåer bruker tilgjengelighetsgruppeteknologi til å implementere SLA- og tilgjengelighetsfunksjoner for et tjenestenivå for forretningskritisk tjeneste, slik at disse ventetypene forventes. Lange ventetider kan indikere en flaskehals, for eksempel I/O-ventetid eller replika bak.

Hyperskala

Hyperscale-arkitekturen kan resultere i noen unike ventetyper som er prefiks med RBIO- (en mulig indikasjon på loggstyring). I tillegg er DMV-er, katalogvisninger og utvidede hendelser forbedret for å vise måledata for sideserverlesninger.

I neste øvelse lærer du hvordan du overvåker og løser et ytelsesproblem for Azure SQL ved hjelp av verktøyene og kunnskapen du har fått i denne enheten.