Si vous voulez de la précision, vous devriez utiliser fio. Il faut lire le manuel ( man fio) mais cela vous donnera des résultats précis. Notez que pour toute précision, vous devez spécifier exactement ce que vous souhaitez mesurer. Quelques exemples:
Vitesse de lecture séquentielle avec de gros blocs (elle devrait être proche du nombre que vous voyez dans les spécifications de votre lecteur):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=read --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Vitesse séquentielle d'écriture avec de gros blocs (elle devrait être proche du nombre que vous voyez dans les spécifications de votre lecteur):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=write --size=500m --io_size=10g --blocksize=1024k --ioengine=libaio --fsync=10000 --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Lecture aléatoire 4K QD1 (c'est le chiffre qui compte vraiment pour une performance réelle, à moins que vous ne sachiez mieux à coup sûr):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randread --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Lecture aléatoire 4K en lecture / écriture aléatoire QD1 avec synchronisation (il s'agit du nombre le plus défavorable auquel vous devriez vous attendre de votre lecteur, généralement inférieur à 1% des nombres répertoriés dans la fiche technique):
fio --name TEST --eta-newline=5s --filename=fio-tempfile.dat --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --fsync=1 --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Augmentez l' --sizeargument pour augmenter la taille du fichier. L'utilisation de fichiers plus volumineux peut réduire le nombre d'informations obtenues en fonction de la technologie du lecteur et du micrologiciel. Les petits fichiers donneront des résultats "trop bons" pour les supports en rotation car la tête de lecture n'a pas besoin de trop bouger. Si votre appareil est presque vide, l'utilisation d'un fichier assez volumineux pour presque remplir le lecteur vous donnera le pire comportement possible pour chaque test. Dans le cas d'un disque SSD, la taille du fichier importe peu.
Toutefois, notez que pour certains supports de stockage, la taille du fichier n’est pas aussi importante que le nombre total d’octets écrits sur une courte période. Par exemple, certains SSD peuvent offrir des performances nettement plus rapides avec des blocs pré-effacés ou une petite zone flash SLC utilisée comme cache en écriture et les performances changent une fois que le cache SLC est plein. Autre exemple, les disques durs Seagate SMR ont une zone de mémoire cache PMR d’environ 20 Go qui offre des performances assez élevées, mais une fois remplie, l’écriture directe dans la zone SMR peut réduire les performances de 10% par rapport à l’original. Et le seul moyen de voir cette dégradation des performances est d’écrire d’abord plus de 20 Go le plus rapidement possible. Bien sûr, tout dépend de votre charge de travail: si votre accès en écriture est éclaté avec des retards de longue durée qui permettent au périphérique de nettoyer le cache interne, Des séquences de test plus courtes refléteront mieux les performances de votre monde réel. Si vous devez faire beaucoup d'E / S, vous devez augmenter les deux--io_sizeet --runtimeparamètres. Notez que certains supports (par exemple la plupart des périphériques flash) vont subir une usure supplémentaire à la suite de tels tests. À mon avis, si un périphérique est suffisamment pauvre pour ne pas gérer ce type de test, il ne doit en aucun cas être utilisé pour conserver des données de valeur.
De plus, certains périphériques SSD de haute qualité peuvent avoir des algorithmes de nivellement d'usure encore plus intelligents dans lesquels le cache SLC interne dispose de suffisamment de compétences pour remplacer les données en place qui sont réécrites pendant le test si elles atteignent le même espace adresse (c'est-à-dire, fichier de test). est plus petit que le cache SLC total). Pour de tels périphériques, la taille du fichier commence à compter à nouveau. Si vous avez besoin de votre charge de travail réelle, il est préférable de tester avec des tailles de fichier que vous verrez réellement dans la vie réelle. Sinon, vos chiffres peuvent paraître trop beaux.
Notez que fiocela créera le fichier temporaire requis lors de la première exécution. Il sera rempli de données aléatoires pour éviter d'obtenir de trop bons nombres d'appareils qui trichent en compressant les données avant de les écrire dans le stockage permanent. Le fichier temporaire sera appelé fio-tempfile.datdans les exemples ci-dessus et stocké dans le répertoire de travail en cours. Donc, vous devriez d’abord passer au répertoire monté sur le périphérique que vous voulez tester.
Si vous avez un bon disque SSD et que vous voulez voir des nombres encore plus élevés, augmentez --numjobsau-dessus. Cela définit la simultanéité pour les lectures et les écritures. Les exemples ci-dessus ont tous été numjobsconfigurés pour 1que le test porte sur la lecture et l'écriture de processus à un seul thread (éventuellement avec une file d'attente définie avec iodepth). Disques SSD haut de gamme (par exemple Intel Optane) devrait obtenir un nombre élevé même sans augmenter numjobsbeaucoup (par exemple , 4devrait être suffisant pour obtenir le plus grand nombre de spécifications) , mais certains « Enterprise » disques SSD nécessitent va 32- 128pour obtenir les numéros de spécifications , car la latence interne de ceux périphériques est plus élevé, mais le débit global est insensé.
