Question 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


260
2017-12-12 00:22


origine


Une question similaire a été posée sur unix.stackexchange.com/questions/108838/… , stackoverflow.com/questions/1198691/… et serverfault.com/questions/219739/… . - Anon


Réponses:


Méthode terminale

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 également des informations.

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

Si le lecteur n’a pas de système de fichiers (et seulement à ce moment-là), utilisation 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 gauche.
  3. Cliquez maintenant sur le bouton «Benchmark - Measure Drive Performance» dans le volet de droite.
  4. Une nouvelle fenêtre avec des graphiques s'ouvre.Vous trouverez deux boutons. L'une concerne «Lancer le test de lecture seule» et l'autre «Lancer le test de lecture / écriture». Lorsque vous cliquez sur n'importe quel bouton, il commence à analyser le disque dur.

test

Comment évaluer les E / S disque

Article

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


342
2017-12-12 00:34



Je recommanderais des tests /dev/urandom aussi bien que /dev/zero comme entrées pour dd lors du test d'un SSD car la compressibilité des données peut avoir un effet considérable sur la vitesse d'écriture. - Ian Mackinnon
Il n'y a pas de tel "Système ->" sur mon unité Ubuntu 12.04. Ou du moins je ne l'ai pas trouvé. Et je ne vois pas cet outil de disque non plus dans les paramètres système ... O_o Mais j'ai réussi à le lancer: / usr / bin / palimpsest - Fran Marzoa
Notez que depuis 12.10 c'est simplement appelé Disques et peut être trouvé à travers l'unité. - Paul Lammertsma
Sur Gnome, cela a été déplacé dans Applications -> Outils système -> Préférences -> Utilitaire de disque. Pour ceux qui détestent l'Unité. - Ken Sharp
le /tmp Le système de fichiers utilise souvent un disque virtuel ces jours-ci. Donc, écrire à /tmp semblerait tester votre mémoire, pas votre sous-système de disque. - Zoredache


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

73
2017-08-18 18:31



C'est une réponse utilisant une autre commande / option que les autres. Je vois que c'est une réponse digne d'un poste. - Alaa Ali
Pourquoi avez-vous utilisé 384k comme taille de bloc? - Diego F. Durán
@Diego Il n'y a pas de raison. C'était juste un exemple. Vous pouvez utiliser n'importe quoi d'autre. (entre environ 4k ... 1M) Bien sûr, une plus grande taille de bloc donnera de meilleures performances. Et bien sûr, diminuez le nombre de comptes lorsque vous utilisez de gros fichiers, ou cela prendra un an pour finir. - Tele
il n'est pas fiable par les outils de benchmark comme iozone et les nombres sysbench sont beaucoup plus faibles - MSS


Je ne recommanderais pas l'utilisation /dev/urandom parce que c'est logiciel et lent comme cochon. Mieux vaut prendre des morceaux de données aléatoires sur le disque virtuel. Sur le disque dur, les tests aléatoires n'ont aucune importance, car chaque octet est écrit tel quel (également sur ssd avec dd). Mais si nous testons un pool zfs déduppé avec des données nulles ou aléatoires, il y a une énorme différence de performance.

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 lors des opérations sur les fichiers.

Pour vraiment mesurer la vitesse du disque et non la mémoire, nous devons synchroniser le système de fichiers pour éliminer 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

La valeur du disque est donc 104857600 / 0,441 = 237772335 B / s -> 237 Mo / s

C'est inférieur à 100 Mo / s qu'avec la mise en cache.

Bonne analyse comparative


42
2017-12-06 23:18





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 exactes sur la performance d'un disque pour une application ou une tâche particulière. La sortie vous montrera la vitesse de lecture / écriture par processus, et la vitesse totale de lecture / écriture pour le serveur, très similaire à top.

Pour installer iotop:

sudo apt-get install iotop  

Pour l'exécuter:

sudo iotop

30
2017-09-17 14:24





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 ++ 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, etc. Comparant une clé usb, un disque dur (rotatif), un disque dur Le système de fichiers peut être très instructif pour le débutant.

Je n'ai aucune idée s'il est inclus dans Ubuntu, mais vous pouvez le compiler facilement à partir des sources.

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


23
2018-02-03 16:13





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 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 effacer le cache mémoire

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

Maintenant, lisez le fichier créé en é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

17
2018-05-05 22:12





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 à: SIMPLE BONNIE ++ EXEMPLE.


12
2017-09-28 19:02





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 voulez mesurer. Quelques exemples:

Vitesse séquentielle READ avec de gros blocs (cela devrait être près 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 WRITE avec de gros blocs (cela devrait être près 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

Aléatoire 4K lire QD1 (c'est le nombre qui compte vraiment pour la performance du monde réel à moins que vous ne le sachiez mieux):

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

Mixage aléatoire 4K lire et écrire QD1 avec synchronisation (il s'agit du numéro de cas le plus défavorable que vous puissiez attendre de votre lecteur, en général 1 à 10% du nombre indiqué 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 de fichiers disponibles en fonction de la technologie du lecteur et du micrologiciel. Les petits fichiers donneront des résultats "trop ​​bons" pour les médias en rotation car la tête de lecture n'a pas besoin de bouger autant. Si votre appareil est presque vide, utiliser un fichier suffisamment gros pour quasiment remplir le disque vous donnera le comportement le plus défavorable pour chaque test. En cas de SSD, la taille du fichier importe peu.

Notez que fio 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 un stockage permanent. Le fichier temporaire sera appelé fio-tempfile.dat dans les exemples ci-dessus et stockés dans le répertoire de travail en cours. Donc, vous devez d'abord modifier le répertoire monté sur le périphérique que vous souhaitez tester.


9
2018-01-01 18:14



Certains des paramètres du fio sont un peu étranges et peuvent ne pas être optimaux. Par exemple, avoir une taille de bloc aussi importante (2 Mo) lorsque vous effectuez des E / S directes avec un moteur d'E / S asynchrone risque d'entraîner une division importante du noyau, créant ainsi une surcharge. Envoi périodique fsyncs lorsque vous ne faites que lire, vous semblez également inhabituel. Je suis d'accord que fio est utile mais je recommande aux lecteurs d'étudier soigneusement les paramètres qu'ils souhaitent utiliser plutôt que de simplement les copier textuellement à partir de la version 20180102 de la réponse ci-dessus ... - Anon
@Anon: vous avez raison, l'optimum pour la lecture séquentielle serait de correspondre /sys/block/sd?/queue/max_sectors_kb car il peut être inférieur à la limite matérielle réelle qui est généralement beaucoup plus que le 2 Mo dans l'exemple ci-dessus. Cependant, je suppose que la surcharge mineure causée par le processeur n'a pas d'importance par rapport à la vitesse du périphérique d'E / S réel. le fsync est un no-operation pour les lectures, donc cela n'affectera pas les résultats - je l'ai gardé pour qu'il soit plus facile de comprendre les différences entre les différentes lignes de commande. Avez-vous des difficultés à obtenir les résultats correspondant aux spécifications du fabricant? - Mikko Rantalainen
Pas exactement, j'ai juste (une) expérience de travail avec fio et Linux. En fait, si vous devinez la meilleure taille de bloc, il serait sage de commencer avec optimal_io_size si elle est disponible (mais vous pouvez supposer que 64 Ko sont à 0 si c'est ce que fait le noyau). fio et Linux. En fait, si vous devinez la meilleure taille de bloc, il serait judicieux de commencer avec optimal_io_size si elle est disponible (mais vous pouvez supposer que 64 Ko sont à 0 si c'est le cas du noyau). - Anon
Je viens de tester à nouveau certains appareils. En utilisant le test de lecture séquentiel ci-dessus (taille de bloc de 2 Mo), j'ai obtenu 280 Mo / s de Samsung SSD 850 EVO et 1070 Mo / s de Intel 910 SSD. Avec une taille de bloc de 64k et une ligne de commande identique, j'ai obtenu 268 Mo / s à partir de 850 EVO et 1055 Mo / s à partir de 910 SSD. Au moins pour ce type d'appareils, l'utilisation d'une taille de bloc de 2 Mo semble améliorer les résultats autour de 1 à 5%, même si le noyau divise les requêtes en matériel. Je suppose que même avec les optimisations du noyau, la surcharge de soumission de plus de syscalls est pire que de diviser le noyau. - Mikko Rantalainen
Après des tests supplémentaires, il semble que je reçoive le débit séquentiel le plus élevé en utilisant une puissance de 2 valeurs inférieure à max_sectors_kb. J'ai changé l'exemple de commandes ci-dessus pour utiliser une taille de bloc de 1 Mo car cela semble fonctionner avec du matériel réel. Et j'ai aussi testé cela fsync n'a pas d'importance pour la lecture. - Mikko Rantalainen