Réponses:
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.
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
-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.
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.
Si vous avez besoin de tests plus rigoureux sur vos disques durs, vous pouvez utiliser Bonnie ++ .
hdparmaussi, pour des repères rapides. Le seul inconvénient est que seuls les points de repère de la bande passante en lecture et les performances de nombreux types de périphériques en mode bloc (par exemple, RAID, iSCSI) peuvent être très asymétriques. Pour comparer les performances "avant" et "après" sur la même boîte, ddfonctionne bien aussi.
hdparm+ ddou juste bonnie++ou tous les 3.
(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:
Etc.
Voici une courte liste des outils les plus faciles à exécuter en haut et difficiles / plus approfondis / meilleurs plus près du bas:
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 .
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:
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.
postgresql-contribpaquet.
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.
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.)