Partage via

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

  • Article

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. Dans Hyperscale, la limite de gouvernance du taux de journal est définie sur 105 Mo/s, quelle que soit la taille de calcul. Cette valeur est exposée dans la colonne primary_max_log_rate dans 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 SLA de récupérabilité. 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 journaux permet au taux de génération de journaux d'atteindre 100 Mo/s. Le taux de génération maximal de journaux effectif pour toutes les tailles de calcul Hyperscale.

Notes

Le taux de génération de journaux de 150 Mo/s est disponible en tant que fonctionnalité en préversion avec consentement. Pour découvrir plus d’informations et pour consentir à 150 Mo/s, consultez Blog : Améliorations apportées à Hyperscale en novembre 2024.

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 (DMF) sys.dm_hs_database_log_rate() fournit des informations supplémentaires pour comprendre la réduction du taux d'écriture de journal, 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 mettent pas en cache 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 de lecture du serveur de pages de rapport sont disponibles dans les vues de gestion dynamique et les vues de catalogue d'exécution :
  • Les champs de lecture du serveur de pages sont présents 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. Dans Hyperscale, chaque fichier de données visible dans cette DMF correspond à un serveur de pages. Le DMF fournit également des statistiques d’E/S pour le cache SSD local sur le réplica de calcul et pour le journal des transactions.

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() a une ligne spéciale rapportant les statistiques d’E/S pour le cache SSD local. Cette ligne a la valeur de 0 pour les colonnes database_id et file_id. Par exemple, la requête ci-dessous 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);

Le ratio de lectures du cache SSD local aux lectures agrégées de tous les autres fichiers de données est le taux 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 de cette lecture sont comptabilisées par rapport à file_id 0. Si une partie de ces données se trouve dans le cache SSD local et qu’une partie se trouve sur les serveurs de pages, les E/S sont comptabilisées vers file_id 0 pour la partie servie à partir du cache SSD local, et la partie servie à partir de serveurs de pages est prise en compte vers leurs fichiers correspondants.
  • Lorsqu’un réplica de calcul demande une page à un LSN particulier à partir d’un serveur de pages, si le serveur de pages n’a pas encore rattrapé le LSN demandé, la lecture sur le réplica de calcul attend que le serveur de pages se rattrape avant le retour de la page. Pour toute lecture sur une réplique de calcul à partir d’un serveur de pages, vous voyez un type d’attente PAGEIOLATCH_* s’il attend sur cette entrée/sortie. 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 (file_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 file_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 E/S par seconde, le débit et la latence observés sur une réplique de calcul pour les fichiers de données autres que file_id 0 ne reflètent pas les véritables statistiques d’E/S des écritures qui se produisent sur les serveurs de pages.

Écritures de journal

  • Sur le réplica de calcul principal, une écriture de journal est prise en compte dans sys.dm_io_virtual_file_stats() sous file_id 2.
  • Contrairement aux groupes de disponibilité AlwaysOn, lorsqu’une transaction est validée sur la réplique principale de calcul, les enregistrements de journal ne sont pas consignés sur la réplique 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 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. 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 métriques signalent l'utilisation des IOPS par rapport à la limite du stockage SSD local sur la réplique de calcul uniquement, ce qui inclut les E/S sur le cache SSD local et dans 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 gestion des ressources liées aux lectures et écritures sur le cache SSD local, le système comptabilise des E/S de 8 Ko individuellement, plutôt que des E/S plus volumineuses qui peuvent être générées 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() comme décrit précédemment.

Contenu connexe