Comment vérifier les performances du disque dur

Réponses:

425

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.

tester

Comment évaluer les E / S du disque

Article

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

Panthère
la source
10
Je recommande de tester /dev/urandomaussi bien que /dev/zerocomme entrées ddlors du test d'un SSD car la compressibilité des données peut avoir un effet énorme sur la vitesse d'écriture.
Ian Mackinnon
3
Il n’existe 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 disque ni dans les paramètres système ... O_o Mais j'ai finalement réussi à l'exécuter: / usr / bin / palimpsest
Fran Marzoa
6
Notez que depuis 12.10, il s’appelle simplement Disques et se trouve dans Unity.
Paul Lammertsma
1
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
2
Le /tmpsystème de fichiers utilise souvent un disque virtuel ces jours-ci. Donc, écrire sur /tmpsemblerait tester votre mémoire, pas votre sous-système de disque.
Zoredache
99

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
Télé
la source
28
C'est une réponse utilisant une commande / option différente des autres. Je vois que c'est une réponse digne d'un article à part.
Alaa Ali
2
Pourquoi avez-vous utilisé 384k comme taille de bloc?
Diego F. Durán
1
@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, de plus grandes tailles de blocs donneront de meilleures performances. Et bien sûr, diminuez le nombre de fois que vous utilisez big bs, sinon cela prendra un an.
Tele
ce n'est pas fiable selon des outils d'évaluation tels que iozone et sysbench, les chiffres sont beaucoup plus bas
MSS
1
Soyez prudent avec l'utilisation des zéros pour vos données d'écriture - certains systèmes de fichiers et certains disques auront un chemin spécial pour les cas (et d'autres données compressibles), ce qui provoquera des nombres de référence artificiellement élevés ...
Anon
50

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,

Pasi Suominen
la source
3
Soyez prudent lorsque vous utilisez des zéros pour vos données d’écriture - certains disques (tels que les disques SSD) et certains systèmes de fichiers auront un chemin de cas particulier. Il en résulte des valeurs de référence artificiellement élevées lors de l'utilisation de mémoires tampons nulles. D'autres modèles de données hautement compressibles peuvent également fausser les résultats ...
Anon
36

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
Lars
la source
28

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

Mikko Rantalainen
la source
1
Je viens de re-tester certains appareils. En utilisant le test de lecture séquentielle 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 sur 850 EVO et 1 055 Mo / s sur 910 SSD. Au moins pour ce type de périphériques, l'utilisation d'une taille de bloc de 2 Mo semble améliorer les résultats d'environ 1 à 5% même si le noyau divise les demandes en matériel. J'imagine que même avec les optimisations de noyau, la surcharge de soumettre plus d'appels système est pire que de se scinder à l'intérieur du noyau.
Mikko Rantalainen
1
Après des tests plus poussés, il semble que j'obtienne le débit séquentiel le plus élevé avec une puissance de 2, inférieure à max_sectors_kb. J'ai modifié les exemples 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é que fsyncpeu importe la lecture.
Mikko Rantalainen
1
Selon la façon dont le lecteur est connecté, il est possible que votre profondeur d’iodation soit trop faible. Vous devez surveiller ce que Linux envoie réellement au périphérique et à quelle profondeur il le fait ...
Anon
1
Je mets iodepthsur 1pour un accès aléatoire exactement parce que les programmes du monde réel utilisent souvent des algorithmes / logiques qui ne fonctionnent pas avec une profondeur supérieure à 1. Par conséquent, si cette profondeur est "trop ​​basse", votre périphérique d'E / S est défectueux. Il est vrai que certains périphériques SSD bénéficieront d'une profondeur supérieure à 32. Cependant, pouvez-vous indiquer une charge de travail réelle qui nécessite un accès en lecture et est capable de conserver une profondeur supérieure à 32? TL; DR: si vous souhaitez reproduire un nombre de référence incroyablement élevé avec un périphérique à latence élevée, utilisez-le, iodepth=256 --numjobs=4mais ne vous attendez jamais à en avoir de véritables.
Mikko Rantalainen
1
La plupart des programmes du "monde réel" ne soumettent pas réellement les entrées / sorties (o_) directement, et encore moins de manière asynchrone, de sorte que tous nos exemples sont dans des charges de travail inhabituelles pour repousser les limites du domaine de référence (le meilleur point de référence étant votre charge de travail réelle). Cela dit, en exécutant des tâches telles que l’exécution de plusieurs machines virtuelles occupées, vous pouvez facilement générer des charges de travail avec des profondeurs incroyablement élevées, mais où les E / S semblent souvent aléatoires du point de vue du disque et constituent un exemple simple illustrant une accélération considérable des choses telles que: NVMe. PS: les nombres trop élevés réduiront le débit, il y a donc une
Anon
25

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++/

Corto
la source
Bonnie est défectueuse pour l'analyse comparative de disque et peut facilement générer des chiffres qui reflètent en réalité des aspects non liés au disque de votre système. Vous devez donc faire très attention si vous choisissez de l'utiliser. Voir l'analyse comparative active de Brendan Gregg: Bonnie ++ pour plus de détails.
Anon
22

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
Limon Monte
la source
Soyez prudent avec l' aide de zéros pour votre écriture des données - certains systèmes de fichiers et les disques auront un chemin de cas particulier pour elle (et d' autres données compressibles) qui entraînera un nombre de référence artificiellement élevés ...
Anon
14

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 .

Nyxee
la source