Utforska prestandascenarier

  • 5 minuter

För att bestämma hur du ska använda prestandaverktyg och funktioner är det viktigt att titta på prestanda för Azure SQL via scenarier.

Förstå vanliga prestandascenarier

En vanlig teknik för felsökning av SQL Server-prestanda är att undersöka om ett prestandaproblem är Körs (hög CPU) eller Väntar (väntar på en resurs). Följande diagram visar ett beslutsträd för att avgöra om ett problem med SQL Server-prestanda körs eller väntar, och hur du använder prestandaverktyg för att fastställa orsaken och lösningen.

Diagram över aktivitet i förhållande till väntetid.

Börja med att studera den övergripande resursanvändningen. För en vanlig SQL Server-distribution kan du använda verktyg som Prestandaövervakare i Windows eller högst upp i Linux. För Azure SQL kan du använda följande metoder:

  • Azure-portalen/PowerShell/aviseringar

    Azure Monitor har integrerade mått för att visa resursanvändning för Azure SQL. Du kan också ställa in aviseringar som söker efter olika resursanvändningstillstånd.

  • sys.dm_db_resource_stats

    För Azure SQL Database kan du titta på denna DMV för att visa CPU-, minnes- och I/O-resursanvändning för databasdistributionen. Denna DMV tar en ögonblicksbild av dessa data var 15:e sekund.

  • sys.server_resource_stats

    Denna DMV fungerar precis som sys.dm_db_resource_stats, men används till att visa resursanvändning angående CPU, minne och I/O i SQL Managed Instance. Denna DMV tar också en ögonblicksbild var 15:e sekund.

  • sys.dm_user_db_resource_governance

    För Azure SQL Database returnerar denna DMV de faktiska konfigurations- och kapacitetsinställningarna som används av resursstyrningsmekanismer i den aktuella databasen eller den elastiska poolen.

  • sys.dm_instance_resource_governance

    För Azure SQL Managed Instance returnerar denna DMV liknande information som sys.dm_user_db_resource_governance, men för den aktuella SQL Managed Instance.

Springa

Om du har fastställt att problemet är hög CPU-användning kallas detta ett scenario som körs. Ett scenario som körs kan handla om frågor som förbrukar resurser genom kompilering eller körning. Använd följande verktyg om du behöver ytterligare analyser:

  • Query Store

    Använd rapporterna om högst resursförbrukning i SSMS, katalogvyer i Query Store eller Query Performance Insight i Azure Portal (endast Azure SQL Database) om du vill hitta de frågor som förbrukar mest CPU-resurser.

  • sys.dm_exec_requests

    Använd denna DMV i Azure SQL för att få en ögonblicksbild av aktiva frågors tillstånd. Leta efter frågor med tillståndet RUNNABLE och väntetypen SOS_SCHEDULER_YIELD för att se om du har tillräckligt med processorkapacitet.

  • sys.dm_exec_query_stats

    Du kan använda den här DMV:n på ungefär samma sätt som Query Store för att hitta de mest resurskrävande frågorna. Den är bara tillgänglig för frågeplaner som cachelagras, medan Query Store ger en beständig historisk post med prestanda. Med denna DMV kan du också hitta frågeplanen för en cachelagrad fråga.

  • sys.dm_exec_procedure_stats

    Den ger information på samma sätt som sys.dm_exec_query_stats, men prestandainformationen kan visas för enskilda lagrade procedurer.

    När du har fastställt vilken fråga eller vilka frågor som förbrukar mest resurser kan du behöva undersöka om du har tillräckligt med CPU-resurser för din arbetsbelastning. Du kan felsöka frågeplaner med verktyg som förenklad frågeprofilering, SET-instruktioner, Query Store eller spårning av utökade händelser.

Väntan

Om prestandaproblemet inte verkar bero på hög CPU-resursanvändning kan det i stället orsakas av väntan på en resurs. Scenarier som innefattar väntan på resurser är:

  • I/O-väntetid
  • Låsväntetid
  • Spärrtid
  • Buffertpoolgränser
  • Minnestilldelningar
  • Borttagning av plancache

Om du vill utföra analys av väntande scenarier tittar du vanligtvis på följande verktyg:

  • sys.dm_os_wait_stats

    Använd den här DMV:n till att se de vanligaste väntetyperna för databasen eller instansen. Vilka väntetyper som är vanligast kan styra vilken åtgärd du ska vidta härnäst.

  • sys.dm_exec_requests

    Använd den här DMV:en för att hitta specifika väntetyper för aktiva frågor för att se vilken resurs de väntar på. Det här kan vara ett standardscenario med blockering beroende på andra användares lås.

  • sys.dm_os_waiting_tasks

    Du kan använda den här DMV:en för att hitta väntetyper för en viss uppgift för en specifik fråga som körs för närvarande, kanske för att se varför det tar längre tid än normalt. sys.dm_os_waiting_tasks innehåller den liveväntestatistik som sys.dm_os_wait_stats aggregeringar över tid.

  • Query Store

    Query Store innehåller rapporter och katalogvyer som visar en sammanställning av de väntetider som ligger i toppen för körning av frågeplaner. Det är viktigt att veta att en väntan på CPU motsvarar ett problem som körs .

Scenarier som är specifika för Azure SQL

Det finns vissa prestandascenarier som är specifika för Azure SQL, både körningsproblem och väntetider. Några exempel är loggstyrning, arbetsgränser, väntetider på tjänstnivån Affärskritisk och väntetider specifika för en Hyperskala-distribution.

Loggstyrning

Azure SQL kan använda logghastighetsstyrning till att framtvinga resursgränser för användning av transaktionsloggen. Du kan behöva det här till att säkerställa resursgränser och för att uppfylla ett utlovat serviceavtal. Loggstyrning kan ses via följande väntetyper:

  • LOG_RATE_GOVERNOR: väntar på Azure SQL Database
  • POOL_LOG_RATE_GOVERNOR: väntar på elastiska pooler
  • INSTANCE_LOG_GOVERNOR: väntar på Azure SQL Managed Instance
  • HADR_THROTTLE_LOG_RATE*: väntar på svarstid för Affärskritisk och geo-replikering

Arbetsgränser

SQL Server använder en arbetarpool med trådar, men har gränser för maximalt antal arbetare. Program med ett stort antal samtidiga användare kan närma sig de arbetsgränser som tillämpas för Azure SQL Database och SQL Managed Instance:

  • Azure SQL Database har gränser som baseras på tjänstnivå och storlek. Om du överskrider den här gränsen visas ett fel för nya frågor.
  • Vid den aktuella tidpunkten använder max worker threadsSQL Managed Instance , så arbetare som har passerat den här gränsen kan se THREADPOOL väntetider.

Affärskritisk HADR-väntan

Om du använder tjänstnivån Affärskritisk kan du oväntat se följande väntetyper:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Även om de här väntetiderna inte gör programmet långsammare kanske du inte förväntar dig att se dem. De visas vanligtvis bara om du använder en AlwaysOn-tillgänglighetsgrupp. På nivån Affärskritisk används tillgänglighetsgrupper för att implementera serviceavtal och tillgänglighetsfunktioner, de här väntetyperna är förväntade. Långa väntetider kan tyda på en flaskhals, som exempelvis I/O-latens eller en eftersläpande replik.

Storskalig datorarkitektur

Hyperskala-arkitekturen kan resultera i vissa unika väntetyper som har prefixet RBIO (en möjlig indikation på logghantering). Dessutom förbättras DMV:er, katalogvyer och utökade händelser för att visa mått för sidserverläsningar.

I nästa övning får du lära dig hur du övervakar och löser ett prestandaproblem för Azure SQL med hjälp av de verktyg och kunskaper som du har fått i den här lektionen.