L'un des goulots d'étranglement les plus courants en matière de performances que je vois en tant que consultant est l'insuffisance des performances du sous-système de stockage. Les mauvaises performances de stockage peuvent s'expliquer par un certain nombre de raisons, mais les mesurer et comprendre ce qui doit être mesuré et surveillé est toujours un exercice utile.
Il existe en fait trois métriques principales qui sont les plus importantes lorsqu'il s'agit de mesurer les performances du sous-système d'E/S :
Latence
La première métrique est la latence, qui est simplement le temps nécessaire à une E/S pour se terminer. Ceci est souvent appelé temps de réponse ou temps de service. La mesure commence lorsque le système d'exploitation envoie une demande au lecteur (ou au contrôleur de disque) et se termine lorsque le lecteur a fini de traiter la demande. Les lectures sont terminées lorsque le système d'exploitation reçoit les données, tandis que les écritures sont terminées lorsque le lecteur informe le système d'exploitation qu'il a reçu les données.
Pour les écritures, les données peuvent toujours se trouver dans un cache DRAM sur le lecteur ou le contrôleur de disque, selon votre politique de mise en cache et votre matériel. La mise en cache à écriture différée est beaucoup plus rapide que la mise en cache à écriture immédiate, mais elle nécessite une batterie de secours pour le contrôleur de disque. Pour l'utilisation de SQL Server, vous voulez vous assurer que vous utilisez la mise en cache en écriture différée plutôt que la mise en cache en écriture immédiate, si possible. Vous voulez également vous assurer que votre cache de disque matériel est réellement activé, car certains outils de gestion de disque de fournisseur le désactivent par défaut.
Opérations d'entrée/sortie par seconde (IOPS)
La deuxième mesure est les opérations d'entrée/sortie par seconde (IOPS). Cette métrique est directement liée à la latence. Par exemple, une latence constante de 1 ms signifie qu'un lecteur peut traiter 1 000 E/S par seconde avec une profondeur de file d'attente de 1. Au fur et à mesure que d'autres E/S sont ajoutées à la file d'attente, la latence augmente. L'un des principaux avantages du stockage flash est qu'il peut lire/écrire sur plusieurs canaux NAND en parallèle, ainsi que le fait qu'il n'y a pas de pièces mobiles électromécaniques pour ralentir l'accès au disque. L'IOPS est en fait égale à la profondeur de la file d'attente divisée par la latence, et l'IOPS en soi ne prend pas en compte la taille de transfert pour un transfert de disque individuel. Vous pouvez traduire les IOPS en Mo/s et les Mo/s en latence tant que vous connaissez la profondeur de la file d'attente et la taille du transfert.
Débit séquentiel
Le débit séquentiel est le débit auquel vous pouvez transférer des données, généralement mesuré en mégaoctets par seconde (Mo/s) ou en gigaoctets par seconde (Go/s). Votre métrique de débit séquentiel en Mo/s est égale aux IOPS multipliées par la taille du transfert. Par exemple, 556 Mo/s équivaut à 135 759 IOPS multipliées par une taille de transfert de 4 096 octets, tandis que 135 759 IOPS multipliées par une taille de transfert de 8 192 octets correspondraient à 1 112 Mo/s de débit séquentiel. Malgré son importance quotidienne pour SQL Server, le débit de disque séquentiel est souvent compromis dans le stockage d'entreprise, à la fois par les fournisseurs de stockage et par les administrateurs de stockage. Il est également assez courant de voir les disques magnétiques réels dans un boîtier de stockage à connexion directe (DAS) ou un périphérique de réseau de stockage (SAN) être si occupés qu'ils ne peuvent pas fournir leur plein débit séquentiel nominal.
Le débit séquentiel est essentiel pour de nombreuses activités de serveur de base de données courantes, y compris les sauvegardes et restaurations complètes de base de données, la création et la reconstruction d'index et les analyses de lecture séquentielle de type entrepôt de données volumineux (lorsque vos données ne rentrent pas dans le pool de mémoire tampon SQL Server). Un objectif de performance que j'aime viser sur les nouvelles versions de serveur de base de données est d'avoir au moins 1 Go/s de débit séquentiel pour chaque lettre de lecteur ou point de montage. Avoir ce niveau de performance (ou mieux) vous facilite la vie en tant que professionnel des bases de données. Cela rend beaucoup plus rapides vos tâches de base de données courantes et vous donne également la liberté d'effectuer des réglages d'index plus fréquents lorsque vous pouvez créer un index sur une grande table en quelques secondes ou minutes au lieu d'heures.
Métriques de charge de travail d'E/S SQL Server
En ce qui concerne SQL Server et les performances d'E/S, il y a un certain nombre de choses que vous devez mesurer et surveiller au fil du temps. Vous devez connaître le rapport lecture/écriture pour votre charge de travail pour tous vos fichiers de base de données utilisateur et pour tempdb. Les ratios seront différents pour différents types de fichiers et charges de travail SQL Server. Vous pouvez utiliser mes requêtes de diagnostic DMV pour déterminer cela, et vous pouvez également utiliser la vue de l'activité du disque dans SQL Sentry Performance Advisor pour obtenir facilement une vue plus complète de l'activité de votre disque, à partir d'une image globale de haut niveau, tout en bas aux fichiers individuels :
Conseiller de performances SQL Sentry :activité du disque
Vous devez également mesurer les taux d'E/S typiques pour les IOPS et le débit séquentiel. Dans l'Analyseur de performances Windows (PerfMon), les lectures/s et les écritures/s indiquent les IOPS, tandis que les octets de lecture de disque/s et les octets d'écriture de disque/s représentent le débit séquentiel. Vous devez utiliser PerfMon pour mesurer la moyenne des secondes disque/lecture et la moyenne des secondes disque/écriture, qui correspond à la latence de lecture et d'écriture au niveau du disque. Enfin, vous pouvez utiliser mes requêtes de diagnostic DMV pour mesurer la latence moyenne de lecture et d'écriture au niveau des fichiers pour tous vos fichiers de base de données utilisateur ainsi que pour tempdb.
Méthodes de mesure des performances d'E/S
Vous pouvez utiliser la section Disque du Moniteur de ressources Windows pour obtenir une vue rapide et en temps réel de certaines métriques de disque clés pour tous vos fichiers de base de données SQL Server. Pour aller plus loin, vous pouvez utiliser PerfMon pour mesurer et surveiller les compteurs de performances critiques que j'ai mentionnés précédemment. Avant de passer en production avec un nouveau serveur de base de données, vous devez effectuer des tests d'évaluation du disque pour déterminer le type de performances que votre sous-système d'E/S peut réellement fournir. Ce n'est en fait pas si difficile ni si long (si vous utilisez les bons outils), mais cela est souvent oublié lorsqu'un nouveau serveur de base de données est provisionné et testé.
Le premier benchmark de disque que vous devez toujours exécuter est CrystalDiskMark 4.0, qui a récemment été réécrit pour utiliser le programme de benchmark de disque Microsoft DiskSpd relativement nouveau. L'interface utilisateur CDM 4.0 vous permet de choisir une gamme plus large de tailles de fichiers de test et vous permet également de choisir la profondeur de la file d'attente et le nombre de threads pour les exécutions de test. Cela vous permet d'obtenir une charge de travail d'E/S plus semblable à celle d'un serveur et vous permet également de stresser plus correctement les nouveaux périphériques de stockage flash NVMe qui peuvent gérer des profondeurs de file d'attente supérieures à 32.
CrystalDiskMark 4.03 Résultats avec QD =32 et threads =1
Figure 2 :Résultats CrystalDiskMark 4.03 avec QD =32 et threads =4
Contrairement aux versions précédentes de CDM, les deux lignes les plus pertinentes pour l'utilisation de SQL Server se trouvent au milieu de l'affichage des résultats. Il s'agit des lectures et écritures aléatoires 4K avec une profondeur de file d'attente élevée (32 par défaut) et des lectures et écritures séquentielles. Après avoir effectué des tests de référence de stockage avec CrystalDiskMark 4.0, vous devez effectuer des tests plus approfondis avec Microsoft DiskSpd. Dans un prochain article, j'expliquerai comment utiliser DiskSpd pour effectuer des tests plus complets pour SQL Server.
