Exercice : mettre à l’échelle les performances de votre charge de travail

  • 10 minutes

Dans cet exercice, vous allez prendre le problème que vous avez rencontré dans le premier exercice et améliorer les performances en mettant à l’échelle davantage de processeurs pour Azure SQL Database. Vous allez utiliser la base de données que vous avez déployée dans l’exercice précédent.

Vous trouverez tous les scripts de cet exercice dans le dosseir 04-Performance\monitor_and_scale dans le référentiel GitHub que vous avez cloné ou le fichier zip que vous avez téléchargé.

Augmenter la puissance des performances Azure SQL

Pour mettre à l’échelle les performances pour un problème qui semble être lié à la capacité du processeur, vous devez déterminer vos options, puis procéder à la mise à l’échelle des processeurs à l’aide des interfaces fournies pour Azure SQL.

  1. Décidez comment mettre à l’échelle les performances. Étant donné que la charge de travail est liée au processeur, une façon d’améliorer les performances consiste à augmenter la capacité ou la vitesse du processeur. Un utilisateur SQL Server devrait se déplacer vers un autre ordinateur ou reconfigurer une machine virtuelle pour obtenir davantage de capacité de processeur. Dans certains cas, même un administrateur de SQL Server peut ne pas disposer des autorisations nécessaires pour effectuer ces modifications de mise à l’échelle. Le processus peut prendre du temps et même nécessiter une migration de base de données.

    Pour Azure, vous pouvez utiliser ALTER DATABASE, Azure CLI ou le portail Microsoft Azure pour augmenter la capacité du processeur sans migration de base de données de la part de l’utilisateur.

  2. Le portail Azure vous propose des options pour mettre à l’échelle votre processeur et augmenter ses ressources. Dans le panneau Vue d’ensemble de votre base de données, sélectionnez le déploiement actuel pour le niveau Tarification. Le niveau Tarification vous permet de changer le niveau de service et le nombre de vCores.

    Screenshot of changing service tier in the Azure portal.

  3. Ici, vous pouvez voir les options de modification ou de mise à l’échelle des ressources de calcul. Pour Usage général, vous pouvez facilement effectuer un scale-up jusqu’à 8 vCores.

    Screenshot of compute options in the Azure portal.

    Vous pouvez également utiliser une autre méthode pour mettre à l’échelle votre charge de travail.

  4. Dans cet exercice, vous devez d’abord vider le Magasin des requêtes pour voir les différences entre les rapports. Dans SQL Server Management Studio (SSMS), sélectionnez la base de données AdventureWorks, puis utilisez le menu Fichier>Ouvrir>Fichier. Ouvrez le script flushhquerystore.sql dans SSMS dans le contexte de la base de données AdventureWorks. Votre fenêtre de l’éditeur de requête doit ressembler au texte suivant :

    EXEC sp_query_store_flush_db;

    Sélectionnez Exécuter pour exécuter ce lot T-SQL.

    Remarque

    L’exécution de la requête précédente vide la partie en mémoire des données du magasin des requêtes sur le disque.

  5. Ouvrez le script get_service_objective.sql dans SSMS. Votre fenêtre de l’éditeur de requête doit ressembler au texte suivant :

    SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
FROM sys.dm_user_db_resource_governance;
GO
SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
GO

    Cette méthode vous permet de déterminer votre niveau de service à l’aide de T-SQL. Le niveau tarifaire ou de service est également appelé objectif de service. Sélectionnez Exécuter pour exécuter les lots T-SQL.

    Pour le déploiement d’Azure SQL Database actuel, vos résultats doivent ressembler à l’image suivante :

    Screenshot of service objective results.

    Notez le terme slo_name est également utilisé pour l’objectif de service. slo signifie service level objective (objectif de niveau de service).

    Les différentes valeurs de slo_name ne sont pas documentées, mais la valeur de chaîne indique que cette base de données utilise un niveau de service Usage général avec deux vCores :

    Remarque

    SQLDB_OP_... est la chaîne qui correspond à Critique pour l’entreprise.

    Quand vous consultez la documentation sur ALTER DATABASE, notez que vous pouvez sélectionner votre déploiement de SQL Server cible pour obtenir les options de syntaxe appropriées. Sélectionnez Base de données SQL unique/pool élastique pour voir les options d’Azure SQL Database. Pour correspondre à l’échelle de calcul que vous avez trouvée dans le portail, vous avez besoin de l’objectif de service 'GP_Gen5_8'.

  6. Modifiez l’objectif de service pour la base de données afin de mettre à l’échelle plus de processeurs. Ouvrez le script modify_service_objective.sql dans SSMS et exécutez le lot T-SQL. Votre fenêtre de l’éditeur de requête doit ressembler au texte suivant :

    ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');

    Cette instruction revient immédiatement, mais la mise à l’échelle des ressources de calcul se produit en arrière-plan. Une mise à l’échelle si petite doit prendre moins d’une minute. La base de données est brièvement mise hors connexion pour que le changement puisse entrer en vigueur. Vous pouvez suivre la progression de cette activité de mise à l’échelle à l’aide du portail Azure.

    Screenshot of update in the Azure portal.

  7. Dans l’Explorateur d’objets sous le dossier Bases de données système, cliquez avec le bouton droit sur la base de données master, puis sélectionnez Nouvelle requête. Exécutez cette requête dans la fenêtre de l’éditeur de requête SSMS :

    SELECT * FROM sys.dm_operation_status;

    Il s’agit d’une autre façon de surveiller la progression d’une modification de l’objectif de service pour Azure SQL Database. Cette vue de gestion dynamique (DMV) expose un historique des changements apportés à l’objectif de service de la base de données avec ALTER DATABASE. Elle indique la progression active du changement.

    Voici un exemple de la sortie de cette DMV sous forme d’un tableau après l’exécution de l’instruction ALTER DATABASE précédente :

    Élément Valeur
    session_activity_id 97F9474C-0334-4FC5-BFD5-337CDD1F9A21
    resource_type 0
    resource_type_desc Base de données
    major_resource_id AdventureWorks
    minor_resource_id
    operation ALTER DATABASE
    state 1
    state_desc IN_PROGRESS
    percent_complete 0
    error_code 0
    error_desc
    error_severity 0
    error_state 0
    start_time [date heure]
    last_modify_time [date heure]

    Au cours d’une modification de l’objectif de service, les requêtes sont autorisées sur la base de données jusqu’à l’implémentation de la modification finale. Une application ne peut pas se connecter pendant une courte période de temps. Pour Azure SQL Managed Instance, une modification du niveau autorise les requêtes et les connexions, mais empêche toutes les opérations de base de données comme la création de bases de données. Dans ces cas, vous recevez le message d’erreur suivant : « Impossible d’effectuer l’opération, car un changement de niveau de service est en cours pour l’instance managée '[serveur]'. Attendez la fin de l’opération en cours, puis réessayez. »

  8. Ensuite, utilisez les requêtes précédentes de get_service_objective.sql dans SSMS pour vérifier que le nouvel objectif de service ou niveau de service de 8 vCores a bien été appliqué.

Exécuter la charge de travail après un scale-up

Maintenant que la base de données dispose d’une plus grande capacité d’UC, nous allons exécuter la charge de travail que nous avons effectuée lors de l’exercice précédent pour observer s’il y a une amélioration des performances.

  1. Maintenant que la mise à l’échelle est terminée, vérifiez si la durée de la charge de travail est plus rapide et si les attentes sur les ressources du processeur ont diminué. Réexécutez la charge de travail à l’aide de la commande sqlworkload.cmd que vous avez exécutée dans l’exercice précédent.

  2. À l’aide de SSMS, exécutez la même requête du premier exercice de ce module pour observer les résultats du script dmdbresourcestats.sql :

    SELECT * FROM sys.dm_db_resource_stats;

    Vous devriez voir que l’utilisation moyenne des ressources du processeur est inférieure à celle de l’exercice précédent (qui avoisinait les 100 %). Normalement, sys.dm_db_resource_stats affiche une heure d’activité. Le redimensionnement de la base de données entraîne la réinitialisation de sys.dm_db_resource_stats.

  3. À l’aide de SSMS, exécutez la même requête du premier exercice de ce module pour observer les résultats du script dmexecrequests.sql.

    SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;

    Il n’y a plus aucune requête avec l’état RUNNING. Cela signifie que nos employés ont plus de capacité d’UC à exécuter.

  4. Observez la nouvelle durée de la charge de travail. La durée de la charge de travail de sqlworkload.cmd doit maintenant être nettement inférieure, environ 25-30 secondes.

Observer les rapports du Magasin des requêtes

Examinons les mêmes rapports de Magasin des requêtes que ceux de l’exercice précédent.

  1. En utilisant les mêmes techniques que pour le premier exercice de ce module, examinez le rapport des principales requêtes consommatrices de ressources à partir de SSMS :

    Screenshot of top query results running faster.

    Vous voyez maintenant deux requêtes (query_id). Il s’agit des mêmes requêtes, mais elles apparaissent sous la forme de valeurs query_id différentes dans le Magasin des requêtes. En effet, l’opération de mise à l’échelle nécessitait un redémarrage et la requête devait être recompilée. Vous pouvez voir dans le rapport que la durée globale et moyenne était beaucoup moins importante.

  2. Examinez également le rapport Statistiques d’attente des requêtes et sélectionnez la barre Attente du processeur. Vous pouvez voir que le temps d’attente moyen global pour la requête est inférieur et que le pourcentage de la durée globale est aussi inférieur. Cela signifie donc que le processeur ne constitue pas vraiment un goulot d’étranglement des ressources quand la base de données a un nombre inférieur de vCores :

    Screenshot of top wait statistics results running faster.

  3. Vous pouvez fermer tous les rapports et toutes les fenêtres de l’éditeur de requête. Laissez SSMS connecté, car vous en aurez besoin dans l’exercice suivant.

Observer les modifications des métriques Azure

  1. Accédez à la base de données AdventureWorks dans le portail Microsoft Azure, puis, dans l’onglet Surveillance du volet Vue d’ensemble, examinez Utilisation du calcul :

    Screenshot of compute comparison in the Azure portal.

    Notez que la durée est plus courte quand l’utilisation du processeur est intensive, ce qui signifie une baisse globale des ressources processeur nécessaires pour exécuter la charge de travail.

  2. Ce graphique peut être quelque peu trompeur. Dans le menu Surveillance, utilisez Métriques, puis définissez la métrique sur Limite du processeur. Le graphique de comparaison des processeurs ressemble à ceci :

    Screenshot of query comparison in the Azure portal.

Conseil

Si vous continuez à augmenter le nombre de vCores pour cette base de données, vous pouvez améliorer les performances jusqu’à un certain seuil (toutes les requêtes disposant alors de beaucoup de ressources processeur). Cela ne signifie pas que le nombre de vCores doit être égal au nombre d’utilisateurs simultanés dans votre charge de travail. Vous pouvez également changer le niveau tarifaire et utiliser un niveau de calcul Serverless, au lieu de Provisionné. Vous adoptez ainsi une approche qui s’apparente plus à une mise à l’échelle automatique de la charge de travail. Par exemple, pour cette charge de travail, si vous choisissez une valeur vCore minimale de 2 et une valeur vCore maximale de 8, la charge de travail est immédiatement mise à l’échelle avec 8 vCores.

Dans l’exercice suivant, vous allez observer un problème lié aux performances d’une application et le résoudre en appliquant les bonnes pratiques.