Comment puis-je comparer mon disque dur?

J'ai vu des commandes pour évaluer son disque dur tel que celui-ci en utilisant dd:

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"

Existe-t-il de meilleures méthodes pour le faire?

J'utilise habituellement hdparmpour comparer mes disques durs. Vous pouvez analyser les lectures directes et les lectures en cache. Vous devrez exécuter les commandes plusieurs fois pour établir une valeur moyenne.

Exemples

Voici une lecture directe.

$ sudo hdparm -t /dev/sda2

/dev/sda2:
 Timing buffered disk reads: 302 MB in  3.00 seconds = 100.58 MB/sec

Et voici une lecture en cache.

$ sudo hdparm -T /dev/sda2

/dev/sda2:
 Timing cached reads:   4636 MB in  2.00 seconds = 2318.89 MB/sec

Détails

-t     Perform  timings  of  device reads for benchmark and comparison 
       purposes.  For meaningful results, this operation should be repeated
       2-3 times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays  
       the  speed of reading through the buffer cache to the disk without 
       any prior caching of data.  This measurement is an indication of how 
       fast the drive can sustain sequential data reads under Linux, without 
       any filesystem overhead.  To ensure accurate  measurements, the 
       buffer cache is flushed during the processing of -t using the 
       BLKFLSBUF ioctl.

-T     Perform timings of cache reads for benchmark and comparison purposes.
       For meaningful results, this operation should be repeated 2-3
       times on an otherwise inactive system (no other active processes) 
       with at least a couple of megabytes of free memory.  This displays
       the speed of reading directly from the Linux buffer cache without 
       disk access.  This measurement is essentially an indication of the
       throughput of the processor, cache, and memory of the system under 
       test.

Utiliser dd

Moi aussi j'ai utilisé ddpour ce type de test aussi. Une modification que je voudrais faire à la commande ci - dessus est d'ajouter ce bit à la fin de votre commande, ; rm ddfile.

$ time sh -c "dd if=/dev/zero of=ddfile bs=8k count=250000 && sync"; rm ddfile

Cela supprimera le message une ddfilefois la commande terminée. REMARQUE: ddfile est un fichier transitoire que vous n'avez pas besoin de conserver, c'est le fichier sur lequel vous ddécrivez ( of=ddfile) lors du chargement de votre disque dur.

Aller plus loin

Si vous avez besoin de tests plus rigoureux sur vos disques durs, vous pouvez utiliser Bonnie ++ .

Références

• Comment utiliser 'dd' pour évaluer votre disque ou votre processeur?
• Benchmark disque IO avec DD et Bonnie ++

(C'est une question très populaire - vous pouvez en voir des variantes sur les sites https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/203726 et https://askubuntu.com/q / 87035/740413 )

Existe-t-il de meilleures méthodes [que dd] pour [analyser les disques]?

Oui, mais leur exécution prendra plus de temps et nécessitera une connaissance de l’interprétation des résultats - il n’existe pas de chiffre unique permettant de tout savoir en une seule fois, car les éléments suivants ont une influence sur le type de test à exécuter:

• Êtes-vous intéressé par les performances des E / S aléatoires, séquentielles ou un mélange des deux?
• Lisez-vous ou écrivez-vous sur le disque (ou un mélange des deux)?
• Êtes-vous préoccupé par la latence, le débit ou les deux?
• Essayez-vous de comprendre le fonctionnement de différentes parties du même disque dur (accélère généralement le rapprochement plus rapidement du centre des disques en rotation)?
• Souhaitez-vous savoir comment un système de fichiers donné fonctionnera lorsque vous utiliserez votre disque ou souhaitez-vous obtenir des résultats plus proches des performances brutes du disque en effectuant des E / S directement sur un périphérique en mode bloc?
• Êtes-vous intéressé par les performances d'une taille particulière d'E / S?
• Soumettez-vous les E / S de manière synchrone ou asynchrone?
• Quelle quantité d'E / S envoyez-vous (soumettez trop peu la mauvaise manière et toutes les E / S pourraient être mises en cache afin que vous finissiez par tester la vitesse de votre RAM plutôt que celle du disque)?
• Dans quelle mesure le contenu des données que vous écrivez est-il compressible (par exemple, seules les données zéro sont hautement compressibles et certains systèmes de fichiers / disques ont même un raccourci spécial pour les données nulles aboutissant à des nombres impossibles à obtenir avec d'autres contenus)?

Etc.

Voici une courte liste des outils les plus faciles à exécuter en haut et difficiles / plus approfondis / meilleurs plus près du bas:

1. dd (lectures ou écritures séquentielles, affiche uniquement le débit, peut être configuré pour utiliser un système de fichiers ou un périphérique en mode bloc, peut être configuré pour contourner le cache de bloc / attendre que les E / S soient réellement terminées)
2. hdparm (lectures séquentielles uniquement, affiche uniquement le débit, n'utilise jamais de système de fichiers, peut être configuré pour contourner le cache de bloc, le test de cache ne relit que les 2 Mo de départ)
3. Le benchmark de GNOME Disk Utility (facile à exécuter, n’utilise jamais de système de fichiers, mais nécessite une installation complète de GNOME, donne les nombres de latence et de débit pour différents types d’E / S mais la charge de travail en écriture est en lecture / écriture / fsync par taille d’échantillon).
4. fio (peut presque tout faire et donne des résultats détaillés, mais nécessite une configuration et une compréhension de la manière d'interpréter lesdits résultats). Voici ce que Linus en dit:

   Greg - récupère le code FIO de Jens. Il fait les choses correctement, y compris l'écriture de contenu pseudo-aléatoire réel, ce qui indique si le disque effectue une "déduplication" (ou "optimiser pour les tests de performance"):

   [ https://github.com/axboe/fio/ ]

   Tout le reste est suspect - oubliez Bonnie ou d'autres outils traditionnels.

Source: commentaire laissé sur Google Plus à Greg Kroah-Hartman par Linus Torvalds .

avec l'outil IOPS

Si vous ne voulez pas lire tout cela, je vous recommande simplement l' outil IOPS . Il vous indiquera la vitesse réelle en fonction de la taille du bloc.

Autrement, lorsque je ferais un test de performance d'entrée-sortie, je regarderais les choses suivantes:

• BlockSize / cache / IOPS / direct vs buffered / async vs sync
• lire écrire
• les fils
• latence

• Utilisation du processeur

• Quelle taille de bloc utiliserez-vous ? Si vous souhaitez lire / écrire 1 Go à partir du / sur le disque, ce sera rapide si vous effectuez une opération d’E / S. Mais si votre application a besoin d'écrire des fragments de 512 octets sur tout le disque dur en morceaux non séquentiels (appelés E / S aléatoires bien que ce ne soit pas aléatoire), l'apparence sera différente. Désormais, les bases de données effectuent des E / S aléatoires pour le volume de données et des E / S séquentielles pour le volume de journalisation en raison de leur nature . Donc, vous devez d’abord savoir clairement ce que vous voulez mesurer. Si vous souhaitez copier des fichiers vidéo volumineux, cela est différent de celui que vous souhaitez installer Linux.

  Cette taille de bloc affecte le nombre d'opérations d'E / S que vous effectuez. Si vous effectuez, par exemple, 8 opérations de lecture (ou d'écriture, mais pas de mélange) séquentielles, le planificateur d'E / S du système d'exploitation les fusionnera. Si ce n'est pas le cas, le cache du contrôleur fera la fusion. Il n'y a pratiquement aucune différence si vous lisez 8 blocs séquentiels de 512 octets ou un bloc de 4096 octets. Une exception - si vous parvenez à effectuer une synchronisation directe d'E / S et attendez les 512 octets avant de demander les 512 octets suivants. Dans ce cas, augmenter la taille du bloc revient à ajouter du cache.

  Vous devez également savoir qu'il existe des E / S synchronisées et asynchrones: avec Sync IO, vous ne pourrez pas émettre la prochaine demande d'E / S avant que la requête actuelle ne soit renvoyée. Avec les entrées / sorties asynchrones, vous pouvez demander, par exemple, 10 blocs de données, puis attendre leur arrivée. Les threads de base de données distincts utilisent généralement SynO IO pour les journaux et async IO pour les données. L’outil IOPS s’occupe de cela en mesurant toutes les tailles de blocs pertinentes à partir de 512 octets.

• Voulez-vous lire ou écrire : La lecture est généralement plus rapide que l'écriture. Mais notez que la mise en cache fonctionne de manière tout à fait différente pour les lectures et les écritures:

  • Pour les écritures, les données seront transmises au contrôleur et, s'il est mis en cache, il en accusera réception avant que les données ne soient sur le disque, à moins que le cache ne soit plein. À l'aide de l'outil iozone, vous pouvez dessiner de superbes graphiques de plateaux d'effets de cache (effet de cache CPU et effet de cache). Les caches deviennent moins efficaces au fur et à mesure que plus on écrit

  • Pour les lectures, les données lues sont conservées dans le cache après la première lecture. Les premières lectures sont les plus longues et la mise en cache devient de plus en plus efficace pendant les périodes de disponibilité. Les caches remarquables sont le cache de la CPU, le cache du système de fichiers du système d'exploitation, le cache du contrôleur IO et le cache du stockage. L'outil IOPS mesure uniquement les lectures. Cela lui permet de "lire partout" et vous ne voulez pas qu'il écrive au lieu de lire.

• Combien de threads utiliserez-vous : Si vous utilisez un seul thread (en utilisant dd pour les tests de performances du disque ), vous obtiendrez probablement des performances bien pires que celles de plusieurs threads. L'outil IOPS en tient compte et lit sur plusieurs threads.

• Quelle est l’importance de la latence pour vous ? Dans les bases de données, la latence des E / S devient extrêmement importante. Toute commande SQL insertion / mise à jour / suppression sera écrite dans le journal de la base de données ("log" dans la langue de la base de données) lors de la validation avant son acquittement. Cela signifie que la base de données complète attend peut-être que cette opération d'E / S soit terminée. Je montre ici comment mesurer le temps d'attente moyen (wait) à l'aide de l' outil iostat .

• Quelle est l’importance de l’utilisation du processeur : votre processeur peut facilement devenir un goulot d’étranglement pour les performances de votre application. Dans ce cas, vous devez savoir combien de cycles de processeur sont brûlés par octet lu / écrit et optimiser dans cette direction. Cela peut signifier que vous souhaitez ou non utiliser une mémoire flash PCIe en fonction des résultats de vos mesures. Là encore, l’ outil iostat peut vous donner une estimation approximative de l’utilisation de la CPU par vos opérations IO.

Si vous avez installé PostgreSQL, vous pouvez utiliser leur excellent benchmark pg_test_fsync . Il teste essentiellement vos performances de synchronisation d’écriture.

Sur Ubuntu, vous le trouverez ici: /usr/lib/postgresql/9.5/bin/pg_test_fsync

L'avantage, c'est que cet outil vous montrera pourquoi les disques SSD d'entreprise valent la peine de dépenser plus.

Vous pouvez utiliser fio- l’ outil de génération d’IO multithread . Il est emballé par plusieurs distributions, par exemple Fedora 25, Debian et OpenCSW.

L'outil fio est très flexible, il peut facilement être utilisé pour comparer différents scénarios d'E / S, y compris des scénarios simultanés. Le paquet est fourni avec quelques exemples de fichiers de configuration (cf. par exemple /usr/share/doc/fio/examples). Il mesure correctement les choses, c’est-à-dire qu’il imprime également l’écart-type et des statistiques quantitatives pour certains chiffres. Des choses que d'autres outils d'analyse comparative populaires ne se soucient pas.

Un exemple simple (une séquence de scénarios simples: séquentiel / aléatoire X en lecture / écriture):

$ cat fio.cfg
[global]
size=1g
filename=/dev/sdz

[randwrite]
rw=randwrite

[randread]
wait_for=randwrite
rw=randread
size=256m

[seqread]
wait_for=randread
rw=read

[seqwrite]
wait_for=seqread
rw=write

L'appel:

# fio -o fio-seagate-usb-xyz.log fio.cfg
$ cat fio-seagate-usb-xyz.log
[..]
randwrite: (groupid=0, jobs=1): err= 0: pid=11858: Sun Apr  2 21:23:30 2017
  write: io=1024.0MB, bw=16499KB/s, iops=4124, runt= 63552msec
clat (usec): min=1, max=148280, avg=240.21, stdev=2216.91
 lat (usec): min=1, max=148280, avg=240.49, stdev=2216.91
clat percentiles (usec):
 |  1.00th=[    2],  5.00th=[    2], 10.00th=[    2], 20.00th=[    7],
 | 30.00th=[   10], 40.00th=[   11], 50.00th=[   11], 60.00th=[   12],
 | 70.00th=[   14], 80.00th=[   16], 90.00th=[   19], 95.00th=[   25],
 | 99.00th=[ 9408], 99.50th=[10432], 99.90th=[21888], 99.95th=[38144],
 | 99.99th=[92672]
bw (KB  /s): min= 7143, max=371874, per=45.77%, avg=15104.53, stdev=32105.17
lat (usec) : 2=0.20%, 4=15.36%, 10=6.58%, 20=69.35%, 50=6.07%
lat (usec) : 100=0.49%, 250=0.07%, 500=0.01%, 750=0.01%
lat (msec) : 4=0.01%, 10=1.20%, 20=0.54%, 50=0.08%, 100=0.03%
lat (msec) : 250=0.01%
  cpu          : usr=1.04%, sys=4.79%, ctx=4977, majf=0, minf=11
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
 submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
 issued    : total=r=0/w=262144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
 latency   : target=0, window=0, percentile=100.00%, depth=1
randread: (groupid=0, jobs=1): err= 0: pid=11876: Sun Apr  2 21:23:30 2017
  read : io=262144KB, bw=797863B/s, iops=194, runt=336443msec
[..]
bw (KB  /s): min=  312, max= 4513, per=15.19%, avg=591.51, stdev=222.35
[..]

Notez que la [global]section a des valeurs par défaut globales qui peuvent être remplacées par d’autres sections. Chaque section décrit un travail. Le nom de la section est le nom du travail et peut être choisi librement. Par défaut, différents travaux sont démarrés en parallèle. Ainsi, l'exemple ci-dessus sérialise explicitement l'exécution du travail avec la wait_forclé. En outre, fio utilise une taille de bloc de 4 Ko - qui peut également être modifiée. L'exemple utilise directement le périphérique brut pour les tâches de lecture et d'écriture. Assurez-vous donc que vous utilisez le bon périphérique. L'outil prend également en charge l'utilisation d'un fichier / répertoire sur les systèmes de fichiers existants.

Autres outils

L' hdparmutilitaire fournit un repère de lecture très simple, par exemple:

# hdparm -t -T /dev/sdz

Il ne remplace pas un outil d'analyse comparative de pointe tel que fio, il devrait simplement être utilisé pour un premier contrôle de vraisemblance. Par exemple, pour vérifier si le lecteur USB 3 externe est reconnu à tort comme un périphérique USB 2 (vous obtiendrez alors des débits de ~ 100 Mio / s contre ~ 30 Mio / s).

Comme indiqué ici , vous pouvez utiliser gnome-disks(si vous utilisez Gnome).

Cliquez sur le lecteur que vous souhaitez tester, puis sur "Options de partition supplémentaires" (les roues). Puis Benchmark Partition. Vous obtiendrez une lecture / écriture moyenne en Mo / s et des temps d'accès moyens en millisecondes. J'ai trouvé ça très confortable.

C'est un peu grossier, mais ça marche un peu:

find <path> -type f -print0 | cpio -0o >/dev/null

Vous pouvez faire des choses intéressantes avec cette technique, y compris la mise en cache de tous les fichiers /libet /usr/bin. Vous pouvez également l'utiliser dans le cadre d'un effort d'analyse comparative:

find / -xdev -type f -print0 | 
sort -R --from0-file=- | 
timeout "5m" cpio -0o >/dev/null

Tous les noms de fichiers sur la racine sont trouvés, triés de manière aléatoire et copiés dans la mémoire cache pendant une minute maximum. La sortie de cpio vous indique combien de blocs ont été copiés. Répétez 3 fois pour obtenir une moyenne de blocs à la minute. (Notez que l'opération de recherche / tri peut prendre beaucoup de temps - beaucoup plus longtemps que la copie. Il serait préférable de mettre en cache la recherche / tri et de l'utiliser splitpour obtenir un échantillon de fichiers.)