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

Artikel
07/31/2023

Van toepassing op: Azure SQL Database

Om prestatieproblemen in een Hyperscale-database op te lossen, vormen algemene methodologieën voor het afstemmen van prestaties op het Rekenknooppunt van Azure SQL Database het uitgangspunt van een prestatieonderzoek. Gezien de gedistribueerde architectuur van Hyperscale zijn er echter aanvullende diagnostische gegevens toegevoegd om u te helpen. In dit artikel worden diagnostische gegevens van Hyperscale beschreven.

Wachttijden voor logboeksnelheid

Elke Azure SQL Database-servicedoelstelling heeft snelheidslimieten voor het genereren van logboeken die worden afgedwongen via beheer van logboeksnelheid. In Hyperscale is de limiet voor logboekbeheer ingesteld op 105 MB per seconde, ongeacht het serviceniveau. Deze waarde wordt weergegeven in de primary_max_log_rate kolom in sys.dm_user_db_resource_governance.

Er zijn echter momenten waarop de snelheid van het genereren van logboeken op de primaire rekenreplica moet worden beperkt om sla's voor herstelbaarheid te behouden. Deze beperking treedt op wanneer een paginaserver of een andere rekenreplica aanzienlijk achter het toepassen van nieuwe logboekrecords van de logboekservice ligt. Als er zich geen paginaservers of replica's bevinden, kan met het beperkingsmechanisme de snelheid voor het genereren van logboeken 100 MB/s bereiken. Dit is de effectieve maximale snelheid voor het genereren van logboeken in alle Hyperscale-servicedoelstellingen.

In de volgende wachttypen (in sys.dm_os_wait_stats) worden de redenen beschreven waarom de logboeksnelheid kan worden beperkt op de primaire rekenreplica:

Wachttype	Omschrijving
RBIO_RG_STORAGE	Treedt op wanneer een primaire generatiesnelheid van het rekenknooppunt van een Hyperscale-database wordt beperkt vanwege vertraagd logboekverbruik op de paginaserver(s).
RBIO_RG_DESTAGE	Treedt op wanneer het genereren van logboeken in een Hyperscale-database wordt beperkt vanwege vertraagd logboekverbruik door de langetermijnopslag van logboeken.
RBIO_RG_REPLICA	Treedt op wanneer het genereren van logboeken van een Hyperscale-database wordt beperkt vanwege vertraagd logboekverbruik door de leesbare secundaire replica('s).
RBIO_RG_GEOREPLICA	Treedt op wanneer het genereren van logboeken van een Hyperscale-database wordt beperkt vanwege vertraagd logboekverbruik door de geo-secundaire replica.
RBIO_RG_LOCALDESTAGE	Treedt op wanneer het genereren van logboeken van een Hyperscale-database wordt beperkt vanwege vertraagd logboekverbruik door de logboekservice.

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 gedeeltelijke (niet-bedekte) cache van gegevenspagina's is. Deze lokale RBPEX-cache is proportioneel aangepast aan de rekengrootte en is drie keer het geheugen van de rekenlaag. RBPEX is vergelijkbaar met de buffergroep omdat deze de meest gebruikte gegevens bevat. Elke paginaserver heeft daarentegen een bedekte RBPEX-cache voor het gedeelte van de database dat wordt onderhouden.

Wanneer een leesbewerking wordt uitgegeven op een rekenreplica, wordt een getPage-functieaanroep (pageId, LSN) uitgegeven als de gegevens niet bestaan in de buffergroep of lokale RBPEX-cache en wordt de pagina opgehaald van de bijbehorende paginaserver. Leesbewerkingen van paginaservers zijn externe leesbewerkingen en zijn dus langzamer dan leesbewerkingen van de lokale RBPEX. Bij het oplossen van I/O-gerelateerde prestatieproblemen moeten we kunnen zien hoeveel IOS zijn uitgevoerd via relatief tragere leesbewerkingen op de externe paginaserver.

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 externe leesbewerkingen vast als onderdeel van de uitvoeringstijdstatistieken van de query.

Leesbewerkingen van kolommen voor rapportpaginaservers zijn beschikbaar in DMV's en catalogusweergaven, zoals:
Leesbewerkingen op de paginaserver worden toegevoegd aan 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 worden toegevoegd aan het queryplan-XML voor werkelijke plannen. Bijvoorbeeld:

Notitie

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 het sys.dm_io_virtual_file_stats() DMF de primaire manier om SQL Database IO te bewaken. I/O-kenmerken in Hyperscale verschillen vanwege de gedistribueerde architectuur. In deze sectie richten we ons op IO (lees- en schrijfbewerkingen) naar gegevensbestanden, zoals te zien is in deze DMF. In Hyperscale komt elk gegevensbestand dat in deze DMF wordt weergegeven overeen met een externe paginaserver. De RBPEX-cache die hier wordt vermeld, is een lokale ssd-cache, die een niet-bedekte cache op de rekenreplica is.

Lokaal RBPEX-cachegebruik

Lokale RBPEX-cache bestaat op de rekenreplica, op lokale SSD-opslag. Io op basis van deze cache is dus sneller dan IO ten opzichte van externe paginaservers. Momenteel heeft sys.dm_io_virtual_file_stats() in een Hyperscale-database een speciale rij die de IO rapporteert aan de lokale RBPEX-cache op de rekenreplica. Deze rij heeft de waarde 0 voor zowel als database_idfile_id kolommen. De onderstaande query retourneert bijvoorbeeld RBPEX-gebruiksstatistieken sinds het opstarten van de database.

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

Een verhouding van leesbewerkingen die zijn uitgevoerd op RBPEX tot geaggregeerde leesbewerkingen die zijn uitgevoerd op alle andere gegevensbestanden, biedt de RBPEX cache hit ratio. De teller RBPEX cache hit ratio wordt ook weergegeven in de prestatiemeteritems DMV sys.dm_os_performance_counters.

Gegevens worden gelezen

Wanneer leesbewerkingen worden uitgegeven door de SQL Server-database-engine op een rekenreplica, kunnen deze worden geleverd door de lokale RBPEX-cache, of door externe paginaservers, of door een combinatie van de twee als u meerdere pagina's leest.
Wanneer de rekenreplica enkele pagina's uit een specifiek bestand leest, bijvoorbeeld file_id 1, als deze gegevens zich alleen in de lokale RBPEX-cache bevinden, wordt alle IO voor deze leesbewerking verwerkt op basis van file_id 0 (RBPEX). Als een deel van die gegevens zich in de lokale RBPEX-cache bevindt en een deel zich op een externe paginaserver bevindt, wordt IO geaccountd naar file_id 0 voor het onderdeel dat wordt geleverd vanuit RBPEX en wordt het deel dat vanaf de externe paginaserver wordt geleverd, verwerkt naar file_id 1.
Wanneer een berekeningsreplica een pagina op een bepaalde LSN aanvraagt vanaf een paginaserver, als de paginaserver de aangevraagde LSN niet heeft opgepikt, wacht de leesbewerking op de rekenreplica totdat de paginaserver bijkomt voordat de pagina wordt geretourneerd naar de rekenreplica. Voor leesbewerkingen van een paginaserver op de rekenreplica ziet u het wachttype PAGEIOLATCH_* als deze wacht 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 voorlezen, worden vaak uitgevoerd met Spreidings-Gather-leesbewerkingen. Hierdoor kunnen maximaal 4 MB aan pagina's tegelijk worden gelezen, als één leesbewerking in de SQL Server-database-engine. Wanneer gegevens echter worden gelezen in RBPEX, worden deze leesbewerkingen als meerdere afzonderlijke leesbewerkingen van 8 kB verwerkt, omdat de buffergroep en RBPEX altijd 8 KB-pagina's gebruiken. Als gevolg hiervan kan het aantal lees-IO's dat is gezien ten opzichte van RBPEX groter zijn dan het werkelijke aantal IOS dat door de engine wordt uitgevoerd.

Schrijfbewerkingen voor gegevens

De primaire rekenreplica schrijft niet rechtstreeks naar paginaservers. In plaats daarvan worden logboekrecords van de logboekservice opnieuw afgespeeld op bijbehorende paginaservers.
Schrijfbewerkingen op de rekenreplica zijn voornamelijk schrijfbewerkingen naar de lokale RBPEX (file_id 0). Voor schrijfbewerkingen op logische bestanden die groter zijn dan 8 kB, met andere woorden schrijfbewerkingen die worden uitgevoerd met Gather-write, wordt elke schrijfbewerking omgezet in meerdere afzonderlijke schrijfbewerkingen van 8 kB naar RBPEX, omdat de buffergroep en RBPEX altijd 8-KB-pagina's gebruiken. Als gevolg hiervan kan het aantal schrijf-IO's dat wordt gezien ten opzichte van RBPEX groter zijn dan het werkelijke aantal IOs dat door de engine wordt uitgevoerd.
Niet-RBPEX-bestanden of gegevensbestanden anders dan file_id 0 die overeenkomen met paginaservers, geven ook schrijfbewerkingen weer. In de Hyperscale-servicelaag worden deze schrijfbewerkingen gesimuleerd, omdat de rekenreplica's nooit rechtstreeks naar paginaservers schrijven. Schrijf-IOPS en doorvoer worden bijgehouden op de berekeningsreplica, maar latentie voor andere gegevensbestanden dan file_id 0 weerspiegelt niet de werkelijke latentie van paginaserverschrijfbewerkingen.

Schrijfbewerkingen in logboeken

Op de primaire berekening wordt een schrijfbewerking voor logboeken geregistreerd in file_id 2 van sys.dm_io_virtual_file_stats. Een logboek schrijven op primaire rekenkracht is een schrijfbewerking naar de landingszone voor logboeken.
Logboekrecords worden niet gehard op de secundaire replica bij een doorvoer. In Hyperscale wordt het logboek asynchroon toegepast door de logboekservice op de secundaire replica's. Omdat logboekschrijfbewerkingen niet daadwerkelijk plaatsvinden op secundaire replica's, is een boekhouding van logboek-IOs op de secundaire replica's alleen bedoeld voor traceringsdoeleinden.

Gegevens-IO in statistieken over resourcegebruik

In een niet-Hyperscale-database worden gecombineerde IOPS voor lezen en schrijven ten opzichte van de IOPS-limiet voor resourcebeheergegevens gerapporteerd in sys.dm_db_resource_stats - en sys.resource_stats weergaven, in de avg_data_io_percent kolom. Dezelfde waarde wordt gerapporteerd in Azure Portal als het gegevens-IO-percentage.

In een Hyperscale-database rapporteert deze kolom over het IOPS-gebruik van gegevens ten opzichte van de limiet voor alleen lokale opslag op rekenreplica, met name IO ten opzichte van RBPEX en tempdb. Een waarde van 100% in deze kolom geeft aan dat resourcebeheer IOPS voor lokale opslag beperkt. Als dit is gecorreleerd met een prestatieprobleem, past u de workload af om minder IO te genereren of verhoogt u de databaseservicedoelstelling om de limiet voor maximale gegevens-IOPS voor resourcebeheer te verhogen. Voor resourcebeheer van RBPEX-lees- en schrijfbewerkingen telt het systeem afzonderlijke IOS van 8 kB in plaats van grotere IOS's die kunnen worden uitgegeven door de SQL Server-database-engine.

Gegevens-I/O voor externe paginaservers wordt niet gerapporteerd in resourcegebruikweergaven of in de portal, maar wordt gerapporteerd in de sys.dm_io_virtual_file_stats() DMF, zoals eerder is vermeld.

Aanvullende bronnen

Zie vCore-servicelaag vCore-limieten voor vCore-limieten voor vCores voor vCore-resourcelimieten voor een Individuele Hyperscale-database
Voor het bewaken van Azure SQL Databases schakelt u Azure Monitor SQL Insights in (preview)
Zie Queryprestaties in Azure SQL Database afstemmen voor het afstemmen van de prestaties van Azure SQL Database
Zie Prestatiebewaking met Behulp van Query Store voor het afstemmen van prestaties met Behulp van Query Store
Zie Prestaties van Azure SQL Database bewaken met dynamische beheerweergaven voor DMV-bewakingsscripts