Comment vérifier les performances du disque dur

Méthode du terminal

hdparm 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/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 ), 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. Aller au système - & gt; Administration - & gt; 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'un est pour "Démarrer lecture seule" et un autre "Démarrer lecture / écriture". Lorsque vous cliquez sur n'importe quel bouton, il commence à analyser le disque dur.

Comment évaluer les E / S 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/urandom parce que c’est un logiciel basé et lent en tant que 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 pas d'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, la différence de performance 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 pour les opérations sur les fichiers.

Pour mesurer réellement 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

donc la date du disque est juste 104857600 / 0.441 = 237772335 B / s - & gt; 237 Mo / s

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

Bonne analyse comparative,

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

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 affichera 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

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. Le système de fichiers basé sur RAM peut être très instructif pour les débutants.

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

lien

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

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

Maintenant, lisez le fichier qui a été créé dans le test 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

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

Si vous voulez de la précision, vous devez 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 de lecture séquentielle avec de gros blocs (cela devrait être proche du nombre indiqué 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 indiqué 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 les performances du monde réel, sauf si vous en savez 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

Lecture et écriture 4K aléatoires mixtes QD1 avec synchro (il s’agit du pire des cas que vous pouvez 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

Augmentez l'argument --size 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é dans le répertoire de travail en cours. Vous devez donc d'abord changer de répertoire monté sur le périphérique que vous souhaitez tester.