Partager via

Collecter une ligne de base : Meilleures pratiques relatives aux performances de SQL Server sur une machine virtuelle Azure

  • Article

S’applique à : SQL Server sur la machine virtuelle Azure

Cet article fournit des informations pour collecter une ligne de base des performances sous la forme d’une série de meilleures pratiques et d’instructions pour optimiser les performances de votre SQL Server sur des machines virtuelles Azure.

Il existe généralement un compromis entre l’optimisation des coûts et l’optimisation des performances. Cette série de bonnes pratiques sur les performances vise à obtenir les meilleures performances possibles pour SQL Server sur les machines virtuelles Azure. Si votre charge de travail est moindre, vous n’aurez peut-être pas besoin de toutes les optimisations recommandées. Tenez compte de vos besoins de performances, des coûts et des modèles de charges de travail lors de l’évaluation de ces recommandations.

Vue d’ensemble

Pour une approche prescriptive, recueillez les compteurs de performances à l’aide de PerfMon/LogMan, et capturez les statistiques d’attente de SQL Server pour mieux comprendre les pressions générales et les goulots d’étranglement potentiels de l’environnement source.

Commencez par collecter le processeur, la mémoire, les IOPS, le débit et la latence de la charge de travail source aux heures de pointe en suivant la liste de contrôle des performances de l’application.

Recueillez des données pendant les heures de pointe, telles que les charges de travail d’une journée de travail ordinaire, mais aussi d’autres processus de charge élevée, tels que le traitement de fin de journée et les charges de travail ETL effectuées pendant le weekend. Envisagez d’augmenter l’échelle de vos ressources pour des charges de travail anormalement lourdes, telles qu’un traitement de fin de trimestre, puis de réduire l’échelle une fois la charge de travail accomplie.

Utilisez l’analyse des performances pour sélectionner la taille de machine virtuelle pouvant adapter son échelle aux exigences de performances de votre charge de travail.

Stockage

Les performances de SQL Server dépendent fortement du sous-système d’E/S et les performances de stockage sont mesurées par IOPS et débit. Si votre base de données ne tient pas dans la mémoire physique, SQL Server place en permanence des pages de base de données dans et hors du pool de mémoires tampons. Les fichiers de données pour SQL Server doivent être traités différemment. L’accès aux fichiers journaux est séquentiel, sauf quand une transaction doit être restaurée à l’emplacement où des fichiers de données, dont la base de données tempdb, font l’objet d’un accès aléatoire. Si vous disposez d’un sous-système d’E/S lent, vos utilisateurs peuvent rencontrer des problèmes de performances, tels que des temps de réponse lents et des tâches qui ne se terminent pas en raison de délais d’expiration.

Les machines virtuelles de la Place de marché Azure ont des fichiers journaux sur un disque physique séparé des fichiers de données par défaut. Le nombre et la taille des fichiers de données de la base de données tempdb sont conformes aux bonnes pratiques et ciblent le lecteur éphémère D:\.

Les compteurs PerfMon suivants peuvent vous aider à valider le débit d’E/S que requiert votre SQL Server :

  • \LogicalDisk\Disk Reads/Sec (IOPS de lecture)
  • \LogicalDisk\Disk Writes/Sec (IOPS d’écriture)
  • \LogicalDisk\Disk Read Bytes/Sec (débit de lecture requis pour les fichiers de données, de journal et de base de données tempdb)
  • \LogicalDisk\Disk Write Bytes/Sec (débit d’écriture requis pour les fichiers de données, de journal et de base de données tempdb)

À l’aide des exigences d’IOPS et de débit aux niveaux de pointe, évaluez les tailles de machine virtuelle correspondant à la capacité de vos mesures.

Si votre charge de travail nécessite 20 000 IOPS de lecture et 10 000 IOPS d’écriture, vous pouvez choisir le modèle E16s_v3 (jusqu’à 32 000 IOPS mises en cache et 25 600 non mises en cache) ou le modèle M16_s (jusqu’à 20 000 IOPS mises en cache et 10 000 non mises en cache) avec 2 disques P30 agrégés par bandes à l’aide d’espaces de stockage.

Veillez à bien identifier les besoins de la charge de travail en termes de débit et d’IOPS, car les machines virtuelles ont des limites d’échelle différentes pour les IOPS et le débit.

Mémoire

Suivez la mémoire externe que le système d’exploitation utilise, ainsi que la mémoire que SQL Server utilise en interne. L’identification de la pression sur chaque composant vous aidera à dimensionner les machines virtuelles et à identifier des opportunités de réglage.

Les compteurs PerfMon suivants peuvent vous aider à valider l’intégrité de la mémoire d’une machine virtuelle SQL Server :

Compute

Le calcul dans Azure est géré autrement que dans l’environnement local. Les serveurs locaux sont conçus pour durer plusieurs années sans mise à niveau en raison de la surcharge de gestion et du coût d’acquisition de nouveau matériel. La virtualisation atténue certains de ces problèmes mais les applications sont optimisées pour tirer le meilleur parti du matériel sous-jacent, ce qui signifie que toute modification significative de l’utilisation des ressources requiert un rééquilibrage de l’ensemble de l’environnement physique.

Ce n’est pas un problème dans Azure où une nouvelle machine virtuelle sur une série différente de matériel, voire dans une région différente, est facile à obtenir.

Dans Azure, vous souhaitez exploiter le plus possible les ressources des machines virtuelles. Par conséquent, les machines virtuelles Azure doivent être configurées pour maintenir l’utilisation moyenne du processeur la plus élevée possible sans que cela ait une incidence sur la charge de travail.

Les compteurs PerfMon suivants peuvent vous aider à valider l’intégrité de calcul d’une machine virtuelle SQL Server :

  • \Processor Information(_Total)% Processor Time
  • \Process(sqlservr)% Processor Time

Notes

Dans l’idéal, essayez d’atteindre une utilisation à 80 % de votre capacité de calcul, avec des pics supérieurs à 90 %, mais sans atteindre 100 % pendant une période prolongée. Fondamentalement, vous souhaitez seulement approvisionner la capacité de calcul dont l’application a besoin, puis planifier l’augmentation ou la diminution d’échelle en fonction des besoins de l’entreprise.

Étapes suivantes

Pour en savoir plus, consultez les autres articles de cette série sur les meilleures pratiques :

Pour connaître les meilleures pratiques en matière de sécurité, consultez Considérations relatives à la sécurité de SQL Server sur les machines virtuelles Azure.

Consultez d’autres articles relatifs aux machines virtuelles avec SQL Server à la page Vue d’ensemble de SQL Server sur les machines virtuelles Azure. Si vous avez des questions sur les machines virtuelles SQL Server, consultez le Forum aux Questions.