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.
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 ne possède pas de système de fichiers (et seulement alors ), 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
gnome-disks
.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
car il s'agit d'un logiciel lent et lent. 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
la date de sortie du disque est donc de 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, très similaires à top
name__.
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 ++ 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. Comparaison d'une clé USB, d'un disque dur (disque rotatif), d'un lecteur à état solide et d'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.
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
Si vous voulez de la précision, utilisez 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 d'écriture 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=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 au format 4K QD1 (c'est le nombre qui compte vraiment pour la performance dans le monde réel, à 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 de 4K et écriture de QD1 avec synchronisation (c'est le nombre le plus défavorable auquel vous pouvez vous attendre de votre lecteur, généralement entre 1 et 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 d'informations obtenues en fonction de la technologie du lecteur et du microprogramme. 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.
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 le stockage permanent. Le fichier temporaire s'appellera fio-tempfile.dat
dans les exemples ci-dessus et sera stocké dans le répertoire de travail en cours. Par conséquent, vous devez d’abord passer au répertoire monté sur le périphérique que vous souhaitez tester.
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 .
Vérifiez l’intégrité, détectez les faux lecteurs flash et testez les performances, tout en un.
Plus sur cette réponse .