Auparavant, j'ai couvert les bases des métriques et des tests du sous-système de stockage dans mon article Analyse des performances du sous-système d'E/S pour SQL Server, y compris une introduction de CrystalDiskMark 4.0. CrystalDiskMark a récemment été réécrit pour utiliser Microsoft DiskSpd pour ses tests, ce qui en fait un outil encore plus précieux pour vos efforts de test initiaux du sous-système de stockage. DiskSpd fournit les fonctionnalités nécessaires pour générer une grande variété de modèles de demande de disque, ce qui peut être très utile dans le diagnostic et l'analyse des problèmes de performances d'E/S avec beaucoup plus de flexibilité que les anciens outils de référence comme SQLIO. Il est extrêmement utile pour les tests de sous-systèmes de stockage synthétiques lorsque vous souhaitez un niveau de contrôle supérieur à celui disponible dans CrystalDiskMark.
Maintenant, nous allons approfondir un peu la façon d'utiliser réellement Microsoft DiskSpd pour tester votre sous-système de stockage sans utiliser CrystalDiskMark 4.0. Pour ce faire, vous devrez télécharger et décompresser DiskSpd. Pour faciliter les choses, je copie toujours le fichier exécutable diskspd.exe souhaité à partir du dossier exécutable approprié (amd64fre, armfre ou x86fre) vers un chemin court et simple comme C:\DiskSpd . Dans la plupart des cas, vous voudrez la version 64 bits de DiskSpd du dossier amd64fre.
Une fois que vous avez le fichier exécutable diskspd.exe disponible, vous devrez ouvrir une invite de commande avec des droits d'administration (en choisissant "Exécuter en tant qu'administrateur"), puis naviguer jusqu'au répertoire où vous avez copié le fichier diskspd.exe.
Voici quelques-uns des paramètres de ligne de commande avec lesquels vous voudrez commencer :
| Paramètre | Description |
| -b | Taille de bloc des E/S, spécifiée comme (K/M/G). Par exemple –b8K signifie une taille de bloc de 8 Ko, ce qui est pertinent pour SQL Server |
| -d | Durée du test en secondes. Les tests de 30 à 60 secondes sont généralement assez longs pour obtenir des résultats valides |
| -o | E/S en attente (c'est-à-dire la profondeur de la file d'attente) par cible, par thread de travail |
| -t | Threads de travail par cible de fichier de test |
| -h | Désactivez la mise en cache logicielle au niveau du système d'exploitation et la mise en cache matérielle en écriture, ce qui est une bonne idée pour tester SQL Server |
| -r | Indicateur aléatoire ou séquentiel. Si –r est utilisé, des tests aléatoires sont effectués, sinon des tests séquentiels sont effectués |
| -w | Pourcentage d'écriture. Par exemple, –w25 signifie 25 % d'écritures, 75 % de lectures |
| -Z | Taille du tampon source d'écriture du test de charge de travail, spécifiée comme (K/M/G). Utilisé pour fournir des données aléatoires pour les écritures, ce qui est une bonne idée pour les tests SQL Server |
| -L | Capturez les informations de latence pendant le test, ce qui est une très bonne idée pour tester SQL Server |
| -c | Crée un ou plusieurs fichiers de charge de travail de la taille spécifiée, spécifiée comme (K/M/G) |
Tableau 1 :Paramètres de ligne de commande de base pour DiskSpd
Vous voudrez également spécifier l'emplacement du fichier de test et le nom du fichier pour les résultats à la fin de la ligne. Voici un exemple de ligne de commande :
diskspd –b8K –d30 –o4 –t8 –h –r –w25 –L –Z1G –c20G T:\iotest.dat> DiskSpeedResults.txtCet exemple de ligne de commande exécutera un test d'E/S aléatoire de 30 secondes à l'aide d'un fichier de test de 20 Go situé sur le lecteur T :, avec un taux d'écriture de 25 % et de lecture de 75 %, avec une taille de bloc de 8 Ko. Il utilisera huit threads de travail, chacun avec quatre E/S en attente et une graine de valeur d'entropie d'écriture de 1 Go. Il enregistrera les résultats du test dans un fichier texte appelé DiskSpeedResults.txt. Il s'agit d'un assez bon ensemble de paramètres pour une charge de travail OLTP SQL Server.
Figure 1 :Exemple de ligne de commande pour DiskSpd
L'exécution du test commence par un temps de préchauffage par défaut de cinq secondes (avant que toute mesure ne démarre réellement), puis le test réel s'exécutera pendant la durée spécifiée en secondes avec un temps de refroidissement par défaut de zéro seconde. Une fois le test terminé, DiskSpd fournira une description du test et les résultats détaillés. Par défaut, il s'agira d'un simple résumé textuel dans un fichier texte utilisant le nom de fichier que vous avez spécifié, qui se trouvera dans le même répertoire que l'exécutable diskspd.
Voici à quoi ressemblent les résultats pour ce test particulier exécuté sur mon poste de travail.
Figure 2 :Exemple de résultats de test DiskSpd
La première section des résultats vous donne la ligne de commande exacte qui a été utilisée pour le test, puis spécifie tous les paramètres d'entrée qui ont été utilisés pour l'exécution du test (qui incluent les valeurs par défaut qui peuvent ne pas avoir été spécifiées dans la ligne de commande réelle ). Ensuite, les résultats du test sont affichés en commençant par le temps de test réel, le nombre de threads et le nombre de processeurs logiques. La section CPU affiche l'utilisation du CPU pour chaque processeur logique, y compris le temps de l'utilisateur et du noyau, pour l'intervalle de test.
La partie la plus intéressante des résultats des tests vient ensuite. Vous obtenez le nombre total d'octets, le nombre total d'E/S, les Mo/seconde, les E/S par seconde (IOPS) et votre latence moyenne en millisecondes. Ces résultats sont ventilés pour chaque thread (quatre dans notre cas), avec des sections distinctes dans les résultats pour Total IO, Read IO et Write IO. Les résultats pour chaque thread doivent être très similaires dans la plupart des cas. Plutôt que de me concentrer initialement sur les valeurs absolues pour chaque mesure, j'aime comparer les valeurs lorsque j'exécute le même test sur différents lecteurs logiques (après avoir changé l'emplacement du fichier de test dans la ligne de commande), ce qui vous permet de comparer les performances. pour chaque lecteur logique.
La dernière section des résultats du test est encore plus intéressante. Il montre une analyse en centile de la distribution des résultats du test de latence à partir de la valeur minimale en millisecondes jusqu'à la valeur maximale en millisecondes, ventilée pour les lectures, les écritures et la latence totale. Les « neufs » dans la colonne %-ile font référence au nombre de neufs, où 3 neufs signifie 99,9, 4 neufs signifie 99,99, etc. La raison pour laquelle les valeurs des lignes de centiles supérieures sont identiques est que ce test avait un nombre relativement faible d'opérations totales. Si vous souhaitez caractériser avec précision les centiles supérieurs, vous devrez exécuter un test de plus longue durée qui génère un plus grand nombre d'opérations d'E/S distinctes.
Ce que vous voulez rechercher dans ces résultats est le point où les valeurs font un saut important. Par exemple, dans ce test, nous pouvons voir que 99 % des lectures avaient une latence de 1,832 millisecondes ou moins.
Figure 3 :Distribution des résultats de latence
Comme vous pouvez le constater, l'exécution de DiskSpd est en fait assez simple une fois que vous comprenez ce que signifient les paramètres de base et comment ils sont utilisés. Non seulement vous pouvez exécuter DiskSpd à partir d'une ligne de commande à l'ancienne, mais vous pouvez également l'exécuter à l'aide de PowerShell. DiskSpd vous donne également des informations beaucoup plus détaillées que celles que vous obtenez de SQLIO. La partie la plus compliquée de l'utilisation de DiskSpd est l'analyse et l'interprétation des résultats, ce que j'aborderai dans un prochain article.
