Comment vérifier les performances d'un disque dur (via un terminal ou une interface graphique). La vitesse d'écriture. La vitesse de lecture. La taille et la vitesse du cache. La 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/secsudo 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 alors seulement ), utilisez of=/dev/sda .
Sinon, montez-le sur /tmp et écrivez puis supprimez le fichier de sortie du 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/sgnome-disks
Vous voulez quelque chose de plus ?
Puisque la question est étiquetée pour 11.10, j'ai juste pensé que je pourrais signaler que l'Utilitaire de disque peut également être recherché facilement dans le tableau de bord de Unity, ou situé dans la catégorie Accessoires de l'objectif Applications en utilisant le filtre fourni.
Je recommande de tester /dev/urandom ainsi que /dev/zero en tant qu'entrées pour dd lorsque vous testez un SSD, car la compressibilité des données peut avoir un effet considérable sur la vitesse d'écriture.
Il n'y a pas de tel "Système ->" sur mon Ubuntu 12.04 Unity. 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 à le lancer : /usr/bin/palimpsest
Suominen a raison, nous devrions utiliser une sorte de synchronisation ; mais il existe une méthode plus simple, conv=fdatasync fera l'affaire :
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
C'est une réponse qui utilise une commande/option différente des autres. Je vois que c'est une réponse qui mérite un post à part entière.
Diego Il n'y a aucune raison. C'était juste un exemple. Vous pouvez utiliser n'importe quoi d'autre. (entre environ 4k ... 1M ) Bien sûr, une taille de bloc plus grande donnera de meilleures performances. Et bien sûr, diminuez le nombre de compteurs lorsque vous utilisez de gros blocs, sinon il faudra un an pour terminer.
Si vous voulez de la précision, vous devez utiliser fio . Il faut lire le manuel ( man fio ) mais il 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 (ce chiffre doit être proche de celui 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_reportingVitesse d'écriture séquentielle avec de gros blocs (ce chiffre doit être proche de celui 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_reportingLecture aléatoire 4K QD1 (c'est le chiffre qui compte vraiment pour les performances réelles, à moins que vous ne soyez sûr de 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_reportingLecture et écriture aléatoires mixtes 4K QD1 avec synchronisation (il s'agit du chiffre le plus défavorable que vous pouvez attendre de votre disque, 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_reportingAugmenter le --size pour augmenter la taille du fichier. L'utilisation de fichiers plus grands peut réduire les chiffres que vous obtenez en fonction de la technologie du lecteur et du micrologiciel. Les petits fichiers donneront de "trop bons" résultats pour les supports rotatifs car la tête de lecture n'a pas besoin de se déplacer autant. Si votre appareil est presque vide, l'utilisation d'un fichier suffisamment grand pour presque remplir le disque vous donnera le pire comportement pour chaque test. Dans le cas d'un SSD, la taille du fichier n'a pas beaucoup d'importance.
Cependant, notez que pour certains supports de stockage, la taille de l'image de l'unité de mesure de l'humidité est trop importante. fichier n'est pas aussi important que nombre total d'octets écrits pendant une courte période . Par exemple, certains SSD ont des performances beaucoup plus rapides avec des blocs pré-effacés ou ils peuvent avoir une petite zone de flash SLC qui est utilisée comme cache d'écriture et les performances changent une fois que le cache SLC est plein (par exemple, la série Samsung EVO qui a un cache SLC de 20-50 Go). Autre exemple, les disques durs Seagate SMR disposent d'une zone de cache PMR d'environ 20 Go dont les performances sont assez élevées, mais une fois qu'elle est pleine, l'écriture directe 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 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 vos accès en écriture sont en rafale avec des délais assez longs qui permettent au dispositif de nettoyer le cache interne, des séquences de test plus courtes refléteront mieux vos performances réelles. Si vous avez besoin de faire beaucoup d'entrées/sorties, vous devez augmenter à la fois la durée de vie du test et la durée de vie de la séquence. --io_size y --runtime paramètres. Notez que certains supports (par exemple, la plupart des bon marché ) souffriront de ces tests car les puces flash sont suffisamment pauvres pour s'user très rapidement. À mon avis, si un dispositif est suffisamment médiocre pour ne pas supporter ce type de test, il ne devrait pas être utilisé pour contenir des données de valeur dans tous les cas. Cela dit, ne répétez pas des tests d'écriture importants des milliers de fois car toutes les cellules flash auront un certain niveau d'usure avec l'écriture.
En outre, certains dispositifs SSD de haute qualité peuvent avoir des algorithmes 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 qu'elles sont encore dans le cache SLC. Pour ces dispositifs, si le fichier de test est plus petit que le cache SLC total du dispositif, le test complet écrit toujours dans le cache SLC uniquement et vous obtenez des performances supérieures à celles que le dispositif peut supporter pour des écritures plus importantes. Ainsi, pour ces périphériques, 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 dans la vie réelle. Si vous ne connaissez pas la charge de travail prévue, 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, effectuer un test d'écriture avec un fichier de test de 25 To prendra pas mal de 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 afin d'éviter d'obtenir de trop bons chiffres de la part d'appareils qui essaient de tricher dans les benchmarks en compressant les données avant de les écrire sur le 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 changer le répertoire qui est monté sur le périphérique que vous voulez tester. Le site fio supporte également l'utilisation d'un support direct comme cible de test, mais je vous conseille vivement de lire la page de manuel avant d'essayer car une faute de frappe peut écraser tout votre système d'exploitation lorsque l'on utilise l'accès direct au support de stockage (par exemple, écrire accidentellement sur le périphérique de l'OS au lieu du périphérique de test).
Si vous avez un bon SSD et que vous voulez voir des chiffres encore plus élevés, augmentez --numjobs ci-dessus. Cela définit la concurrence pour les lectures et les écritures. Les exemples ci-dessus ont tous numjobs réglé sur 1 Le test porte donc sur la lecture et l'écriture par un processus monotâche (éventuellement avec la profondeur de la file d'attente ou QD réglée sur iodepth ). Les SSD haut de gamme (par exemple Intel Optane 905p) devraient obtenir des chiffres élevés même sans augmenter numjobs beaucoup (par exemple 4 devrait suffire pour obtenir les spécifications les plus élevées), mais certains SSD "Enterprise" nécessitent de passer à la gamme 32 - 128 pour obtenir les chiffres des spécifications, car la latence interne de ces dispositifs est plus élevée, mais le débit global est fou. Notez que l'augmentation numbjobs à des valeurs élevées augmente généralement performance de référence mais reflète rarement les performances du monde réel.
Certains des paramètres de fio sont un peu étranges et peuvent être non optimaux. Par exemple, avoir une taille de bloc aussi importante (2Mbytes) lorsque vous faites de l'E/S directe avec un moteur d'E/S asynchrone est susceptible de conduire à beaucoup de fractionnement dans le noyau, créant ainsi de la surcharge. L'envoi de messages périodiques fsync alors que vous ne faites que des lectures semble également inhabituel. Je suis d'accord pour dire que fio est utile mais je recommanderais aux lecteurs d'étudier attentivement les paramètres qu'ils souhaitent utiliser avec plutôt que de simplement les copier mot à mot de la version 20180102 de la réponse ci-dessus....
@Anon : vous avez raison, l'optimum pour la lecture séquentielle serait de faire correspondre /sys/block/sd?/queue/max_sectors_kb car elle peut être inférieure à la limite matérielle réelle, qui est généralement bien supérieure aux 2 Mo de l'exemple ci-dessus. Cependant, je suppose que le léger surcoût causé par le CPU n'a pas d'importance par rapport à la vitesse du périphérique d'E/S réel. Le site fsync n'est pas une opération de lecture et n'affecte donc pas les résultats - je l'ai conservé pour faciliter la compréhension des différences entre les différentes lignes de commande. Avez-vous des problèmes pour que les résultats correspondent aux spécifications du fabricant ?
Pas exactement, j'ai juste une (certaine) 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 s'il est disponible (mais vous pouvez supposer 64Kbytes s'il est 0 - c'est ce que fait le noyau).Pas exactement, j'ai juste (un peu) d'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 s'il est disponible (mais vous pouvez supposer 64Kbytes s'il est 0 - c'est ce que fait le noyau).
Je ne recommanderais pas d'utiliser /dev/urandom parce que c'est un logiciel et qu'il est lent comme un cochon. Il vaut mieux prendre des morceaux de données aléatoires sur un disque RAM. Sur un disque dur, tester l'aléatoire n'a pas d'importance, car chaque octet est écrit tel quel (également sur un ssd avec dd). Mais si nous testons un pool zfs dédupliqué avec des données purement 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 pour les opérations sur les fichiers.
Pour mesurer réellement la vitesse du disque et non de la mémoire, nous devons synchroniser le système de fichiers pour éliminer l'effet de cache. Cela peut être fait facilement en :
time sh -c "dd if=/dev/zero of=testfile bs=100k count=1k && sync"avec cette méthode, vous obtenez un résultat :
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.124sdonc le débit du disque est juste 104857600 / 0.441 = 237772335 B/s --> 237MB/s
C'est plus de 100 Mo/s de moins qu'avec la mise en cache.
Bon benchmarking,
Faites attention à l'utilisation de zéros pour vos données d'écriture - certains disques (comme les SSD) et certains systèmes de fichiers auront un chemin d'accès spécial pour cela. Cela entraîne des chiffres de référence artificiellement élevés lors de l'utilisation de tampons zéro. D'autres modèles de données hautement compressibles peuvent également fausser les résultats...
Si vous souhaitez surveiller la vitesse de lecture et d'écriture du disque en temps réel, vous pouvez utiliser la commande 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 iotopCet outil est utile pour comprendre comment un disque se comporte pour une charge de travail spécifique par rapport à des tests plus généraux et théoriques.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
2 votes
Une question similaire a été posée sur unix.stackexchange.com/questions/108838/ , stackoverflow.com/questions/1198691/ y serverfault.com/questions/219739/ .