Après des mois de tests, j’ai abandonné CrystalDiskMark.
Diskspd de Microsoft fait mieux le travail. Le résultat est moins joli à regarder, mais les chiffres sont plus proches de la réalité. Et au final, c’est ce qui compte.
L’installation en 30 secondes
Ouvre PowerShell et colle ça :
$client = New-Object System.Net.WebClient
$client.DownloadFile("https://github.com/Microsoft/diskspd/releases/latest/download/DiskSpd.zip","$env:temp\DiskSpd-download.zip")
Expand-Archive -LiteralPath "$env:temp\DiskSpd-download.zip" C:\DISKSPD
cd \diskspd\amd64
C’est fait. Maintenant tu peux mesurer.
Le test de base
Voici ma commande pour un test rapide et représentatif :
## Pour SQL Server
Si tu as un serveur SQL, les tests changent. Le disque des logs et celui des données tempdb ont des besoins différents.
### Disque pour les logs de transaction
```
.\diskspd -b60K -d60 -h -L -o32 -t4 -s -w100 -c1G f:\diskspdtest\io.dat > ..\Log-DiskF.txt
```
100% d'écritures séquentielles. C'est exactement ce que fait SQL avec ses logs.
### Disque pour tempdb
```
.\diskspd -b512K -d120 -h -L -o32 -t4 -si -w100 -c1G f:\diskspdtest\io.dat > ..\Temp-DiskF.txt
```
Des blocs plus gros, un test plus long. Tempdb travaille différemment.
### Test de lecture pure
```
.\diskspd -b2M -d60 -o32 -h -L -t4 -W -w0 f:\diskspdtest\io.dat > ..\Read-DiskF.txt
Sur mon poste avec un NVMe, ça donne des résultats qui correspondent à ce que je vois vraiment quand je travaille.
Décoder les paramètres
Le truc avec diskspd, c’est que chaque paramètre compte. Voici ce que j’utilise :
-b : Taille de bloc (ici 4K, parfait pour SQL Server)
-d : Durée en secondes (30-60 secondes suffisent)
-o : Profondeur de file d’attente par thread
-t : Nombre de threads
-h : Désactive les caches (essentiel pour tester vraiment)
-r : Test aléatoire (sinon c’est séquentiel)
-w : Pourcentage d’écritures (25 = 25% écritures, 75% lectures)
-Z : Taille du tampon avec données aléatoires
-L : Capture la latence (indispensable)
-c : Crée le fichier de test
N’oublie pas de créer ton dossier de test sur chaque disque :
md f:\diskspdtest
Pour SQL Server
Si tu as un serveur SQL, les tests changent. Le disque des logs et celui des données tempdb ont des besoins différents.
Disque pour les logs de transaction
.\diskspd -b60K -d60 -h -L -o32 -t4 -s -w100 -c1G f:\diskspdtest\io.dat > ..\Log-DiskF.txt
100% d’écritures séquentielles. C’est exactement ce que fait SQL avec ses logs.
Disque pour tempdb
.\diskspd -b512K -d120 -h -L -o32 -t4 -si -w100 -c1G f:\diskspdtest\io.dat > ..\Temp-DiskF.txt
Des blocs plus gros, un test plus long. Tempdb travaille différemment.
Test de lecture pure
.\diskspd -b2M -d60 -o32 -h -L -t4 -W -w0 f:\diskspdtest\io.dat > ..\Read-DiskF.txt
Blocs de 2MB, zéro écriture. Les valeurs de write seront à 0, c’est normal.
Ce qui compte vraiment
Il existe des centaines de combinaisons possibles. Le secret ? Tester ce qui correspond à ton usage réel.
Veeam a ses propres tests pour la sauvegarde. SQL Server a ses patterns spécifiques. Ne teste pas au hasard : teste ce que tu fais vraiment.
Deux exemples du terrain
VMware avec une carte RAID mal configurée
Avant : performances catastrophiques
Après : multiplication par 10
C’est énorme. Mais ça montre surtout qu’une mauvaise config coûte cher.
Proxmox avec RAID ZFS
Mon HP MicroServer Gen11. Serveur de préparation, quasi inactif. Pourtant, deux tests diskspd ont suffi pour charger le système.
Par contre en échange d’une charge processeur
Comprendre la latence
Je m’inspire de Paul Randal pour interpréter les résultats :
- Excellent : < 1ms
- Très bon : < 5ms
- Bon : 5-10ms
- Médiocre : 10-20ms
- Mauvais : 20-100ms
- Catastrophique : 100-500ms
La latence, c’est ce que tes utilisateurs ressentent. Les IOPS impressionnent sur les fiches techniques, mais la latence tue l’expérience.
Laisser un commentaire