Comment comparer mon disque dur?
J'ai vu des commandes pour comparer son disque dur comme celle-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 généralement hdparm pour comparer mes disques durs. Vous pouvez comparer à la fois les lectures directes et les lectures mises en cache. Vous voudrez 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.
Utilisation de dd
J'ai également utilisé dd pour ce type de test. Une modification que j'apporterais à 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 ddfile une fois la commande terminée. REMARQUE: ddfile est un fichier transitoire que vous n'avez pas besoin de conserver, c'est le fichier que dd est Ecrire à (of=ddfile), quand il met votre disque dur sous charge.
Aller plus loin
Si vous avez besoin de tests plus rigoureux de vos disques durs, vous pouvez utiliser Bonnie ++ .
Références
(Il s'agit d'une question très populaire - vous pouvez en voir des variantes sur https://stackoverflow.com/q/1198691 , https://serverfault.com/q/219739/ 203726 et https://askubuntu.com/q/87035/74041 )
Existe-t-il de meilleures méthodes [que dd] pour [comparer les disques]?
Oui, mais ils prendront plus de temps à exécuter et nécessiteront des connaissances sur la façon d'interpréter les résultats - il n'y a pas de numéro unique qui vous dira tout en une fois, car les éléments suivants influencent le type de test que vous devez exécuter:
- Êtes-vous intéressé par les performances des E/S aléatoires, séquentielles ou un mélange des deux?
- Êtes-vous en train de lire ou d'écrire 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 comment les différentes parties d'un même disque dur fonctionnent (accélère généralement plus rapidement vers le centre des disques en rotation)?
- Êtes-vous intéressé par la façon dont un système de fichiers donné fonctionnera lors de l'utilisation de votre disque ou souhaitez-vous des résultats plus proches des performances brutes du disque en effectuant des E/S directement sur un périphérique de bloc?
- Êtes-vous intéressé par la performance d'une taille particulière d'E/S?
- Soumettez-vous les E/S de manière synchrone ou asynchrone?
- Combien d'E/S soumettez-vous (soumettez trop peu dans le mauvais sens et toutes les E/S pourraient être mises en cache afin que vous finissiez par tester la vitesse de votre RAM plutôt que la vitesse du disque) )?
- Dans quelle mesure le contenu des données que vous écrivez est compressible (par exemple, les données zéro uniquement sont hautement compressibles et certains systèmes de fichiers/disques ont même un raccourci spécial pour les données zéro uniquement, ce qui conduit à des nombres qui ne peuvent pas être obtenus avec d'autres contenus)?
Etc.
Voici une courte liste d'outils avec les plus faciles à exécuter en haut et difficiles/plus approfondis/mieux en bas:
- 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 de bloc, peut être configuré pour contourner le cache de bloc/attendre que les E/S soient vraiment terminées)
- 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)
- Référence de GNOME Disk Utility (facile à exécuter, n'utilise jamais de système de fichiers, graphique mais nécessite une installation complète de GNOME, donne la latence et les nombres de débit pour différents types d'E/S mais la charge de travail d'écriture fait en fait lecture/écriture/fsync par taille d'échantillon).
- fio (peut faire presque n'importe quoi et donne des résultats détaillés mais nécessite une configuration et une compréhension de la façon 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 montre si le disque fait une certaine "déduplication" (alias "optimiser pour les tests de performances):
[ 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 pouvez pas prendre la peine de lire tout cela, je recommanderais simplement outil IOPS . Il vous indiquera la vitesse du monde réel en fonction de la taille du bloc.
Sinon - en faisant un IO benchmark je regarderais les choses suivantes:
- taille de bloc/cache/IOPS/direct vs tamponné/async vs synchronisation
- lire écrire
- fils
- latence
Utilisation du processeur
Quelle taille de bloc utiliserez-vous : Si vous souhaitez lire/écrire 1 Go depuis/vers le disque, cela sera rapide si vous effectuez une opération d'E/S. Mais si votre application a besoin d'écrire dans des morceaux de 512 octets sur le disque dur en morceaux non séquentiels (appelés E/S aléatoires bien que ce ne soit pas aléatoire), cela se présentera différemment. Maintenant, les bases de données feront des E/S aléatoires pour le volume de données et des E/S séquentielles pour le volume de journal en raison de leur nature . Donc, vous devez d'abord clarifier ce que vous voulez mesurer. Si vous souhaitez copier des fichiers vidéo volumineux, c'est différent de si vous souhaitez installer Linux.
Cette taille de bloc affecte le nombre d'opérations d'E/S que vous effectuez. Si vous le faites par exemple 8 opérations séquentielles de lecture (ou d'écriture, mais pas mixtes) 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 à synchroniser directement IO 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 de synchronisation et asynchrone: avec sync IO, vous n'émettrez pas la prochaine IO requête avant le retour de la requête en cours). Avec async IO vous pouvez par exemple demander 10 morceaux de données et ensuite attendre à mesure qu'ils arrivent. Les threads de base de données distincts utilisent généralement sync IO pour le journal et async IO pour les données. L'outil IOPS s'en charge en mesurant toutes les tailles de blocs pertinentes à partir de 512 octets.
Allez-vous lire ou écrire : Habituellement, la lecture est plus rapide que l'écriture. Mais notez que la mise en cache fonctionne d'une manière très différente pour les lectures et les écritures:
Pour les écritures, les données seront transmises au contrôleur et s'il se met en cache, il accusera réception avant que les données ne soient sur le disque, sauf si le cache est plein. En utilisant l'outil iozone vous pouvez dessiner de beaux graphiques de plateaux d'effets de cache (effet de cache CPU et effet de cache tampon). Les caches deviennent moins efficaces plus ils ont été écrits.
Pour les lectures, les données lues sont conservées dans le cache après la première lecture. Les premières lectures prennent plus de temps et la mise en cache devient de plus en plus efficace pendant la disponibilité. Les caches notables sont le cache du processeur, 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 ne mesure que les lectures, ce qui 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 thread ( en utilisant dd pour les benchmarks de disque ) vous obtiendrez probablement beaucoup performances moins bonnes qu'avec plusieurs threads. L'outil IOPS en tient compte et lit sur plusieurs threads.
Quelle est l'importance de la latence pour vous : En regardant les bases de données, IO la latence devient extrêmement importante. Toute insertion/mise à jour/suppression La commande SQL sera écrite dans le journal de la base de données ("log" dans le jargon de la base de données) lors de la validation avant d'être acquittée. Cela signifie que la base de données complète peut attendre que cette opération IO soit terminée. I montrer ici comment mesurer le temps d'attente moyen (attendre) en utilisant l'outil iostat .
Quelle est l'importance de l'utilisation du CPU pour vous : Votre CPU peut facilement devenir le goulot d'étranglement pour les performances de votre application. Dans ce cas, vous devez savoir combien de cycles CPU sont brûlés par octet en lecture/écriture et optimiser dans cette direction. Cela peut signifier décider pour/contre la mémoire flash PCIe en fonction de vos résultats de mesure. Encore une fois, l'outil iostat peut vous donner une estimation approximative de l'utilisation du processeur 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 trouvez ici: /usr/lib/postgresql/9.5/bin/pg_test_fsync
La grande chose à ce sujet, c'est que cet outil vous montrera pourquoi les SSD d'entreprise valent les dollars supplémentaires.
Vous pouvez utiliser fio - le Multithreaded IO generation tool . Il est conditionné par plusieurs distributions, par exemple Fedora 25, Debian et OpenCSW.
L'outil fio est très flexible, il peut être facilement utilisé pour comparer différents scénarios IO - y compris des scénarios simultanés. Le paquet est livré 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 les statistiques quantitatives pour certains chiffres. Certains autres outils d'analyse comparative populaires ne se soucient pas.
Un exemple simple (une séquence de scénarios simples: lecture/écriture X séquentielle/aléatoire):
$ 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 le [global] la 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 librement choisi. 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 le wait_for clé. De plus, 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 travaux 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'utilitaire hdparm fournit une référence de lecture très simple, par exemple:
# hdparm -t -T /dev/sdz
Il ne remplace pas un outil d'analyse comparative de pointe comme fio, il doit simplement être utilisé pour un premier contrôle de plausibilité. Par exemple, pour vérifier si le lecteur USB 3 externe est incorrectement reconnu comme périphérique USB 2 (vous verrez alors des débits de ~ 100 Mio/s contre ~ 30 Mio/s).
C'est un peu grossier, mais cela fonctionne à la rigueur:
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 /lib et /usr/bin des dossiers. 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 à la racine sont trouvés, triés aléatoirement et copiez-les dans le cache pendant 1 minute maximum. La sortie de cpio vous indique le nombre de blocs copiés. Répétez 3 fois pour obtenir une moyenne de blocs par minute. (Remarque: 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 d'utiliser split pour obtenir un échantillon de fichiers.)
Comme indiqué ici ici , vous pouvez utiliser gnome-disks (si vous utilisez Gnome).
Cliquez sur le lecteur que vous souhaitez tester et cliquez sur "Options de partition supplémentaires" (les roues). Alors 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.