Partager via

Diagnostics de résolution des problèmes de performances Hyperscale SQL

S’applique à :Azure SQL Database

Pour résoudre les problèmes de performances dans une base de données Hyperscale, la méthodologies générales de réglage des performances SQL est le point de départ de toute investigation de performances. Cependant, compte tenu de l’architecture distribuée d’Hyperscale, des données de diagnostic supplémentaires peuvent être nécessaires. Cet article décrit les données de diagnostic propres à Hyperscale.

Réduction des délais d'attente liés au taux de journalisation

Chaque base de données et chaque pool élastique dans Azure SQL Database gère le taux de génération de journaux via gouvernance du taux de logs. La limite de débit du journal est exposée dans la colonne primary_max_log_rate de sys.dm_user_db_resource_governance.

Parfois, le taux de génération de journaux sur le réplica de calcul principal doit être réduit pour maintenir les contrats de niveau de service de récupération (SLA). Par exemple, cela peut se produire lorsqu’un serveur de pages ou un autre réplica de calcul est sensiblement en retard dans l'application des nouveaux enregistrements de journal provenant du service de journal. Si aucun composant Hyperscale n’est en retard, le mécanisme de régulation du taux de génération de journaux permet au taux d’atteindre 150 Mio/s par base de données, pour le matériel de la série Premium et la série optimisée pour la mémoire Premium. Pour le matériel de série standard, le débit maximum de journalisation est de 100 Mo/s par base de données. Pour les pools élastiques, le taux maximal de journalisation est de 150 Mio/s par pool pour le matériel optimisé en mémoire de série Premium et de 125 Mio/s par pool pour les autres matériels.

Les types d’attente suivants apparaissent dans sys.dm_os_wait_stats lorsque le taux de journalisation est réduit :

Type d’attente Raison
RBIO_RG_STORAGE Consommation différée des journaux par un serveur de pages
RBIO_RG_DESTAGE Consommation différée des journaux par le stockage des journaux à long terme
RBIO_RG_REPLICA Consommation différée des journaux par une réplique secondaire HA ou une réplique nommée
RBIO_RG_GEOREPLICA Consommation différée des journaux de logs par un réplica géographique secondaire
RBIO_RG_DESTAGE Consommation différée des fichiers journaux par le service des journaux
RBIO_RG_LOCALDESTAGE Consommation différée des fichiers journaux par le service des journaux
RBIO_RG_STORAGE_CHECKPOINT Consommation différée des journaux de transactions sur un serveur de pages en raison d’un point de contrôle de base de données lent
RBIO_RG_MIGRATION_TARGET Consommation différée des journaux de logs par la base de données non Hyperscale pendant la migration inverse

La fonction de gestion dynamique sys.dm_hs_database_log_rate() (DMF) fournit des détails supplémentaires pour vous aider à comprendre la réduction du taux de journalisation, le cas échéant. Par exemple, il peut vous indiquer quel réplica secondaire spécifique est en retard dans l'application des enregistrements de journal, et quelle est la taille totale du journal des transactions qui n'ont pas encore été appliquées.

Lectures de serveur de pages

Les réplicas de calcul ne cachent pas une copie complète de la base de données localement. 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 d’extension de pool de mémoires tampons résilient (RBPEX) local qui contient un sous-ensemble des pages de données les plus fréquemment consultées. Ce cache SSD local est dimensionné proportionnellement à la taille de calcul. Chaque serveur de pages, d’autre part, dispose d’un cache SSD complet pour la partie de la base de données qu’il gère.

Lorsqu'une E/S de lecture est émise sur un réplica de calcul, si les données n'existent pas dans le bassin de tampons ou dans le cache SSD local, la page au numéro de séquence de journal (LSN) demandé est récupérée du serveur de pages correspondant. Les lectures des serveurs de pages sont distantes et sont plus lentes que les lectures du cache SSD local. Lors de la résolution des problèmes de performances liés aux E/S, nous devons être en mesure de déterminer le nombre d'E/S effectuées via les lectures de serveur de pages relativement lentes.

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. Le Magasin des requêtes capture également les lectures du serveur de pages dans les statistiques d'exécution de requête.

  • Les colonnes concernant les lectures du serveur de pages sont disponibles dans les vues de gestion dynamique (DMVs) et les vues de catalogue d’exécution.

  • "Des champs de lecture du serveur de pages se trouvent dans les événements étendus suivants :"

    • 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 attributs sont présents dans le code XML du plan de requête pour les plans qui incluent des statistiques d’exécution. Par exemple:

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

    Conseil

    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.

Statistiques sur les fichiers virtuels et comptabilisation des E/S

Dans Azure SQL Database, le sys.dm_io_virtual_file_stats() DMF est un moyen de surveiller les statistiques d’E/S de base de données, telles que les E/S par seconde, le débit et la latence. Les caractéristiques d’E/S dans Hyperscale sont différentes en raison de son architecture distribuée . Dans cette section, nous nous concentrons sur la lecture et l’écriture d’E/S comme indiqué dans cette DMF.

Pour Hyperscale, les données pertinentes sont sys.dm_io_virtual_file_stats() les suivantes :

  • Les lignes où la database_id valeur correspond à la valeur retournée par la fonction DB_ID et où la file_id valeur est autre que 2, correspondent aux serveurs de pages. Généralement, chaque ligne correspond à un serveur de pages. Toutefois, pour les fichiers plus volumineux, plusieurs serveurs de pages sont utilisés.

    • La ligne avec file_id 2 correspond au journal des transactions.

  • Les lignes où la valeur de la colonne database_id est 0 correspondent au cache SSD local du réplica de calcul.

Utilisation du cache SSD local

Étant donné que le cache SSD local existe sur le même réplica de calcul que celui où le moteur de base de données traite les requêtes, les E/S sur ce cache sont plus rapides que les E/S sur les serveurs de pages. Dans une base de données Hyperscale ou un pool élastique, sys.dm_io_virtual_file_stats() des lignes spéciales signalent des statistiques d’E/S pour le cache SSD local. Ces lignes ont la valeur de 0 pour la colonne database_id. Par exemple, la requête suivante retourne les statistiques d’E/S du cache SSD local depuis le démarrage de la base de données.

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

Un ratio des lectures agrégées des fichiers de cache SSD locaux aux lectures agrégées de tous les autres fichiers de données est le ratio d’accès au cache SSD local. Cette métrique est fournie par les compteurs de performances RBPEX cache hit ratio et RBPEX cache hit ratio base, disponibles dans la DMV sys.dm_os_performance_counters.

Lectures de données

  • Lorsque les lectures sont émises par le moteur de base de données sur une réplique de calcul, elles peuvent être servies par le cache SSD local, par les serveurs de pages, ou par une combinaison des deux si plusieurs pages sont lues.

  • Lorsque le réplica de calcul lit certaines pages à partir d’un fichier de données spécifique (par exemple, le fichier avec file_id 1), si ces données résident uniquement dans le cache SSD local, toutes les E/S pour cette lecture sont comptabilisées par rapport aux fichiers de cache SSD locaux où database_id est 0. Si une partie de ces données se trouve dans le cache SSD local et qu’une autre se trouve sur les serveurs de pages, les opérations d’entrée/sortie sont partiellement attribuées aux fichiers du cache SSD local et partiellement aux fichiers de données liés aux serveurs de pages.

  • Lorsqu’un réplica de calcul demande une page à une adresse LSN particulière à partir d’un serveur de pages, si le serveur de pages n’a pas encore atteint l'adresse LSN demandée, la lecture sur le réplica de calcul attend que le serveur de pages ait atteint cette adresse avant que la page ne soit retournée. Pour toute lecture effectuée à partir d’un serveur de pages sur le réplica de calcul, vous constaterez un type d’attente PAGEIOLATCH_* si celui-ci est en attente de l'E/S. 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.

  • Les lectures volumineuses telles que les lectures anticipées sont souvent effectuées à l’aide de lectures de nuages de points. Cela permet de lire jusqu’à 4 Mo en tant qu’E/S de lecture unique. Toutefois, lorsque les données lues se trouvent dans le cache SSD local, ces lectures sont représentées par plusieurs lectures individuelles de 8 Ko, car le pool de mémoires tampons et le cache SSD local utilisent toujours des pages de 8 Ko. Par conséquent, le nombre d’E/S lues sur le cache SSD local peut être supérieur au nombre réel d’E/S effectuées par le moteur.

Écritures de données

  • Le réplica de calcul principal n’écrit pas directement sur les serveurs de pages. Au lieu de cela, les enregistrements de journal du service de journal sont rejoués sur les serveurs de pages correspondants.

  • Les opérations d'écriture sur la réplique de calcul sont principalement effectuées dans le cache SSD local (database_id 0). Pour les écritures supérieures à 8 Ko, autrement dit celles effectuées à l’aide de de collecte-écriture, chaque opération d’écriture est traduite en plusieurs écritures individuelles de 8 Ko dans le cache SSD local, car le pool de mémoires tampons et le cache SSD local utilisent toujours 8 Ko de pages. Par conséquent, le nombre d'opérations d'entrée/sortie d'écriture observées contre le cache SSD local peut être supérieur au nombre réel d'opérations d'entrée/sortie effectuées par le moteur.

  • Les fichiers de données autres que database_id 0 correspondant aux serveurs de pages peuvent également afficher les écritures. Dans Hyperscale, ces écritures sont simulées, car les répliques de calcul n’écrivent jamais directement sur les serveurs de pages. Les statistiques d’E/S sont comptabilisées à mesure qu’elles se produisent sur la réplique de calcul. Les IOPS d'écriture, le débit et la latence affichés sur un réplica de calcul pour les fichiers de données autres que database_id 0 ne reflètent pas les statistiques réelles d’E/S des écritures qui se produisent sur les serveurs de pages.

Écritures de journal

  • Sur le réplique de traitement principal, les écritures de journal sont comptabilisées en sys.dm_io_virtual_file_stats() sous file_id 2.

  • Contrairement aux groupes de disponibilité, lorsqu’une transaction est validée sur le réplica de calcul principal, les enregistrements de journal ne sont pas renforcés sur le réplica secondaire. Dans Hyperscale, le journal des transactions est renforcé dans le service de journalisation et appliqué aux réplicas secondaires de manière asynchrone. É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 dans sys.dm_io_virtual_file_stats() sur les réplicas secondaires ne doit pas être utilisée comme statistiques d’E/S du journal des transactions.

E/S de données dans les statistiques d’utilisation des ressources

Dans une base de données non Hyperscale, les E/S par seconde de lecture et d’écriture combinées sur les fichiers de données par rapport à la limite d’E/S des données de gouvernance des ressources sont rapportées dans les vues sys.dm_db_resource_stats et sys.resource_stats, dans la colonne avg_data_io_percent. Les DMV correspondantes pour les pools élastiques sont sys.dm_elastic_pool_resource_stats et sys.elastic_pool_resource_stats. Les mêmes valeurs sont signalées que le pourcentage d’E/S de données des métriques Azure Monitor pour les bases de données et les pools élastiques.

Dans une base de données Hyperscale, ces colonnes et ces métriques signalent l’utilisation des E/S de données par rapport à la limite du stockage SSD local uniquement sur le réplica de calcul, lequel inclut les E/S sur le cache SSD local et la base de données tempdb. Une valeur de 100 % dans cette colonne indique que la gouvernance des ressources limite le stockage local en IOPS. Si cela est corrélé avec un problème de performances, ajustez la charge de travail pour générer moins d’E/S ou augmentez la taille de calcul pour augmenter la gouvernance des ressources nombre maximal d’E/S par seconde de donnéeslimite. Pour la gouvernance des ressources des lectures et écritures du cache SSD local, le système compte des E/S individuels de 8 Ko, plutôt que des E/S plus volumineuses qui peuvent être émises par le moteur de base de données.

Les E/S de données sur les serveurs de pages ne sont pas signalées dans les vues d'utilisation des ressources ou via les métriques Azure Monitor, mais elles sont signalées dans sys.dm_io_virtual_file_stats() tel que décrit précédemment.

Contenu connexe

  • Last updated on