Delen via

Diagnostische gegevens over het oplossen van problemen met SQL Hyperscale-prestaties

van toepassing op:Azure SQL Database-

Om prestatieproblemen in een Hyperscale-database op te lossen, zijn de algemene sql-prestatieafstemmingsmethoden het uitgangspunt van een prestatieonderzoek. Gezien de gedistribueerde architectuur van Hyperscale moeten er mogelijk aanvullende diagnostische gegevens worden overwogen. In dit artikel worden diagnostische gegevens van Hyperscale beschreven.

Verminderde wachttijden voor logfrequentie

Elke database en elastische pool in Azure SQL Database beheert het genereren van logboeken via beheer van logboeksnelheid. De limiet voor de logboeksnelheid wordt weergegeven in de primary_max_log_rate kolom in sys.dm_user_db_resource_governance.

Soms moet de logboekgeneratie op de primaire rekenreplica worden verminderd om service level agreements (SLA's) voor herstelmogelijkheden te onderhouden. Dit kan bijvoorbeeld gebeuren wanneer een paginaserver of een andere rekenreplica aanzienlijk achterloopt bij het toepassen van nieuwe logboekrecords van de logboekservice. Als er geen Hyperscale-componenten aanwezig zijn, kan het beheermechanisme voor loggeneratiesnelheid 150 MiB/s per database bereiken voor hardware geoptimaliseerd voor geheugen in de Premium-serie. Voor hardware uit de standaardreeks is de maximale logboeksnelheid 100 MiB/s per database. Voor elastische pools is de maximale logboekcapaciteit 150 MiB/s per pool voor geoptimaliseerde hardware uit de Premium-serie en Premium-serie Memory Optimized, en 125 MiB/s per pool voor andere hardware.

De volgende wachttypen worden weergegeven in sys.dm_os_wait_stats wanneer de logboeksnelheid wordt verlaagd:

Wachttype Reden
RBIO_RG_STORAGE Vertraagde logconsumptie door een paginaserver
RBIO_RG_DESTAGE Vertraagd logboekverbruik door de langetermijnopslag van logboeken
RBIO_RG_REPLICA Vertraagd logboekverbruik door een secundaire replica met hoge beschikbaarheid of een benoemde replica
RBIO_RG_GEOREPLICA Vertraagde logconsumptie door een geo-secundaire replica
RBIO_RG_DESTAGE Vertraagd logboekverbruik door de logboekservice
RBIO_RG_LOCALDESTAGE Vertraagd logboekverbruik door de logboekservice
RBIO_RG_STORAGE_CHECKPOINT Vertraagd logboekverbruik door een paginaserver vanwege traag databasecontrolepunt
RBIO_RG_MIGRATION_TARGET Vertraagd logboekverbruik door de niet-Hyperscale-database tijdens omgekeerde migratie

De sys.dm_hs_database_log_rate() dynamische beheerfunctie (DMF) biedt meer informatie om u te helpen inzicht te hebben in de snelheidsvermindering van logboeken, indien van toepassing. U kunt bijvoorbeeld zien welke specifieke secundaire replica achterloopt met het toepassen van logboekregels en wat de totale grootte is van het transactielogboek dat nog niet is toegepast.

Leesbewerkingen van paginaserver

De rekenreplica's cachen geen volledige kopie van de database lokaal. De gegevens die lokaal zijn voor de rekenreplica worden opgeslagen in de buffergroep (in het geheugen) en in de lokale RBPEX-cache (Resilient Buffer Pool Extension) die een subset bevat van de meest gebruikte gegevenspagina's. Deze lokale SSD-cache is proportioneel aangepast aan de rekengrootte. Elke paginaserver heeft daarentegen een volledige SSD-cache voor het gedeelte van de database die wordt onderhouden.

Wanneer een lees-I/O wordt uitgegeven op een rekenreplica, als de gegevens niet aanwezig zijn in de bufferpool of de lokale SSD-cache, wordt de pagina op de aangevraagde LSN (Log Sequence Number) opgehaald van de bijbehorende paginaserver. Leesbewerkingen van paginaservers zijn extern en zijn langzamer dan leesbewerkingen uit de lokale SSD-cache. Bij het oplossen van I/O-gerelateerde prestatieproblemen moeten we kunnen zien hoeveel IO's er zijn uitgevoerd via de relatief tragere paginaserverlezingen.

Verschillende dynamische beheerde weergaven (DMV's) en uitgebreide gebeurtenissen bevatten kolommen en velden waarmee het aantal externe leesbewerkingen van een paginaserver wordt opgegeven, wat kan worden vergeleken met de totale leesbewerkingen. Query Store legt ook paginaserver-leesbewerkingen vast in queryruntimestatistieken.

  • Kolommen voor het rapporteren van paginaserver-leesbewerkingen zijn beschikbaar in uitvoerings-DMV's en catalogusweergaven.

  • De velden die de paginaserver leest, komen voor in de volgende uitgebreide gebeurtenissen:

    • 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 kenmerken aanwezig zijn in de XML van het queryplan voor plannen die runtimestatistieken bevatten. Voorbeeld:

    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    Fooi

    Als u deze kenmerken wilt weergeven in het venster eigenschappen van het queryplan, is SSMS 18.3 of hoger vereist.

Statistieken van virtuele bestanden en IO-boekhouding

In Azure SQL Database is de sys.dm_io_virtual_file_stats() DMF één manier om database-I/O-statistieken, zoals IOPS, doorvoer en latentie, te bewaken. I/O-kenmerken in Hyperscale zijn anders vanwege de gedistribueerde architectuur. In deze sectie richten we ons op lees- en schrijf-I/O, zoals te zien is in deze DMF.

Voor Hyperscale zijn de relevante gegevens sys.dm_io_virtual_file_stats() als volgt:

  • De rijen waarin de database_id waarde overeenkomt met de waarde die wordt geretourneerd door de functie DB_ID , en waar de file_id waarde niet 2 is, correspondeert met paginaservers. Normaal gesproken komt elke rij overeen met één paginaserver. Voor grotere bestanden worden echter meerdere paginaservers gebruikt.

    • De rij met file_id 2 komt overeen met het transactielogboek.

  • De rijen waarin de waarde in de database_id kolom 0 is, komen overeen met de lokale SSD-cache op de rekenreplica.

Gebruik van lokale SSD-cache

Omdat de lokale SSD-cache bestaat op dezelfde rekenreplica waar de database-engine query's verwerkt, is I/O tegen deze cache sneller dan I/O op paginaservers. In een Hyperscale-database of elastische pool sys.dm_io_virtual_file_stats() beschikt u over speciale rijen die I/O-statistieken rapporteren voor de lokale SSD-cache. Deze rijen hebben de waarde 0 voor de kolom database_id. De volgende query retourneert bijvoorbeeld de I/O-statistieken van de lokale SSD-cache sinds het opstarten van de database.

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

Een verhouding van de geaggregeerde leesbewerkingen van de lokale SSD-cachebestanden tot de geaggregeerde leesbewerkingen van alle andere gegevensbestanden is de lokale SSD-cachetrefferverhouding. Deze metriek wordt verstrekt door de RBPEX cache hit ratio en RBPEX cache hit ratio base prestatiecounters, beschikbaar in de sys.dm_os_performance_counters DMV.

Gegevens worden gelezen

  • Wanneer lezingen worden uitgevoerd door de database-engine op een compute-replica, kunnen deze worden bediend door de lokale SSD-cache of door paginaservers, of door een combinatie van beide bij het lezen van meerdere pagina's.

  • Wanneer de rekenreplica enkele pagina's uit een specifiek gegevensbestand leest (bijvoorbeeld het bestand met file_id 1), als deze gegevens zich alleen in de lokale SSD-cache bevinden, wordt alle IO voor deze leesbewerking geregistreerd voor de lokale SSD-cachebestanden, waarbij database_id 0 is. Als een deel van die gegevens zich in de lokale SSD-cache bevindt en een deel ervan zich op paginaservers bevindt, wordt IO gedeeltelijk verantwoordelijk voor de lokale SSD-cachebestanden en gedeeltelijk naar de gegevensbestanden die overeenkomen met paginaservers.

  • Wanneer een rekenreplica een pagina op een bepaalde LSN aanvraagt van een paginaserver, wacht de leesbewerking op de rekenreplica totdat de paginaserver de aangevraagde LSN heeft bereikt voordat de pagina wordt geretourneerd. Voor elke leesbewerking van een pagina vanaf een server op de rekenreplica ziet u een PAGEIOLATCH_* wachttype als er gewacht wordt op die I/O. In Hyperscale bevat deze wachttijd zowel de tijd die nodig is om de aangevraagde pagina op de paginaserver op te halen naar de vereiste LSN en de tijd die nodig is om de pagina over te dragen van de paginaserver naar de rekenreplica.

  • Grote leesbewerkingen, zoals leesdoorloop, worden vaak uitgevoerd met behulp van spreidingsvergade leesbewerkingen. Hierdoor kan maximaal 4 MB worden gelezen als één lees-I/O. Wanneer de gegevens die worden gelezen zich echter in de lokale SSD-cache bevinden, worden deze leesbewerkingen als meerdere afzonderlijke leesbewerkingen van 8 kB verwerkt, omdat de buffergroep en de lokale SSD-cache altijd 8-KB-pagina's gebruiken. Hierdoor kan het aantal lees-IO's dat tegen de lokale SSD-cache wordt waargenomen groter zijn dan het werkelijke aantal IO's dat door de engine wordt uitgevoerd.

Gegevens schrijven

  • De primaire rekenreplica schrijft niet rechtstreeks naar paginaservers. In plaats daarvan worden logboekrecords van de logboekservice opnieuw afgespeeld op de bijbehorende paginaservers.

  • Schrijfbewerkingen op de compute-replica zijn voornamelijk schrijfbewerkingen naar de lokale SSD-cache (database_id 0). Voor schrijfbewerkingen die groter zijn dan 8 kB, met andere woorden, die worden uitgevoerd met gather-write-, wordt elke schrijfbewerking omgezet in meerdere afzonderlijke schrijfbewerkingen van 8 kB naar de lokale SSD-cache, omdat de buffergroep en de lokale SSD-cache altijd 8 KB-pagina's gebruiken. Als gevolg hiervan kan het aantal schrijf-IOs dat wordt gezien op basis van de lokale SSD-cache groter zijn dan het werkelijke aantal IOs dat door de engine wordt uitgevoerd.

  • Gegevensbestanden die niet database_id 0 zijn die overeenkomen met paginaservers, kunnen ook schrijfbewerkingen weergeven. In Hyperscale worden deze schrijfbewerkingen gesimuleerd, omdat rekenreplica's nooit rechtstreeks naar paginaservers schrijven. I/O-statistieken worden bijgehouden wanneer deze zich voordoen op de rekenreplica. Schrijf-IOPS, doorvoer en latentie op een rekenreplica voor andere gegevensbestanden dan database_id 0 weerspiegelen niet de werkelijke I/O-statistieken van schrijfbewerkingen die plaatsvinden op paginaservers.

Schrijfbewerkingen in logboeken

  • Op de primaire rekenreplica worden logschrijfbewerkingen bijgehouden in sys.dm_io_virtual_file_stats() onder file_id 2.

  • In tegenstelling tot beschikbaarheidsgroepen, worden de logboekrecords niet gehard op de secundaire replica wanneer een transactie wordt uitgevoerd op de primaire rekenreplica. In Hyperscale wordt het logboek beveiligd in de logboekservice en asynchroon toegepast op de secundaire replica's. Omdat schrijfbewerkingen van logboeken niet daadwerkelijk plaatsvinden op secundaire replica's, mag een registratie van logboek-I/O's in sys.dm_io_virtual_file_stats() op de secundaire replica's niet worden gebruikt als I/O-statistieken voor het transactielog.

Gegevens-IO in statistieken over resourcegebruik

In een niet-Hyperscale-database worden gecombineerde IOPS voor lezen en schrijven voor gegevensbestanden ten opzichte van de I/O-limiet voor resourcebeheergegevens gerapporteerd in sys.dm_db_resource_stats en sys.resource_stats weergaven, in de avg_data_io_percent kolom. De bijbehorende DMV's voor elastische pools zijn sys.dm_elastic_pool_resource_stats en sys.elastic_pool_resource_stats. Dezelfde waarden worden gerapporteerd als de Data IO Percentage Azure Monitor-metriek voor databases en elastische pools.

In een Hyperscale-database rapporteren deze kolommen en metrische gegevens over het gegevens-IO-gebruik ten opzichte van de limiet voor alleen lokale SSD-opslag op rekenreplica, waaronder I/O voor de lokale SSD-cache en de tempdb database. Een waarde van 100% in deze kolom geeft aan dat resourcebeheer IOPS voor lokale opslag beperkt. Als dit samenhangt met een prestatieprobleem, kunt u de werkbelasting afstemmen om minder IO te genereren of de rekengrootte verhogen om de hulpbronnenbeheerlimiet te vergroten Max Data IOPSlimiet. Het systeem telt voor het beheer van lokale SSD-cache-lees- en schrijfbewerkingen afzonderlijke IO's van 8 kB in plaats van grotere IO's die mogelijk door de database-engine worden uitgegeven.

Gegevens-IO voor paginaservers wordt niet gerapporteerd in weergaven voor resourcegebruik of via metrische gegevens van Azure Monitor, maar wordt gerapporteerd zoals eerder beschreven in sys.dm_io_virtual_file_stats().

Verwante inhoud

  • Last updated on