J'utilise habituellement hdparm pour comparer mes disques durs. Vous pouvez évaluer à la fois 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 jj
Moi aussi j'ai utilisé dd également pour ce type de test. Une modification que j'apporterais à la commande ci-dessus consiste à 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 écrit à (of=ddfile ), lorsqu'il charge votre disque dur.
Aller au-delà
Si vous avez besoin de tests plus rigoureux de vos disques durs, vous pouvez utiliser Bonnie++.
Références
- Comment utiliser "dd" pour comparer votre disque ou votre processeur ?
- Comparer les E/S disque avec DD et Bonnie++
(C'est 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/740413 )
Existe-t-il de meilleures méthodes [que jj] pour [disques de référence] ?
Oui, mais ils prendront plus de temps à s'exécuter et nécessiteront des connaissances sur la façon d'interpréter les résultats - il n'y a pas de chiffre unique qui vous dira tout en une seule 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 ?
- 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 les performances de différentes parties d'un même disque dur (généralement une vitesse plus rapide plus près du centre des disques en rotation) ?
- Êtes-vous intéressé par les performances d'un système de fichiers donné 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 bloc ?
- Êtes-vous intéressé par les performances d'une taille d'E/S particulière ?
- 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, vous finissant 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-il compressible ?
Et ainsi de suite.
Voici une courte liste d'outils avec les plus faciles à exécuter en haut et les plus difficiles/plus approfondis/meilleurs plus près du 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 réellement 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)
- Le benchmark de l'utilitaire de disque GNOME (facile à exécuter, n'utilise jamais de système de fichiers, graphique mais nécessite une installation complète de GNOME, donne des chiffres de latence et de débit pour différents types d'E/S, mais la charge de travail d'écriture fait en fait lecture/écriture/fsync par échantillon taille).
- 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 - obtenez le code FIO de Jens. Il fait les choses correctement, y compris l'écriture de contenu pseudo-aléatoire réel, qui indique si le disque effectue une "déduplication" (c'est-à-dire "optimiser pour les benchmarks) :
[ 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 vous recommande simplement l'outil IOPS. Il vous indiquera la vitesse réelle en fonction de la taille du bloc.
Sinon - lors d'un benchmark IO, je regarderais les choses suivantes :
- taille de bloc/cache/IOPS/direct vs mis en mémoire tampon/async vs sync
- lire/écrire
- threads
- latence
-
Utilisation du processeur
-
Quelle taille de bloc allez-vous utiliser :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 des morceaux 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), cela se présentera différemment. Désormais, les bases de données effectueront 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 faites par ex. 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 effectuera la fusion. Il n'y a pratiquement aucune différence si vous lisez 8 blocs séquentiels de 512 octets ou un morceau de 4096 octets. Une exception - si vous parvenez à effectuer une synchronisation directe des 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 être conscient qu'il existe des E/S synchronisées et asynchrones :avec les E/S synchronisées, vous n'émettez pas la prochaine demande d'E/S avant le retour de l'actuelle. Avec async IO, vous pouvez demander par ex. 10 blocs de données, puis attendez qu'ils arrivent. Les threads de base de données distincts utilisent généralement des E/S de synchronisation pour le journal et des E/S asynchrones pour les données. L'outil IOPS s'en charge en mesurant toutes les tailles de bloc pertinentes à partir de 512 octets.
-
Lisez-vous ou écrivez-vous :Habituellement, la lecture est plus rapide que l'écriture. Mais notez que la mise en cache fonctionne de manière assez 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 accusera réception avant que les données ne soient sur le disque, sauf si le cache est plein. A l'aide de l'outil iozone vous pouvez dessiner de beaux graphes de plateaux d'effets de cache (effet cache CPU et effet cache tampon). Les caches deviennent moins efficaces au fur et à mesure que l'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 prennent plus de temps et la mise en cache devient de plus en plus efficace pendant la disponibilité. Les caches notables sont le cache 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 seules mesures lit. Cela lui permet de "lire partout" et vous ne voulez pas qu'il écrive au lieu de lire.
-
-
Combien de fils allez-vous utiliser :Si vous utilisez un seul thread (en utilisant dd pour les benchmarks de disque), vous obtiendrez probablement une bien pire performance qu'avec plusieurs threads. L'outil IOPS en tient compte et lit sur plusieurs fils.
-
Quelle est l'importance de la latence pour vous :En ce qui concerne les bases de données, la latence des E/S devient extrêmement importante. Toute commande SQL d'insertion/mise à jour/suppression 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 reconnue. Cela signifie que la base de données complète peut attendre que cette opération IO soit terminée. Je montre ici comment mesurer le temps d'attente moyen (attente) à l'aide de l'outil iostat .
-
Quelle est l'importance de l'utilisation du processeur pour vous :Votre processeur peut facilement devenir le goulot d'étranglement des performances de votre application. Dans ce cas, vous devez savoir combien de cycles CPU sont brûlés par octet lu/écrit et optimiser dans cette direction. Cela peut signifier de 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 d'E/S.