Diagnostics de résolution des problèmes de performances Hyperscale SQLSQL Hyperscale performance troubleshooting diagnostics

S’APPLIQUE À : Azure SQL Database

Pour résoudre les problèmes de performances dans une base de données Hyperscale, les méthodologies d’optimisation des performances générales sur le nœud de calcul Azure SQL Database sont le point de départ d’une investigation des performances.To troubleshoot performance problems in a Hyperscale database, general performance tuning methodologies on the Azure SQL Database compute node is the starting point of a performance investigation. Cependant, compte tenu de l’architecture distribuée d’Hyperscale, des diagnostics supplémentaires ont été ajoutés pour faciliter les opérations.However, given the distributed architecture of Hyperscale, additional diagnostics have been added to assist. Cet article décrit les données de diagnostic propres à Hyperscale.This article describes Hyperscale-specific diagnostic data.

Attentes liées à la limitation du taux de journalisationLog rate throttling waits

Chaque niveau de service Azure SQL Database présente des limites de taux de génération de journaux qui sont appliquées via la gouvernance du taux de journalisation.Every Azure SQL Database service level has log generation rate limits enforced via log rate governance. Dans Hyperscale, la limite de génération de journaux actuellement définie est de 100 Mo/s, quel que soit le niveau de service.In Hyperscale, the log generation limit is currently set to 100 MB/sec, regardless of the service level. Cependant, le taux de génération de journaux doit parfois être limité sur le réplica de calcul principal pour respecter les contrats SLA de récupération.However, there are times when the log generation rate on the primary compute replica has to be throttled to maintain recoverability SLAs. Cette limitation se produit quand un serveur de pages ou un autre réplica de calcul tarde à appliquer les nouveaux enregistrements de journal du service de journal.This throttling happens when a page server or another compute replica is significantly behind applying new log records from the log service.

Les types d’attente suivants (dans sys.dm_os_wait_stats) décrivent les raisons pour lesquelles le taux de journalisation peut être limité sur le réplica de calcul principal :The following wait types (in sys.dm_os_wait_stats) describe the reasons why log rate can be throttled on the primary compute replica:

Type d’attenteWait Type DescriptionDescription
RBIO_RG_STORAGERBIO_RG_STORAGE Se produit quand le taux de génération de journal sur le nœud de calcul principal d’une base de données Hyperscale est limité en raison d’une consommation de journal retardée sur le ou les serveurs de pages.Occurs when a Hyperscale database primary compute node log generation rate is being throttled due to delayed log consumption at the page server(s).
RBIO_RG_DESTAGERBIO_RG_DESTAGE Se produit quand le taux de génération de journal sur le nœud de calcul d’une base de données Hyperscale est limité en raison d’une consommation de journal retardée par le stockage de journal à long terme.Occurs when a Hyperscale database compute node log generation rate is being throttled due to delayed log consumption by the long-term log storage.
RBIO_RG_REPLICARBIO_RG_REPLICA Se produit quand le taux de génération de journal sur le nœud de calcul d’une base de données Hyperscale est limité en raison d’une consommation de journal retardée par le ou les réplicas secondaire accessibles en lecture.Occurs when a Hyperscale database compute node log generation rate is being throttled due to delayed log consumption by the readable secondary replica(s).
RBIO_RG_LOCALDESTAGERBIO_RG_LOCALDESTAGE Se produit quand le taux de génération de journal sur le nœud de calcul d’une base de données Hyperscale est limité en raison d’une consommation de journal retardée par le service de journal.Occurs when a Hyperscale database compute node log generation rate is being throttled due to delayed log consumption by the log service.

Lectures de serveur de pagesPage server reads

Les réplicas de calcul ne mettent pas en cache une copie complète de la base de données localement.The compute replicas do not cache a full copy of the database locally. Les données locales du réplica de calcul sont stockées dans le pool de mémoires tampons (en mémoire) et dans le cache local de l’extension du pool de mémoires tampons résilientes (RBPEX), qui est un cache partiel (non couvrant) des pages de données.The data local to the compute replica is stored in the buffer pool (in memory) and in the local resilient buffer pool extension (RBPEX) cache that is a partial (non-covering) cache of data pages. Ce cache RBPEX local est dimensionné proportionnellement à la taille de calcul et représente trois fois la taille de mémoire du niveau de calcul.This local RBPEX cache is sized proportionally to the compute size and is three times the memory of the compute tier. Le cache RBPEX est similaire au pool de mémoires tampons dans le sens où il contient les données les plus fréquemment sollicitées.RBPEX is similar to the buffer pool in that it has the most frequently accessed data. En revanche, chaque serveur de pages dispose d’un cache RBPEX couvrant pour la partie de la base de données qu’il gère.Each page server, on the other hand, has a covering RBPEX cache for the portion of the database it maintains.

Quand une lecture est émise sur un réplica de calcul, si les données n’existent pas dans le pool de mémoires tampons ou dans le cache RBPEX local, un appel de fonction getPage (pageId, LSN) est émis et la page est récupérée à partir du serveur de pages correspondant.When a read is issued on a compute replica, if the data doesn't exist in the buffer pool or local RBPEX cache, a getPage(pageId, LSN) function call is issued, and the page is fetched from the corresponding page server. Les lectures à partir des serveurs de pages étant des lectures distantes, elles sont plus lentes que les lectures à partir du cache RBPEX local.Reads from page servers are remote reads and are thus slower than reads from the local RBPEX. Pour résoudre les problèmes de performances liés aux E/S, il importe de connaître le nombre d’E/S liées aux lectures distantes relativement lentes effectuées à partir d’un serveur de pages.When troubleshooting IO-related performance problems, we need to be able to tell how many IOs were done via relatively slower remote page server reads.

Plusieurs vues de gestion dynamique (DMV) et événements étendus contiennent des colonnes et des champs qui spécifient le nombre de lectures à distante à partir d’un serveur de pages, qui peuvent être comparées au nombre total de lectures.Several dynamic managed views (DMVs) and extended events have columns and fields that specify the number of remote reads from a page server, which can be compared against the total reads. Le magasin des requêtes capture également les lectures distantes dans le cadre des statistiques de durée d’exécution des requêtes.Query store also captures remote reads as part of the query run time stats.

<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" />

Notes

Pour voir ces attributs dans la fenêtre de propriétés du plan de requête, vous avez besoin de SSMS 18.3 ou version ultérieure.To view these attributes in the query plan properties window, SSMS 18.3 or later is required.

Statistiques sur les fichiers virtuels et comptabilisation des E/SVirtual file stats and IO accounting

Dans Azure SQL Database, la fonction de gestion dynamique (DMF) sys.dm_io_virtual_file_stats() est le principal moyen de superviser les E/S de SQL Database.In Azure SQL Database, the sys.dm_io_virtual_file_stats() DMF is the primary way to monitor SQL Database IO. Les caractéristiques des E/S dans Hyperscale sont différentes en raison de son architecture distribuée.IO characteristics in Hyperscale are different due to its distributed architecture. Dans cette section, nous nous concentrons sur les E/S (lectures et écritures) dans les fichiers de données tels qu’ils apparaissent dans cette fonction DMF.In this section, we focus on IO (reads and writes) to data files as seen in this DMF. Dans Hyperscale, chaque fichier de données visible dans cette fonction DMF correspond à un serveur de pages distant.In Hyperscale, each data file visible in this DMF corresponds to a remote page server. Le cache RBPEX mentionné ici est un cache local basé sur SSD qui est un cache non couvrant sur le réplica de calcul.The RBPEX cache mentioned here is a local SSD-based cache, that is a non-covering cache on the compute replica.

Utilisation de cache RBPEX localLocal RBPEX cache usage

Il existe un cache RBPEX local sur le réplica de calcul du stockage SSD local.Local RBPEX cache exists on the compute replica, on local SSD storage. Par conséquent, les E/S sur ce cache sont plus rapides que les E/S sur les serveurs de pages distants.Thus, IO against this cache is faster than IO against remote page servers. Actuellement, dans une base de données Hyperscale, sys.dm_io_virtual_file_stats() contient une ligne spéciale qui fait état des E/S qui se sont produites dans le cache RBPEX local du réplica de calcul.Currently, sys.dm_io_virtual_file_stats() in a Hyperscale database has a special row reporting the IO against the local RBPEX cache on the compute replica. Cette ligne a la valeur 0 pour les colonnes database_id et file_id.This row has the value of 0 for both database_id and file_id columns. Par exemple, la requête ci-dessous retourne des statistiques d’utilisation RBPEX depuis le démarrage de la base de données.For example, the query below returns RBPEX usage statistics since database startup.

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

Le ratio de lectures effectuées dans le cache RBPEX par rapport aux lectures agrégées effectuées dans tous les autres fichiers de données donne le taux d’accès au cache RBPEX.A ratio of reads done on RBPEX to aggregated reads done on all other data files provides RBPEX cache hit ratio.

Lectures de donnéesData reads

  • Quand les lectures sont émises par le moteur de base de données SQL Server sur un réplica de calcul, elles peuvent être traitées par le cache RBPEX local, par des serveurs de pages distants ou par une combinaison des deux dans le cas où plusieurs pages sont lues.When reads are issued by the SQL Server database engine on a compute replica, they may be served either by the local RBPEX cache, or by remote page servers, or by a combination of the two if reading multiple pages.
  • Quand le réplica de calcul lit certaines pages d’un fichier spécifique, par exemple file_id 1, si ces données résident uniquement dans le cache RBPEX local, toutes les E/S de cette lecture comptent pour file_id 0 (RBPEX).When the compute replica reads some pages from a specific file, for example file_id 1, if this data resides solely on the local RBPEX cache, all IO for this read is accounted against file_id 0 (RBPEX). Si une partie de ces données se trouve dans le cache RBPEX local et qu’une autre partie se trouve sur un serveur de pages distant, les E/S comptent pour file_id 0 pour la partie traitée à partir du cache RBPEX, et la partie traitée à partir du serveur de pages distant compte pour file_id 1.If some part of that data is in the local RBPEX cache, and some part is on a remote page server, then IO is accounted towards file_id 0 for the part served from RBPEX, and the part served from the remote page server is accounted towards file_id 1.
  • Quand un réplica de calcul demande une page à un numéro LSN particulier sur un serveur de pages, si celui-ci a tardé à atteindre le LSN demandé, la lecture sur le réplica de calcul attend que le serveur de pages l’ait atteinte avant que la page soit retournée au réplica de calcul.When a compute replica requests a page at a particular LSN from a page server, if the page server has not caught up to the LSN requested, the read on the compute replica will wait until the page server catches up before the page is returned to the compute replica. Pour toute lecture auprès d’un serveur de pages du réplica de calcul, vous constaterez la présence du type d’attente PAGEIOLATCH_* si cette E/S est attendue.For any read from a page server on the compute replica, you will see the PAGEIOLATCH_* wait type if it is waiting on that IO. Dans Hyperscale, ce temps d’attente est constitué à la fois du temps nécessaire pour atteindre la page demandée sur le serveur de pages au numéro LSN voulu et du temps nécessaire pour transférer la page du serveur de pages au réplica de calcul.In Hyperscale, this wait time includes both the time to catch up the requested page on the page server to the LSN required, and the time needed to transfer the page from the page server to the compute replica.
  • Les lectures volumineuses que sont notamment les lectures anticipées se produisent souvent sous forme de lectures par ventilation-regroupement.Large reads such as read-ahead are often done using "Scatter-Gather" Reads. Cela autorise des lectures pouvant atteindre 4 Mo de pages à la fois, ce que le moteur de base de données SQL Server considère comme une lecture unique.This allows reads of up to 4 MB of pages at a time, considered a single read in the SQL Server database engine. En revanche, quand les données lues se trouvent dans un cache RBPEX, ces lectures comptent pour plusieurs lectures individuelles de 8 Ko, car le pool de mémoires tampons et le cache RBPEX utilisent toujours des pages de 8 Ko.However, when data being read is in RBPEX, these reads are accounted as multiple individual 8-KB reads, since the buffer pool and RBPEX always use 8-KB pages. De ce fait, le nombre d’E/S en lecture détectées sur le cache RBPEX peut être supérieur au nombre réel d’E/S exécutées par le moteur.As the result, the number of read IOs seen against RBPEX may be larger than the actual number of IOs performed by the engine.

Écritures de donnéesData writes

  • Le réplica de calcul principal n’écrit pas directement sur les serveurs de pages.The primary compute replica does not write directly to page servers. Au lieu de cela, les enregistrements de journal du service de journal sont relus sur les serveurs de pages correspondants.Instead, log records from the log service are replayed on corresponding page servers.
  • Les écritures qui se produisent sur le réplica de calcul sont principalement des écritures dans le cache RBPEX local (file_id 0).Writes that happen on the compute replica are predominantly writes to the local RBPEX (file_id 0). Pour les écritures dans les fichiers logiques dont la taille est supérieure à 8 Ko, en d’autres termes celles qui résultent d’opérations d’écriture avec regroupement, chaque opération d’écriture est traduite en plusieurs écritures individuelles de 8 Ko dans le cache RBPEX, car le pool de mémoires tampons et le cache RBPEX utilisent toujours des pages de 8 Ko.For writes on logical files that are larger than 8 KB, in other words those done using Gather-write, each write operation is translated into multiple 8-KB individual writes to RBPEX since the buffer pool and RBPEX always use 8-KB pages. De ce fait, le nombre d’E/S en écriture détectées sur le cache RBPEX peut être supérieur au nombre réel d’E/S exécutées par le moteur.As the result, the number of write IOs seen against RBPEX may be larger than the actual number of IOs performed by the engine.
  • Les fichiers non RBPEX, ou les fichiers de données autres que file_id 0 qui correspondent à des serveurs de pages, présentent aussi des écritures.Non-RBPEX files, or data files other than file_id 0 that correspond to page servers, also show writes. Dans le niveau de service Hyperscale, ces écritures sont simulées, car les réplicas de calcul n’écrivent jamais directement sur des serveurs de pages.In the Hyperscale service tier, these writes are simulated, because the compute replicas never write directly to page servers. Les E/S par seconde en écriture et le débit sont comptabilisés à mesure qu’elles se produisent sur le réplica de calcul, mais la latence pour les fichiers de données autres que file_id 0 ne reflète pas la latence réelle des écritures de serveur de pages.Write IOPS and throughput are accounted as they occur on the compute replica, but latency for data files other than file_id 0 does not reflect the actual latency of page server writes.

Écritures de journalLog writes

  • Sur le réplica de calcul principal, une écriture de journal est représentée dans le fichier file_id 2 de sys.dm_io_virtual_file_stats.On the primary compute, a log write is accounted for in file_id 2 of sys.dm_io_virtual_file_stats. Une écriture de journal sur le réplica de calcul principal est une écriture dans la zone d’atterrissage du journal.A log write on primary compute is a write to the log Landing Zone.
  • Les enregistrements de journal ne sont pas renforcés sur le réplica secondaire après une validation.Log records are not hardened on the secondary replica on a commit. Dans Hyperscale, le journal est appliqué par le service de journal aux réplicas secondaires de manière asynchrone.In Hyperscale, log is applied by the log service to the secondary replicas asynchronously. Étant donné que les écritures de journal ne se produisent pas réellement sur les réplicas secondaires, toute comptabilité des E/S de journal sur les réplicas secondaires est établie uniquement à des fins de suivi.Because log writes don't actually occur on secondary replicas, any accounting of log IOs on the secondary replicas is for tracking purposes only.

E/S de données dans les statistiques d’utilisation des ressourcesData IO in resource utilization statistics

Dans une base de données non Hyperscale, les E/S en lecture et en écriture combinées sur les fichiers de données, par rapport à la limite d’E/S de données de la gouvernance des ressources, sont rapportées dans les affichages sys.dm_db_resource_stats et sys.resource_stats, au niveau de la colonne avg_data_io_percent.In a non-Hyperscale database, combined read and write IOPS against data files, relative to the resource governance data IOPS limit, are reported in sys.dm_db_resource_stats and sys.resource_stats views, in the avg_data_io_percent column. La même valeur est indiquée dans le portail Azure en tant que pourcentage d’E/S de données.The same value is reported in the Azure portal as Data IO Percentage.

Dans une base de données Hyperscale, cette colonne indique l’utilisation d’IOPS des données par rapport à la limite du stockage local sur le réplica de calcul uniquement, en particulier les E/S liées à RBPEX et tempdb.In a Hyperscale database, this column reports on data IOPS utilization relative to the limit for local storage on compute replica only, specifically IO against RBPEX and tempdb. Une valeur de 100 % dans cette colonne indique que la gouvernance des ressources limite le stockage local en IOPS.A 100% value in this column indicates that resource governance is limiting local storage IOPS. Si cela est lié à un problème de performances, paramétrez la charge de travail pour générer moins d’E/S ou augmentez le service de base de données afin d’augmenter la limite Max Data IOPS (IOPS maxi de données) pour la gouvernance des ressources.If this is correlated with a performance problem, tune the workload to generate less IO, or increase database service objective to increase the resource governance Max Data IOPS limit. Pour la gouvernance des ressources des lectures et écritures RBPEX, le système compte un nombre d’E/S individuelles de 8 Ko plutôt que des E/S plus volumineuses qui peuvent être émises par le moteur de base de données SQL Server.For resource governance of RBPEX reads and writes, the system counts individual 8-KB IOs, rather than larger IOs that may be issued by the SQL Server database engine.

Les E/S de données sur les serveurs de pages distants ne sont pas rapportées dans les affichages d’utilisation des ressources ou dans le portail, mais le sont dans la fonction de gestion dynamique sys.dm_io_virtual_file_stats(), comme indiqué précédemment.Data IO against remote page servers is not reported in resource utilization views or in the portal, but is reported in the sys.dm_io_virtual_file_stats() DMF, as noted earlier.

Ressources supplémentairesAdditional resources