Udforsk scenarier med ydeevne

  • 5 minutter

Hvis du vil beslutte, hvordan du vil bruge ydeevneværktøjer og -funktioner, er det vigtigt at se på ydeevnen for Azure SQL via scenarier.

Forstå almindelige ydeevnescenarier

En almindelig teknik til fejlfinding af ydeevnen i SQL Server er at undersøge, om et problem med ydeevnen er Kørsel af (høj CPU) eller Venter (venter på en ressource). I følgende diagram vises et beslutningstræ, der bestemmer, om der kører eller venter et sql Server-problem, og hvordan du bruger ydeevneværktøjer til at bestemme årsagen og løsningen.

Diagram over kørsel i forhold til ventetid.

Først skal du se på det overordnede ressourceforbrug. I forbindelse med en standardinstallation af SQL Server kan du bruge værktøjer som Ydelsesmåler i Windows eller øverst i Linux. I Azure SQL kan du bruge følgende metoder:

  • Azure Portal/PowerShell/alerts

    Azure Monitor har integrerede målepunkter til at få vist ressourceforbruget for Azure SQL. Du kan også konfigurere beskeder for at søge efter betingelser for ressourceforbrug.

  • sys.dm_db_resource_stats

    I Forbindelse med Azure SQL Database kan du se denne DMV for at se cpu-, hukommelses- og I/O-ressourceforbrug for databaseinstallationen. Denne DMV tager et snapshot af disse data hvert 15. sekund.

  • sys.server_resource_stats

    Denne DMV fungerer på samme måde som sys.dm_db_resource_stats, men den bruges til at se ressourceforbruget for SQL Managed Instance for CPU, hukommelse og I/O. Denne DMV tager også et snapshot hvert 15. sekund.

  • sys.dm_user_db_resource_governance

    For Azure SQL Database returnerer denne DMV de faktiske konfigurationsindstillinger og kapacitetsindstillinger, der bruges af ressourcestyringsmekanismer i den aktuelle database eller elastiske pulje.

  • sys.dm_instance_resource_governance

    For Azure SQL Managed Instance returnerer denne DMV lignende oplysninger som sys.dm_user_db_resource_governance, men for den aktuelle SQL Managed Instance.

Løb

Hvis du har fundet ud af, at problemet er høj CPU-udnyttelse, kaldes det et kørende scenarie. Et kørende scenarie kan omfatte forespørgsler, der forbruger ressourcer via kompilering eller udførelse. Brug følgende værktøjer til yderligere analyse:

  • Forespørgselslager

    Brug de mest forbrugende ressourcerapporter i katalogvisninger af SSMS, Forespørgselslager eller Indsigt i forespørgselsydeevne på Azure Portal (kun Azure SQL Database) til at finde ud af, hvilke forespørgsler der bruger mest CPU-ressourcer.

  • sys.dm_exec_requests

    Brug denne DMV i Azure SQL til at få et øjebliksbillede af tilstanden for aktive forespørgsler. Søg efter forespørgsler med tilstanden RUNNABLE og en vent-type SOS_SCHEDULER_YIELD for at se, om du har tilstrækkelig CPU-kapacitet.

  • sys.dm_exec_query_stats

    Denne DMV kan bruges på samme måde som Forespørgselslager til at finde de mest ressourcekrævende forespørgsler. Den er kun tilgængelig for forespørgselsplaner, der cachelagres, mens Forespørgselslager giver en vedvarende oversigt over ydeevnen. Denne DMV giver dig også mulighed for at finde forespørgselsplanen for en cachelagret forespørgsel.

  • sys.dm_exec_procedure_stats

    Denne DMV indeholder oplysninger på samme måde som sys.dm_exec_query_stats, bortset fra at oplysninger om ydeevne kan vises på niveauet for lagrede procedurer.

    Når du har fundet ud af, hvilken forespørgsel eller hvilke forespørgsler der bruger flest ressourcer, skal du muligvis undersøge, om du har nok CPU-ressourcer til din arbejdsbelastning. Du kan foretage fejlfinding af forespørgselsplaner med værktøjer som letvægtsforespørgselsprofilering, SET-sætninger, forespørgselslager eller sporing af udvidede hændelser.

Venter

Hvis dit problem ikke ser ud til at være et højt CPU-ressourceforbrug, kan det være, at problemet med ydeevnen omfatter at vente på en ressource. Scenarier, der involverer ventetid på ressourcer, omfatter:

  • I/O-ventetider
  • Lås ventetider
  • Låseventetider
  • Buffergruppegrænser
  • Hukommelsestilskud
  • Fjernelse af plancache

Hvis du vil udføre analyser af ventende scenarier, vil du typisk se på følgende værktøjer:

  • sys.dm_os_wait_stats

    Brug denne DMV til at se de øverste ventetyper for databasen eller forekomsten. Dette kan hjælpe dig med, hvilken handling du skal udføre næste, afhængigt af de øverste ventetyper.

  • sys.dm_exec_requests

    Brug denne DMV til at finde bestemte ventetyper for aktive forespørgsler for at se, hvilken ressource de venter på. Dette kan være et standardblokeringsscenarie, der venter på låse fra andre brugere.

  • sys.dm_os_waiting_tasks

    Du kan bruge denne DMV til at finde ventetyper for en bestemt opgave for en bestemt forespørgsel, der kører i øjeblikket, måske for at se, hvorfor det tager længere tid end normalt. sys.dm_os_waiting_tasks indeholder statistikkerne over liveventetider, der sys.dm_os_wait_stats aggregeringer over tid.

  • Forespørgselslager

    Forespørgselslager indeholder rapporter og katalogvisninger, der viser en sammenlægning af de øverste ventetider for udførelse af forespørgselsplan. Det er vigtigt at vide, at en ventetid på CPU- svarer til et , der kører problem.

Scenarier, der er specifikke for Azure SQL

Der er nogle ydeevnescenarier, både kørende og venter, som er specifikke for Azure SQL. Disse omfatter logstyring, medarbejdergrænser, ventetider for forretningskritiske tjenesteniveauer og ventetider, der er specifikke for en Hyperscale-udrulning.

Logstyring

Azure SQL kan bruge styring af logfrekvens til at gennemtvinge ressourcegrænser for transaktionslogforbrug. Du skal muligvis bruge denne håndhævelse for at sikre ressourcegrænser og opfylde den lovede SLA. Logstyring kan ses af følgende ventetidstyper:

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

Grænser for arbejdere

SQL Server bruger en arbejderpulje af tråde, men har grænser for det maksimale antal arbejdere. Programmer med et stort antal samtidige brugere kan nærme sig de arbejdsgrænser, der gennemtvinges for Azure SQL Database og SQL Managed Instance:

  • Azure SQL Database har grænser, der er baseret på tjenesteniveau og -størrelse. Hvis du overskrider denne grænse, modtager en ny forespørgsel en fejl.
  • På nuværende tidspunkt bruger SQL Managed Instance max worker threads, så arbejdere, der overskrider denne grænse, kan se THREADPOOL ventetider.

Forretningskritiske HADR-ventetider

Hvis du bruger et tjenesteniveau, der er forretningskritisk, kan du muligvis uventet se følgende ventetidstyper:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Selvom disse ventetider muligvis ikke sinker dit program, forventer du muligvis ikke at se disse. De er normalt specifikke for brug af en always on-tilgængelighedsgruppe. Forretningskritiske niveauer bruger tilgængelighedsgruppeteknologi til at implementere SLA og tilgængelighedsfunktioner på et forretningskritisk serviceniveau, så disse ventetyper forventes. Lange ventetider kan indikere en flaskehals, f.eks. I/O-ventetid eller replika bag.

Hyperskalering

Hyperskaleringsarkitekturen kan resultere i nogle unikke ventetyper, der har præfikset RBIO- (en mulig indikation af logstyring). Derudover er DMV'er, katalogvisninger og udvidede hændelser forbedret for at vise målepunkter for sideserverlæsninger.

I den næste øvelse lærer du, hvordan du overvåger og løser et problem med ydeevnen for Azure SQL ved hjælp af de værktøjer og den viden, du har fået i dette undermodul.