Dela via

Diagnostik för felsökning av SQL Hyperscale-prestanda

  • Artikel

gäller för:Azure SQL Database

För att felsöka prestandaproblem i en Hyperskala-databas är allmänna SQL-prestandajusteringsmetoder startpunkten för alla prestandaundersökningar. Men med tanke på distribuerad arkitektur av hyperskala kan ytterligare diagnostikdata behöva beaktas. Den här artikeln beskriver Hyperskala-specifika diagnostikdata.

Minskad väntetid för loggfrekvenser

Varje databas och elastisk pool i Azure SQL Database hanterar logggenereringshastigheten via logghastighetsstyrning. I Hyperskala är logghastighetsstyrningsgränsen inställd på 105 MB/s, oavsett beräkningsstorlek. Det här värdet visas i kolumnen primary_max_log_rate i sys.dm_user_db_resource_governance.

Ibland måste logggenereringshastigheten på den primära beräkningsrepliken minskas för att upprätthålla serviceavtalen för återställning. Detta kan till exempel inträffa när en -sidserver eller en annan beräkningsreplik ligger betydligt efter med att tillämpa nya loggposter från loggtjänsten. Om inga Hyperskala-komponenter ligger efter tillåter mekanismen för logghastighetsstyrning att logggenereringshastigheten når 100 MiB/s. Det här är den effektiva maximala logggenereringshastigheten i alla Hyperskala-beräkningsstorlekar.

Not

Logggenereringshastigheten på 150 MiB/s är tillgänglig som en förhandsversionsfunktion för premiumserie- och premiumserieminne optimerat. Mer information och om du vill välja 150 MiB/s finns i Blogg: Förbättringar av Hyperskala i november 2024.

Följande väntetyper visas i sys.dm_os_wait_stats när loggfrekvensen minskas:

Väntetyp Förnuft
RBIO_RG_STORAGE Fördröjd loggförbrukning av en sidserver
RBIO_RG_DESTAGE Fördröjd loggförbrukning av långsiktig logglagring
RBIO_RG_REPLICA Fördröjd loggförbrukning av en sekundär HA-replik eller en namngiven replik
RBIO_RG_GEOREPLICA Fördröjd loggkonsumtion av en geografisk sekundär replik
RBIO_RG_DESTAGE Fördröjd loggförbrukning av loggtjänsten
RBIO_RG_LOCALDESTAGE Fördröjd loggförbrukning av loggtjänsten
RBIO_RG_STORAGE_CHECKPOINT Fördröjd loggförbrukning på en sidserver på grund av långsam kontrollpunkt för databasen
RBIO_RG_MIGRATION_TARGET Fördröjd loggförbrukning av icke-Hyperskala-databasen under omvänd migrering

Funktionen sys.dm_hs_database_log_rate() dynamisk hantering (DMF) innehåller ytterligare information som hjälper dig att förstå eventuella minskningar av loggfrekvensen. Den kan till exempel tala om för dig vilken specifik sekundär replik som ligger bakom att tillämpa loggposter och vilken total storlek den ännu inte tillämpade transaktionsloggen har.

Sidorserver läser

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 innehåller en delmängd av de datasidor som används oftast. Den här lokala SSD-cachen är proportionellt storleksanpassad till beräkningsstorleken. Varje sidserver har å andra sidan en fullständig SSD-cache för den del av databasen som den underhåller.

När en läs-I/O utförs på en beräkningreplika, om data inte finns i buffertpoolen eller i den lokala SSD-cachen, hämtas sidan med det begärda Loggsekvensnummer (LSN) från motsvarande sidserver. Läsningar från sidservrar är fjärranslutna och är långsammare än läsningar från den lokala SSD-cachen. När vi felsöker I/O-relaterade prestandaproblem måste vi kunna se hur många IO:er som gjordes via de relativt långsammare sidserverläsningarna.

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 även in sidserverläsningar i frågekörningsstatistik.

  • Kolumner för serverläsningar av rapportsidor är tillgängliga i körnings-DMVs och i katalogvyer.
  • Sidserverns fält för läsningar förekommer i följande utökade händelser:
    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query_store_execution_runtime_info
  • ActualPageServerReads / ActualPageServerReadAheads attribut finns i frågeplanens XML för planer som innehåller körningsstatistik. Till exempel: 
    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    Tips

    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 ett sätt att övervaka databas-I/O-statistik som IOPS, dataflöde och svarstid. I/O-egenskaper i Hyperskala skiljer sig på grund av dess distribuerade arkitektur. I det här avsnittet fokuserar vi på att läsa och skriva I/O enligt beskrivningen i denna DMF. I Hyperskala motsvarar varje datafil som visas i denna DMF en sidserver. DMF tillhandahåller också I/O-statistik för den lokala SSD-cachen på beräkningsrepliken och för transaktionsloggen.

Lokal SSD-cacheanvändning

Eftersom den lokala SSD-cachen finns på samma beräkningsreplik där databasmotorn bearbetar frågor är I/O mot den här cachen snabbare än I/O mot sidservrar. I en Hyperskala-databas eller elastisk pool har sys.dm_io_virtual_file_stats() en särskild radrapporterings-I/O-statistik för den lokala SSD-cachen. Den här raden har värdet 0 för både database_id och file_id kolumner. Frågan nedan returnerar till exempel den lokala SSD-cache-I/O-statistiken sedan databasens start.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Förhållandet mellan läsningar från den lokala SSD-cachen och aggregerade läsningar från alla andra datafiler är det lokala SSD-cachens träffförhållande. Det här måttet tillhandahålls av prestandaräknarna RBPEX cache hit ratio och RBPEX cache hit ratio base, som är tillgängliga i sys.dm_os_performance_counters DMV.

Dataläsningar

  • När läsningar utförs av databasmotorn på en beräkningsreplik kan de betjänas antingen av den lokala SSD-cachen, av sidservrarna eller av en kombination av de två om flera sidor läses.
  • När beräkningsrepliken läser vissa sidor från en specifik datafil, till exempel filen med file_id 1, om dessa data endast finns i den lokala SSD-cachen, redovisas all I/O för den här läsningen mot file_id 0. Om en del av dessa data finns i den lokala SSD-cachen och en del finns på sidservrar, redovisas I/O mot file_id 0 för den del som hanteras från den lokala SSD-cachen, och den del som hanteras från sidservrar redovisas mot motsvarande filer.
  • När en beräkningsreplik begär en sida på ett visst LSN från en sidserver, och om sidservern ännu inte har hunnit ikapp det begärda LSN, väntar läsningen på beräkningsrepliken tills sidservern kommer ikapp innan sidan returneras. För alla läsningar från en sidserver på compute-repliken visas en PAGEIOLATCH_*-väntetyp om den väntar på I/O-operationen. 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 läsningar framåt, görs ofta med hjälp av punktinsamlingsläsningar. På så sätt kan du läsa upp till 4 MB som en enda läs-I/O. Men när data som läss i den lokala SSD-cachen redovisas dessa läsningar som flera enskilda 8 KB-läsningar, eftersom buffertpoolen och den lokala SSD-cachen alltid använder 8 KB-sidor. Därför kan antalet läs-IO:er som visas mot den lokala SSD-cachen 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 återges loggposter från loggtjänsten på motsvarande sidservrar.
  • Skrivningar på beräkningsrepliken skrivs främst till den lokala SSD-cachen (file_id 0). För skrivningar som är större än 8 KB, med andra ord de som görs med samla in-skriv-, översätts varje skrivåtgärd till flera 8 KB enskilda skrivningar till den lokala SSD-cachen eftersom buffertpoolen och den lokala SSD-cachen alltid använder 8 KB-sidor. Därför kan antalet skriv-IO:er som visas mot den lokala SSD-cachen vara större än det faktiska antalet IO:er som utförs av motorn.
  • Andra datafiler än file_id 0 som motsvarar sidservrar kan också visa skrivningar. I Hyperskala simuleras dessa skrivningar eftersom beräkningsrepliker aldrig skrivs direkt till sidservrar. I/O-statistik redovisas när de uppstår på beräkningsenheten. IOPS, dataflöde och svarstid som visas på en beräkningsreplik för andra datafiler än file_id 0 återspeglar inte den faktiska I/O-statistiken för skrivningar som sker på sidservrar.

Loggskrivningar

  • På den primära beräkningsrepliken redovisas en loggskrivning i sys.dm_io_virtual_file_stats() under file_id 2.
  • Till skillnad från i AlwaysOn-tillgänglighetsgrupper, när en transaktion bekräftas på den primära beräkningsrepliken, så härdas inte loggposter på den sekundära repliken. I Hyperscale hårdgörs loggen i loggtjänsten och appliceras asynkront på de sekundära replikerna. Eftersom loggskrivningar faktiskt inte sker på sekundära repliker, bör all redovisning av logg-IO:er i sys.dm_io_virtual_file_stats() på de sekundära replikerna inte användas som transaktionsloggens I/O-statistik.

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 resursstyrning data-IOPS-gräns, i sys.dm_db_resource_stats och sys.resource_stats vyer i kolumnen avg_data_io_percent. Motsvarande DMV:er för elastiska pooler är sys.dm_elastic_pool_resource_stats och sys.elastic_pool_resource_stats. Samma värden rapporteras som I/O-procentandel Azure Monitor-mått för databaser och elastiska pooler.

I en Hyperskala-databas rapporterar dessa kolumner och mått om data-IOPS-användningen i förhållande till gränsen för lokal SSD-lagring endast på beräkningsreplik, vilket inkluderar I/O mot den lokala SSD-cachen och i tempdb-databasen. 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 så att den genererar mindre I/O eller ökar beräkningsstorleken för att öka resursstyrningen Max Data IOPS-gräns. För resursstyrning av lokala SSD-cachelä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 databasmotorn.

Data-I/O mot sidservrar rapporteras inte i resursanvändningsvyer eller via Azure Monitor-mått, men rapporteras i sys.dm_io_virtual_file_stats() enligt beskrivningen tidigare.

Relaterat innehåll