Comment vérifier les performances du disque dur

Comment vérifier les performances d'un disque dur (via un terminal ou une interface graphique). La vitesse d'écriture. La vitesse de lecture. Taille et vitesse du cache. Vitesse aléatoire.

Méthode du terminal

hdparm est un bon endroit pour commencer.

sudo hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads:   12540 MB in  2.00 seconds = 6277.67 MB/sec
Timing buffered disk reads: 234 MB in  3.00 seconds =  77.98 MB/sec

sudo hdparm -v /dev/sda donnera des informations aussi bien.

dd vous donnera des informations sur la vitesse d'écriture.

Si le lecteur ne possède pas de système de fichiers (et uniquement dans ce cas ), utilisez of=/dev/sda.

Sinon, montez-le sur / tmp et écrivez puis supprimez le fichier de sortie de test.

dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output

10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

Méthode graphique

1. Allez dans Système -> Administration -> Utilitaire de disque.
   • Vous pouvez également lancer l'utilitaire de disque Gnome à partir de la ligne de commande en exécutant gnome-disks
2. Sélectionnez votre disque dur dans le volet de gauche.
3. Maintenant, cliquez sur le bouton “Benchmark - Measure Drive Performance” dans le volet de droite.
4. Une nouvelle fenêtre avec des graphiques s’ouvre. Vous y trouverez deux boutons. L'un concerne «Lancer le test de lecture seule» et l'autre «Lancer le test de lecture / écriture». Lorsque vous cliquez sur n'importe quel bouton, l'analyse comparative du disque dur commence.

Comment évaluer les E / S du disque

Article

Y a-t-il quelque chose de plus que tu veux?

Suominen a raison, nous devrions utiliser une sorte de synchronisation; mais il existe une méthode plus simple, conv = fdatasync fera le travail:

dd if=/dev/zero of=/tmp/output conv=fdatasync bs=384k count=1k; rm -f /tmp/output
1024+0records in
1024+0 records out
402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s

Je ne recommanderais pas d'utiliser /dev/urandomparce que c'est un logiciel et lent comme cochon. Mieux vaut prendre des morceaux de données aléatoires sur le disque mémoire. Le test aléatoire sur le disque dur n'a pas d'importance, car chaque octet est écrit tel quel (également sur ssd avec dd). Mais si nous testons un pool zfs déduit avec des données pures ou aléatoires, la différence de performances est énorme.

Un autre point de vue doit être l'inclusion du temps de synchronisation; tous les systèmes de fichiers modernes utilisent la mise en cache sur les opérations de fichier.

Pour vraiment mesurer la vitesse du disque et non la mémoire, nous devons synchroniser le système de fichiers pour supprimer l'effet de mise en cache. Cela peut être facilement fait par:

time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"

avec cette méthode, vous obtenez une sortie:

sync ; time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k  && sync" ; rm testfile 
1024+0 records in
1024+0 records out
104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/s

real    0m0.441s
user    0m0.004s
sys 0m0.124s

le disque date / minute est donc juste 104857600 / 0.441 = 237772335 B / s -> 237Mo / s

C'est plus de 100 Mo / s de moins qu'avec la mise en cache.

Joyeux benchmarking,

Si vous souhaitez surveiller la vitesse de lecture et d'écriture du disque en temps réel, vous pouvez utiliser l' outil iotop .

Cela est utile pour obtenir des informations exactes sur le comportement d'un disque pour une application ou une tâche particulière. La sortie indiquera la vitesse de lecture / écriture par processus et la vitesse totale de lecture / écriture du serveur, qui sont très similaires à top.

Pour installer iotop:

sudo apt-get install iotop  

Pour l'exécuter:

sudo iotop

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é.

Bonnie ++ est l'utilitaire de référence ultime que je connaisse pour Linux.

(Je prépare actuellement un livecd Linux au travail avec Bonnie ++ dessus pour tester notre machine Windows!)

Il prend en charge la mise en cache, la synchronisation, les données aléatoires, l'emplacement aléatoire sur le disque, les mises à jour de petite taille, les mises à jour volumineuses, les lectures, les écritures, etc. Comparant une clé USB, un disque dur (disque rotatif), un lecteur à état solide et un lecteur Le système de fichiers peut être très instructif pour le débutant.

Je ne sais pas s'il est inclus dans Ubuntu, mais vous pouvez le compiler facilement à partir des sources.

http://www.coker.com.au/bonnie++/

Vitesse d'écriture

$ dd if=/dev/zero of=./largefile bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 4.82364 s, 223 MB/s

La taille des blocs est en réalité assez grande. Vous pouvez essayer avec des tailles plus petites comme 64k ou même 4k.

Vitesse de lecture

Exécutez la commande suivante pour effacer le cache de la mémoire

$ sudo sh -c "sync && echo 3 > /proc/sys/vm/drop_caches"

Lisez maintenant le fichier créé dans le test d’écriture:

$ dd if=./largefile of=/dev/null bs=4k
165118+0 records in
165118+0 records out
676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s

quelques astuces pour utiliser Bonnie ++

bonnie++ -d [TEST_LOCATION] -s [TEST_SIZE] -n 0 -m [TEST_NAME] -f -b -u [TEST_USER] 
bonnie++ -d /tmp -s 4G -n 0 -m TEST -f -b -u james

Un peu plus sur: SIMPLE BONNIE ++ EXEMPLE .

f3 - Lutte contre la fraude éclair

Vérifiez l'intégrité, détectez les faux lecteurs flash et testez les performances, les trois en un.

Plus sur cette réponse .