Delen via

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

  • Artikel

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. In Hyperscale wordt de limiet voor logboeksnelheidsbeheer ingesteld op 105 MB/s, ongeacht de rekenkracht. Deze waarde wordt weergegeven in de kolom primary_max_log_rate in sys.dm_user_db_resource_governance.

Soms is het noodzakelijk om de logboekgeneratie op de primaire rekenreplica te verminderen om de SLA's voor herstelbaarheid te behouden. 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-onderdelen aanwezig zijn, staat het mechanisme voor het beheersen van de logboekgeneratiesnelheid toe dat de snelheid van logboekgeneratie 100 MiB/s kan bereiken. Dit is de effectieve maximale snelheid voor het genereren van logboeken in alle Rekengrootten van Hyperscale.

Notitie

De loggeneratiesnelheid van 150 MiB/s is beschikbaar als een optionele previewfunctie voor de Premium-serie en geheugen-geoptimaliseerde Premium-serie. Zie Blog: verbeteringen van Hyperscale in november 2024voor meer informatie en om u aan te kiezen voor 150 MiB/s.

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 aanvullende details om u te helpen begrijpen of er sprake is van logboekreductie, 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 rapportage van paginaservergelezen zijn beschikbaar in uitvoering DMVs en catalogusweergaven.
  • Velden die door de paginaserver worden gelezen, zijn aanwezig 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. Bijvoorbeeld: 
    <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. In Hyperscale komt elk gegevensbestand dat in deze DMF wordt weergegeven overeen met een paginaserver. De DMF biedt ook I/O-statistieken voor de lokale SSD-cache op de rekenreplica en voor het transactielogboek.

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 heeft sys.dm_io_virtual_file_stats() een speciale rij die de I/O-statistieken voor de lokale SSD-cache rapporteert. Deze rij heeft de waarde van 0 voor zowel database_id als file_id kolommen. De onderstaande 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 leesbewerkingen van de lokale SSD-cache 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 op basis van file_id 0. Als een deel van die gegevens zich in de lokale SSD-cache bevindt en een ander deel op de paginaservers, wordt IO toegeschreven aan file_id 0 voor het deel dat vanuit de lokale SSD-cache wordt geleverd, en wordt het deel dat door de paginaservers wordt geleverd, toegeschreven aan de bijbehorende bestanden.
  • Wanneer een computer-replica een pagina opvraagt van een paginaserver op een bepaalde LSN, als de paginaserver nog niet bijgewerkt is tot de aangevraagde LSN, wacht de leesactie op de computer-replica totdat de paginaserver bijgewerkt is voordat de pagina wordt geretourneerd. Voor een leesverzoek van een paginaserver op de berekeningsreplica ziet u het wachttype PAGEIOLATCH_* als deze op die I/O wacht. 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 (file_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 file_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. IOPS, doorvoer en latentie op een rekenreplica voor andere gegevensbestanden dan file_id 0 weerspiegelen niet de werkelijke I/O-statistieken van schrijfbewerkingen die op paginaservers plaatsvinden.

Schrijfbewerkingen in logboeken

  • Op de primaire rekengeraamte wordt een schrijfbewerking voor logboeken in sys.dm_io_virtual_file_stats() onder file_id 2 geregistreerd.
  • In tegenstelling tot bij AlwaysOn Availability Groups, worden logboekrecords niet vastgelegd op de secundaire replica wanneer een transactie wordt vastgelegd 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 tegen gegevensbestanden, ten opzichte van de resourcebeheer IOPS-limiet , gerapporteerd in de weergaven sys.dm_db_resource_stats en sys.resource_stats, in de kolom avg_data_io_percent. 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 meetwaarden over het IOPS-gebruik van gegevens in verhouding tot de limiet, uitsluitend voor lokale SSD-opslag op de compute-replica. Dit omvat I/O op de lokale SSD-cache en in 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. Voor resourcebeheer van lokale SSD-cache-lees- en schrijfbewerkingen telt het systeem afzonderlijke IOS van 8 kB in plaats van grotere IOS's die kunnen worden uitgegeven door de database-engine.

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

Verwante inhoud