Comment vérifier les performances du disque dur

français
#1

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.

#2

Méthode terminale

hdparm c'est un bon point de départ.

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

sudo hdparm -v /dev/sda donnera également des informations.

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

Si le lecteur ne dispose pas d'un système de fichiers (et alors seulement), utiliser 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/output10240+0 records in10240+0 records out83886080 bytes (84 MB) copied, 1.08009 s, 77.7 MB/s

Méthode graphique

  1. >>Accédez à System-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 gauche.
  3. Cliquez maintenant sur le bouton "Benchmark-Mesurer les performances du lecteur" dans le volet droit.
  4. Une nouvelle fenêtre avec des graphiques s'ouvre.Vous trouverez et deux boutons. L'un est pour "Démarrer le Benchmark en lecture seule" et un autre est “Démarrer le Benchmark en lecture / écriture". Lorsque vous cliquez sur un bouton, il commence l'analyse comparative du disque dur.

test

Comment comparer les E/S de disque

Article

Y a-t-il quelque chose de plus que vous voulez?

#3

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/output1024+0records in1024+0 records out402653184 bytes (403 MB) copied, 3.19232 s, 126 MB/s
#4

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 (cela 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 d'écriture séquentielle avec de gros blocs (cela 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 nombre qui compte vraiment pour les performances du monde réel à moins que vous ne sachiez mieux avec certitude):

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 et écriture aléatoires mixtes 4K QD1 avec synchronisation (c'est le pire chiffre auquel vous devriez vous attendre de votre lecteur, généralement moins de 1% des chiffres indiqué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

Augmenter le --size argument pour augmenter la taille du fichier. L'utilisation de fichiers plus volumineux peut réduire le nombre que vous obtenez en fonction de la technologie du lecteur et du micrologiciel. Les petits fichiers donneront des résultats "trop bons" pour les supports rotatifs car la tête de lecture n'a pas besoin de bouger autant. Si votre appareil est presque vide, l'utilisation d'un fichier suffisamment volumineux pour remplir presque le lecteur vous donnera le comportement le plus défavorable pour chaque test. Dans le cas du SSD, la taille du fichier n'a pas beaucoup d'importance.

Cependant, notez que pour certains supports de stockage, la taille du fichier n'est pas aussi important que nombre total d'octets écrits pendant une courte période. Par exemple, certains SSD ont des performances nettement plus rapides avec des blocs pré-effacés ou ils peuvent avoir une petite zone flash SLC utilisée comme cache d'écriture et les performances changent une fois le cache SLC plein (par exemple, la série Samsung EVO qui a un cache SLC de 20 à 50 Go). À titre d'autre exemple, les disques durs Seagate SMR ont une zone de cache PMR d'environ 20 Go qui offre des performances assez élevées, mais une fois qu'elle est pleine, l'écriture directement dans la zone SMR peut réduire les performances à 10% par rapport à l'original. Et la seule façon de voir cette dégradation des performances est d'écrire d'abord plus de 20 Go aussi vite que possible et de continuer avec le test réel immédiatement après. Bien sûr, tout dépend de votre charge de travail: si votre accès en écriture est saturé de longs retards qui permettent au périphérique de nettoyer le cache interne, des séquences de test plus courtes refléteront mieux vos performances réelles. Si vous devez faire beaucoup d'IO, vous devez augmenter les deux --io_size et --runtime paramètre. Notez que certains médias (par exemple la plupart pas cher les périphériques flash) souffriront de tels tests car les puces flash sont suffisamment pauvres pour s'user très rapidement. À mon avis, si un appareil est suffisamment médiocre pour ne pas gérer ce type de test, il ne devrait en aucun cas être utilisé pour contenir des données précieuses. Cela dit, ne répétez pas les gros tests d'écriture pendant 1000 secondes, car toutes les cellules flash auront un certain niveau d'usure avec l'écriture.

De plus, certains périphériques SSD de haute qualité peuvent avoir des algorithmes de nivellement d'usure encore plus intelligents où le cache SLC interne a suffisamment d'intelligence pour remplacer les données sur place si elles sont réécrites alors que les données sont toujours dans le cache SLC. Pour de tels périphériques, si le fichier de test est plus petit que le cache SLC total du périphérique, le test complet écrit toujours uniquement dans le cache SLC et vous obtenez des performances supérieures à celles que le périphérique peut prendre en charge pour des écritures plus importantes. Donc, pour de tels appareils, la taille du fichier recommence à avoir de l'importance. Si vous connaissez votre charge de travail réelle, il est préférable de tester avec les tailles de fichiers que vous verrez réellement dans la vraie vie. Si vous ne connaissez pas la charge de travail attendue, l'utilisation d'une taille de fichier de test qui remplit environ 50% du périphérique de stockage devrait donner un bon résultat moyen pour toutes les implémentations de stockage. Bien sûr, pour une configuration RAID de 50 To, faire un test d'écriture avec un fichier de test de 25 To prendra un certain temps!

Notez que fio créera le fichier temporaire requis lors de la première exécution. Il sera rempli de données pseudo-aléatoires pour éviter d'obtenir de trop bons nombres de périphériques qui tentent de tricher dans les benchmarks en compressant les données avant de les écrire dans un stockage permanent. Le fichier temporaire sera appelé fio-tempfile.dat dans les exemples ci-dessus et stocké dans le répertoire de travail actuel. Vous devez donc d'abord accéder au répertoire monté sur le périphérique que vous souhaitez tester. Le fio prend également en charge l'utilisation de médias directs comme cible de test, mais je suggère vivement de lire la page de manuel avant d'essayer cela, car une faute de frappe peut écraser l'ensemble de votre système d'exploitation lorsque l'on utilise un accès direct aux supports de stockage (par exemple, écrire accidentellement sur un périphérique OS au lieu d'un périphérique de test).

Si vous avez un bon SSD et que vous souhaitez voir des chiffres encore plus élevés, augmentez --numjobs surtout. Cela définit la concurrence pour les lectures et les écritures. Les exemples ci-dessus ont tous numjobs définir sur 1 le test concerne donc la lecture et l'écriture de processus à thread unique (éventuellement avec la profondeur de file d'attente ou QD définie avec iodepth). Les SSD haut de gamme (par exemple Intel Optane 905p) devraient obtenir des chiffres élevés même sans augmenter numjobs beaucoup (p. ex. 4 devrait être suffisant pour obtenir les numéros de spécifications les plus élevés) mais certains SSD "d'entreprise" nécessitent d'aller à la gamme 32-128 pour obtenir les numéros de spécifications, car la latence interne de ces périphériques est plus élevée, mais le débit global est insensé. Notez que l'augmentation numbjobs à des valeurs élevées augmente généralement le résultat performances de référence les chiffres, mais reflètent rarement la performance du monde réel de quelque manière que ce soit.

#5

Je ne recommanderais pas d'utiliser /dev/urandom parce qu'il est basé sur un logiciel et lent comme cochon. Mieux vaut prendre un morceau de données aléatoires sur ramdisk. Sur le disque dur, le test aléatoire n'a pas d'importance, car chaque octet est écrit tel quel (également sur SSD avec dd). Mais si nous testons le pool zfs dédupliqué avec des données pures nulles ou aléatoires, il y a une énorme différence de performances.

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

Pour vraiment mesurer la vitesse du disque et non la mémoire, nous devons synchroniser le système de fichiers pour nous débarrasser de 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 in1024+0 records out104857600 bytes (105 MB) copied, 0.270684 s, 387 MB/sreal    0m0.441suser    0m0.004ssys 0m0.124s

>donc, la date du disque est juste 104857600 / 0,441 = 237772335 B / s -- 237 Mo / s

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

Bonne analyse comparative,

#6

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

Ceci est utile pour obtenir des informations sur les performances d'un disque pour une application ou une charge de travail particulière. La sortie vous montrera la vitesse de lecture/écriture par processus et la vitesse totale de lecture/écriture pour le serveur, similaire à top.

Installer iotop:

sudo apt-get install iotop

Exécutez-le:

sudo iotop

Cet outil est utile pour comprendre les performances d'un disque pour une charge de travail spécifique par rapport à des tests plus généraux et théoriques.

#7

Vitesse d'écriture

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

La taille du bloc est en fait 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 vider le cache mémoire

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

Maintenant, lisez le fichier qui a été créé en test d'écriture:

$ dd if=./largefile of=/dev/null bs=4k165118+0 records in165118+0 records out676323328 bytes (676 MB) copied, 3.0114 s, 225 MB/s
#8

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

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

Il s'occupe de la mise en cache, de la synchronisation, des données aléatoires, de l'emplacement aléatoire sur le disque, des mises à jour de petite taille, des mises à jour volumineuses, des lectures, des écritures, etc. La comparaison d'une clé USB, d'un disque dur (rotatif), d'un disque SSD et d'un système de fichiers basé sur la RAM peut être très instructive pour le débutant.

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

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

#9

quelques conseils sur l'utilisation de 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 à: EXEMPLE DE BONNIE++ SIMPLE.

#10

Similar question has been asked over on linux - How can I benchmark my HDD? - Unix & Linux Stack Exchange , file io - Testing IO performance in Linux - Stack Overflow and io - I/O Performance Benchmarking Linux - Server Fault .