Felsökning av prestandadiagnostik för SQL Hyperskala

  • Artikel

Gäller för:Azure SQL Database

För att felsöka prestandaproblem i en Hyperskala-databas är allmänna prestandajusteringsmetoder på Azure SQL Database-beräkningsnoden startpunkten för en prestandaundersökning. Men med tanke på den distribuerade arkitekturen i Hyperskala har ytterligare diagnostik lagts till för att hjälpa till. Den här artikeln beskriver Hyperskala-specifika diagnostikdata.

Väntetider för logghastighetsbegränsning

Varje Azure SQL Database-tjänstmål har hastighetsbegränsningar för logggenerering som tillämpas via logghastighetsstyrning. I Hyperskala är loggstyrningsgränsen inställd på 105 MB/s, oavsett tjänstnivå. Det här värdet visas i primary_max_log_rate kolumnen i sys.dm_user_db_resource_governance.

Det finns dock tillfällen då logggenereringshastigheten på den primära beräkningsrepliken måste begränsas för att upprätthålla serviceavtal för återställningsbarhet. Den här begränsningen sker när en sidserver eller en annan beräkningsreplik ligger betydligt bakom tillämpningen av nya loggposter från loggtjänsten. Om inga sidservrar eller repliker ligger bakom tillåter begränsningsmekanismen att logggenereringshastigheten når 100 MB/s. Det här är den effektiva maximala logggenereringshastigheten i alla tjänstmål för Hyperskala.

Följande väntetyper (i sys.dm_os_wait_stats) beskriver orsakerna till att loggfrekvensen kan begränsas på den primära beräkningsrepliken:

Väntetyp Beskrivning
RBIO_RG_STORAGE Inträffar när en logggenereringshastighet för primär beräkningsnod i Hyperskala-databasen begränsas på grund av fördröjd loggförbrukning på sidservern eller sidservrarna.
RBIO_RG_DESTAGE Inträffar när genereringshastigheten för beräkningsnodloggar i Hyperskala-databasen begränsas på grund av fördröjd loggförbrukning av den långsiktiga logglagringen.
RBIO_RG_REPLICA Inträffar när genereringshastigheten för beräkningsnodloggar i Hyperskala-databasen begränsas på grund av fördröjd loggförbrukning av de läsbara sekundära replikerna.
RBIO_RG_GEOREPLICA Inträffar när genereringshastigheten för beräkningsnodloggar i Hyperskala-databasen begränsas på grund av fördröjd loggförbrukning av den geo-sekundära repliken.
RBIO_RG_LOCALDESTAGE Inträffar när genereringshastigheten för beräkningsnodloggar i Hyperskala-databasen begränsas på grund av fördröjd loggförbrukning av loggtjänsten.

Sidserverläsningar

Beräkningsreplikerna cachelagrar inte en fullständig kopia av databasen lokalt. Data som är lokala för beräkningsrepliken lagras i buffertpoolen (i minnet) och i RBPEX-cacheminnet (local resilient buffer pool extension) som är en partiell cache (som inte täcker) datasidor. Den här lokala RBPEX-cachen är proportionellt storleksanpassad till beräkningsstorleken och är tre gånger så mycket som minnet på beräkningsnivån. RBPEX liknar buffertpoolen eftersom den har de data som används oftast. Varje sidserver har å andra sidan en täckande RBPEX-cache för den del av databasen som den underhåller.

När en läsning utfärdas på en beräkningsreplik, om data inte finns i buffertpoolen eller den lokala RBPEX-cachen, utfärdas ett getPage-funktionsanrop (pageId, LSN) och sidan hämtas från motsvarande sidserver. Läsningar från sidservrar är fjärrläsningar och är därför långsammare än läsningar från den lokala RBPEX. När vi felsöker I/O-relaterade prestandaproblem måste vi kunna se hur många IO:er som gjordes via relativt långsammare fjärrsidesserverläsningar.

Flera dynamiska hanterade vyer (DMV: er) och utökade händelser har kolumner och fält som anger antalet fjärrläsningar från en sidserver, vilket kan jämföras med de totala läsningarna. Query Store samlar också in fjärrläsningar som en del av frågekörningens tidsstatistik.

<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />

Kommentar

Om du vill visa dessa attribut i fönstret för frågeplansegenskaper krävs SSMS 18.3 eller senare.

Statistik för virtuella filer och I/O-redovisning

I Azure SQL Database är sys.dm_io_virtual_file_stats() DMF det primära sättet att övervaka SQL Database IO. I/O-egenskaper i Hyperskala skiljer sig på grund av dess distribuerade arkitektur. I det här avsnittet fokuserar vi på I/O (läsningar och skrivningar) till datafiler som visas i denna DMF. I Hyperskala motsvarar varje datafil som visas i denna DMF en fjärrsideserver. RBPEX-cachen som nämns här är en lokal SSD-baserad cache, som är en icke-täckande cache på beräkningsrepliken.

Lokal RBPEX-cacheanvändning

Lokal RBPEX-cache finns på beräkningsrepliken på lokal SSD-lagring. Därför är I/O mot den här cachen snabbare än I/O mot fjärrsideservrar. För närvarande har sys.dm_io_virtual_file_stats() i en Hyperskala-databas en särskild rad som rapporterar I/O mot den lokala RBPEX-cachen på beräkningsrepliken. Den här raden har värdet 0 för både database_id kolumner och file_id . Frågan nedan returnerar till exempel RBPEX-användningsstatistik sedan databasens start.

select * from sys.dm_io_virtual_file_stats(0,NULL);

Ett förhållande mellan läsningar som görs på RBPEX och aggregerade läsningar som görs på alla andra datafiler ger RBPEX-cacheträffförhållande. Räknaren RBPEX cache hit ratio exponeras också i prestandaräknarna DMV sys.dm_os_performance_counters.

Dataläsningar

  • När läsningar utfärdas av SQL Server-databasmotorn på en beräkningsreplik kan de hanteras antingen av den lokala RBPEX-cachen eller av fjärrsideservrar eller av en kombination av de två om de läser flera sidor.
  • När beräkningsrepliken läser vissa sidor från en specifik fil, till exempel file_id 1, om dessa data endast finns i den lokala RBPEX-cachen, redovisas all I/O för den här läsningen mot file_id 0 (RBPEX). Om en del av dessa data finns i den lokala RBPEX-cachen och en del finns på en fjärrsideserver, redovisas I/O mot file_id 0 för den del som hanteras från RBPEX, och den del som hanteras från fjärrsideservern redovisas mot file_id 1.
  • När en beräkningsreplik begär en sida på en viss LSN från en sidserver väntar läsningen på beräkningsrepliken tills sidservern kommer ikapp innan sidan returneras till beräkningsrepliken om sidservern inte har kommit ikapp den begärda LSN-filen. För alla läsningar från en sidserver på beräkningsrepliken visas PAGEIOLATCH_* väntetyp om den väntar på den I/O-filen. I Hyperskala omfattar den här väntetiden både tiden för att komma ikapp den begärda sidan på sidservern till det LSN som krävs och den tid som krävs för att överföra sidan från sidservern till beräkningsrepliken.
  • Stora läsningar, till exempel read-ahead, görs ofta med hjälp av "Scatter-Gather"-läsningar. Detta tillåter läsningar på upp till 4 MB sidor åt gången, vilket anses vara en enda läsning i SQL Server-databasmotorn. Men när data som läss i RBPEX redovisas dessa läsningar som flera enskilda 8 KB-läsningar, eftersom buffertpoolen och RBPEX alltid använder 8 KB-sidor. Därför kan antalet läs-IO:er som visas mot RBPEX vara större än det faktiska antalet IO:er som utförs av motorn.

Dataskrivningar

  • Den primära beräkningsrepliken skriver inte direkt till sidservrar. I stället spelas loggposter från loggtjänsten upp på motsvarande sidservrar.
  • Skrivningar som sker på beräkningsrepliken skrivs främst till den lokala RBPEX (file_id 0). För skrivningar på logiska filer som är större än 8 KB, med andra ord de som görs med Gather-write, översätts varje skrivåtgärd till flera 8 KB individuella skrivningar till RBPEX eftersom buffertpoolen och RBPEX alltid använder 8 KB-sidor. Därför kan antalet skriv-IO:er som visas mot RBPEX vara större än det faktiska antalet IO:er som utförs av motorn.
  • Icke-RBPEX-filer eller andra datafiler än file_id 0 som motsvarar sidservrar, visar också skrivningar. På tjänstnivån Hyperskala simuleras dessa skrivningar eftersom beräkningsreplikerna aldrig skrivs direkt till sidservrar. Skriv-IOPS och dataflöde redovisas när de inträffar på beräkningsrepliken, men svarstiden för andra datafiler än file_id 0 återspeglar inte den faktiska svarstiden för sidserverskrivningar.

Loggskrivningar

  • I den primära beräkningen redovisas en loggskrivning i file_id 2 av sys.dm_io_virtual_file_stats. En loggskrivning på primär beräkning är en skrivning till loggens landningszon.
  • Loggposter är inte härdade på den sekundära repliken vid en incheckning. I Hyperskala tillämpas loggen av loggtjänsten på de sekundära replikerna asynkront. Eftersom loggskrivningar faktiskt inte sker på sekundära repliker är all redovisning av logg-IO:er på de sekundära replikerna endast i spårningssyfte.

Data-I/O i resursanvändningsstatistik

I en icke-Hyperskala-databas rapporteras kombinerad läs- och skriv-IOPS mot datafiler i förhållande till IOPS-gränsen för resursstyrningsdata i sys.dm_db_resource_stats och sys.resource_stats vyer i avg_data_io_percent kolumnen. Samma värde rapporteras i Azure-portalen som I/O-procentandel för data.

I en Hyperskala-databas rapporterar den här kolumnen om data-IOPS-användning i förhållande till gränsen för endast lokal lagring på beräkningsreplik, särskilt IO mot RBPEX och tempdb. Ett värde på 100 % i den här kolumnen anger att resursstyrning begränsar IOPS för lokal lagring. Om detta korreleras med ett prestandaproblem justerar du arbetsbelastningen för att generera mindre I/O eller ökar databastjänstmålet för att öka resursstyrningens maxgräns för data-IOPS. För resursstyrning av RBPEX-läsningar och skrivningar räknar systemet enskilda 8 KB-IO:er i stället för större IO:er som kan utfärdas av SQL Server-databasmotorn.

Data-I/O mot fjärrsideservrar rapporteras inte i resursanvändningsvyer eller i portalen, men rapporteras i sys.dm_io_virtual_file_stats() DMF, som tidigare nämnts.

Ytterligare resurser