Agrandir
/
Ars Technica déconseille de retirer le capot de protection de votre disque dur ou de le mettre en feu dans les paramètres de production.
Guillaume Warby
commentaires des lecteurs
155
avec 77 affiches participantes, y compris l'auteur de l'histoire
Partagez cette histoire
Partager sur Facebook
Partager sur Twitter
Partager sur Reddit
Fondamentaux du stockage
OpenZFS 2.1 est sorti - parlons de ses tout nouveaux vdevs dRAID
Retour à RAID : Les lecteurs Ars « Et si ? » édition
ZFS contre RAID : huit disques Ironwolf, deux systèmes de fichiers, un gagnant
ZFS 101—Comprendre le stockage et les performances ZFS
Comprendre le RAID : comment les performances passent d'un disque à huit
Voir plus d'histoires
Lectures complémentaires
Comment Ars teste les équipements Wi-Fi (et vous pouvez aussi)
Analyse comparative du stockage, un peu comme
Benchmark Wi-Fi
- est un art noir largement incompris. Les administrateurs et les passionnés ont été tentés pendant des décennies de simplement "obtenir le grand nombre" en lisant ou en écrivant une grande quantité de données sur un disque, en obtenant un chiffre en Mo/sec et en l'appelant par jour. Malheureusement, la charge de travail réelle d'un disque typique ne ressemble pas à cela, et ce « simple test de vitesse » ne reproduit pas la plupart des goulots d'étranglement qui ralentissent l'accès au disque dans les systèmes du monde réel.
La façon la plus réaliste de tester et de comparer les disques est, bien sûr, de simplement les utiliser et de voir ce qui se passe. Malheureusement, ce n'est ni très reproductible, ni simple à analyser. Nous voulons donc un outil d'analyse comparative artificielle, mais nous en voulons un que nous puissions utiliser intelligemment pour tester les systèmes de stockage dans des scénarios réalistes qui modélisent bien notre utilisation quotidienne. Heureusement, nous n'avons pas à inventer un tel outil - il existe déjà un outil logiciel gratuit et open source appelé
fio
, et c'est même multiplateforme !
Nous allons vous présenter quelques utilisations simples mais efficaces de fio sur des ordinateurs Windows, Mac et Linux, mais avant cela, parlons un peu des systèmes de stockage d'un point de vue plus basique.
Débit, latence, IOPS et cache
Débit
Le débit, mesuré le plus souvent dans les systèmes de stockage en Mo/s, est le moyen le plus couramment utilisé pour parler des performances de stockage. Il y a plusieurs points d'étranglement dans un système de stockage pour le débit—d'abord et avant tout, il y a la vitesse du support physique lui-même. Si vous avez une seule tête sur un disque de rouille conventionnel tournant à 7 200 tr/min, la vitesse à laquelle vous pouvez obtenir des données sur ou hors de ce disque sera limitée par le nombre de secteurs/blocs physiques passant sous la tête. Vous êtes également limité par la bande passante de votre contrôleur et de votre câblage. Par exemple, les liaisons SATA modernes fonctionnent généralement à 6 Gbit/s, tandis que les liaisons SAS modernes peuvent fonctionner jusqu'à 22,5 Gbit/s.
Les choses deviennent un peu plus compliquées ici, car nous mélangeons des unités - notez le grand B en Mo/sec et le petit b en Gbps. C'est la différence entre les octets et les bits. Vous divisez Gbps par 8 pour obtenir Go/sec, puis multipliez par 1024 pour obtenir MB/sec. Ainsi, un lien SATA-3 6Gbps peut théoriquement se déplacer jusqu'à 768Mo/sec. Vous ne pouvez pas réellement déplacer les données sur le bus SATA ou SAS à la vitesse de liaison théorique maximale, mais vous pouvez vous en approcher assez près. Il convient également de noter que la plupart des contrôleurs SATA ne déplaceront pas beaucoup plus de données qu'un seul lien ne peut en gérer, même avec de nombreux disques connectés au contrôleur. 700 Mo/s.
Latence
La latence est le revers de la même médaille de performance. Alors que le débit fait référence au nombre d'octets de données par seconde que vous pouvez déplacer sur ou hors du disque, la latence (le plus souvent mesurée en millisecondes) fait référence au temps nécessaire pour lire ou écrire un seul bloc. La plupart des pires goulots d'étranglement du stockage sont des problèmes de latence qui affectent le débit, et non l'inverse.
Dans les disques de rouille en rotation conventionnels, il existe deux sources principales de latence : la latence de rotation et la latence de recherche. La latence de recherche est le temps qu'il faut pour déplacer le bras mécanique sur lequel la tête de disque est montée sur la bonne piste sur le disque. Une fois que la tête s'est déplacée sur la bonne piste, le lecteur doit alors attendre que le bon secteur tourne sous la tête - c'est la latence de rotation. La combinaison de la recherche et de la latence de rotation totalise généralement entre 15 ms et 25 ms.
Vous pouvez voir comment la latence affecte le débit par une expérience de pensée. Si nous avons un disque tournant raisonnablement rapide avec un débit maximum de 180 Mo/sec et une latence d'accès totale de 16 ms, et que nous lui présentons une charge de travail fragmentée au maximum, ce qui signifie qu'il n'y a pas deux blocs écrits/écrits dans l'ordre séquentiel. nous pouvons faire un peu de calcul pour arriver à ce débit. En supposant des blocs physiques de 4 Ko sur le disque, 4 Ko par recherche divisés par 0,016 seconde par recherche = seulement 250 Ko/sec. Aie!
IOPS
Abréviation de Input/Output Operations Per Second, IOPS est la métrique de mesure dont vous entendrez le plus souvent parler de vrais ingénieurs de stockage. Cela signifie exactement à quoi cela ressemble : combien d'opérations différentes un disque peut-il effectuer ? De la même manière, le "débit" fait généralement référence au débit maximal d'un disque, avec des lectures ou des écritures très volumineuses et éventuellement séquentielles, les IOPS font généralement référence au nombre maximal d'opérations qu'un disque peut desservir sur le bas de gamme - 4K lectures aléatoires et écrit.
Les disques à semi-conducteurs ne souffrent pas de latence de recherche ou de rotation, mais l'entrée/sortie aléatoire 4K (E/S) leur pose toujours des problèmes. Sous le capot, un SSD grand public n'est pas vraiment un seul "disque" - c'est une matrice RAID dans une petite boîte scellée, avec son propre contrôleur complexe à l'intérieur du disque lui-même gérant les lectures et les écritures. Le contrôleur SSD lui-même essaie de répartir les écritures sur plusieurs canaux de supports flash physiques en parallèle et, si l'utilisateur a de la chance, les écritures réparties uniformément sur ces canaux seront également lues de la même manière, maximisant ainsi le débit.
Lorsqu'un disque à semi-conducteurs est présenté avec une charge de travail d'E/S aléatoire 4K, s'il ne peut pas trouver un moyen d'agréger et de paralléliser les demandes, il finira par provoquer un goulot d'étranglement à des vitesses beaucoup plus faibles, dictées par la rapidité avec laquelle une seule cellule de flash media peut lire ou écrire un bloc de données. L'impact n'est pas aussi dramatique qu'il le serait sur un disque rouillé, mais il est toujours important, où un disque rouillé capable de 180 Mo/s de débit pourrait chuter à 250 Ko/s d'E/S aléatoires 4K, un SSD capable de 500 Mo /sec pourrait chuter à environ 40 Mo/sec.
Bien que vous puissiez discuter du débit en termes d'E/S aléatoires 4K et d'IOPS en termes d'E/S séquentielles de 1 Mo, ce n'est pas ainsi que chaque terme est généralement utilisé. Vous devez généralement vous attendre à ce que le débit soit discuté en termes de quantité de données qu'un disque déplace dans des conditions optimales, et les IOPS en termes de « grognement bas de gamme » dont le disque est capable même dans les pires charges de travail. Pour une utilisation typique d'un ordinateur de bureau, les IOPS sont bien plus importantes que le débit, car il y a beaucoup d'E/S aléatoires 4K lentes et cela ralentit l'ensemble du système lorsque cela se produit.
Cacher
Comme nous l'avons vu ci-dessus, les charges de travail non optimisées nuisent aux performances et les nuisent
mal
. Heureusement pour les utilisateurs, des décennies de recherche et de développement nous ont présenté toutes sortes d'astuces pour éviter d'explorer les pires caractéristiques de performance de notre stockage, en particulier le stockage de la rouille. Les systèmes d'exploitation utilisent à la fois des caches de lecture et des tampons d'écriture pour minimiser le nombre de recherches nécessaires en fonctionnement et éviter d'avoir à continuer à lire les blocs de stockage fréquemment nécessaires.
Les tampons d'écriture permettent au système d'exploitation de stocker un grand nombre de petites demandes d'E/S et de les valider sur disque en lots importants. Un mégaoctet correspond à une très petite quantité de données, mais cela revient toujours à 256 blocs de 4 Ko - et si vous devez écrire chacun de ces blocs avec des opérations individuelles, vous risquez de bloquer toute la capacité de service de votre disque pendant une seconde complète. D'un autre côté, si vous pouvez agréger ces 256 blocs dans un tampon d'écriture puis les vider en une seule opération, vous évitez toute cette latence d'accès et la même quantité de données peut être enregistrée en un centième de seconde ou moins. . Cette agrégation peut également grandement aider avec les vitesses de lecture plus tard. Si la plupart des mêmes blocs doivent être lus ultérieurement en tant que groupe, le lecteur peut éviter de chercher entre eux puisqu'ils ont tous été écrits en tant que groupe en premier lieu.
Publicité
Le cache de lecture évite au système de bloquer le stockage avec des demandes répétées inutiles pour les mêmes blocs encore et encore. Si votre système d'exploitation dispose de beaucoup de RAM, chaque fois qu'il lit des données sur le disque, il en garde une copie en mémoire. Si un autre programme demande les mêmes blocs plus tard, le système d'exploitation peut traiter cette demande directement à partir du cache, ce qui maintient les ressources limitées du lecteur disponibles pour les demandes de lecture ou d'écriture, ce qui
doit
frapper le disque réel.
Lectures complémentaires
Les SSD sont en passe de devenir plus gros et moins chers grâce à la technologie PLC
Certains modèles de SSD ont un cache d'écriture non volatile supplémentaire sur le disque lui-même, constitué d'un type de support flash plus rapide et plus coûteux. Par exemple, un SSD TLC ou QLC (Quad Layer Cell) peut avoir quelques gigaoctets de support MLC (Multi-Layer Cell) à utiliser comme tampon pour les écritures ; cela permet au SSD de suivre les écritures exigées par une charge de travail de bureau typique en utilisant le tampon MLC plus rapide, mais s'il est présenté avec des écritures lourdes soutenues pendant trop longtemps, le tampon MLC rapide se remplit et le débit chute à ce que le TLC ou le TLC plus lent Les médias QLC peuvent gérer. Il peut souvent s'agir d'un scénario de type « chute de la falaise », car le support le plus lent doit généralement non seulement supporter les écritures en cours, mais le faire tout en continuant à diffuser les écritures déjà acceptées à partir du tampon MLC rapide.
Modélisation réaliste de l'accès au stockage
Maintenant que nous comprenons un peu les points faibles d'un système de stockage, il est assez évident que nous ne devrions pas simplement utiliser un outil simple comme
jj
pour lire ou écrire d'énormes morceaux de données et générer des nombres énormes. Ces chiffres énormes ne correspondent pas vraiment aux performances de chaque disque sous des charges de travail plus réalistes. Nous souhaitons donc générer des modèles d'accès plus réalistes avec lesquels tester.
C'est ici que
fio
Fio est l'abréviation de Flexible Input/Output tester et peut être configuré pour modéliser presque toutes les charges de travail de stockage sous le soleil. Les vrais ingénieurs du stockage, du moins ceux qui font leur travail correctement, analyseront d'abord les modèles d'accès au stockage réels d'un serveur ou d'un service, puis écriront des scripts fio pour modéliser ces modèles exacts. De cette façon, ils peuvent tester un disque ou une baie non seulement pour ses performances générales, mais aussi pour ses performances applicables de manière très spécifique à leur charge de travail exacte.
Nous n'allons pas être aussi précis ici, mais nous utiliserons fio pour modéliser et rendre compte de certains modèles d'utilisation clés communs au stockage de bureau et de serveur. Le plus important d'entre eux est l'E/S aléatoire 4K, dont nous avons longuement discuté ci-dessus. 4K aléatoire est l'endroit où vit la douleur - c'est la raison pour laquelle votre ordinateur rapide et agréable avec un disque dur conventionnel sonne soudainement comme s'il moud du café et vous donne envie de
défenestrer
il dans la frustration.
Ensuite, nous examinons les E/S aléatoires de 64K, dans seize processus parallèles. Il s'agit en quelque sorte d'une charge de travail intermédiaire pour un ordinateur occupé : il y a beaucoup de demandes pour des quantités de données relativement petites, mais il y a aussi beaucoup de processus parallèles ; sur un système moderne, ce nombre élevé de processus parallèles est bon, car il permet potentiellement au système d'exploitation d'agréger de nombreuses petites requêtes en quelques requêtes plus importantes. Bien que loin d'être aussi pénibles que les E/S aléatoires 4K, les E/S aléatoires 64K sont suffisantes pour ralentir considérablement la plupart des systèmes de stockage.
Enfin, nous examinons le débit haut de gamme - certains des plus gros nombres que vous pouvez vous attendre à voir hors du système - au moyen d'E/S aléatoires de 1 Mo. Techniquement, vous pouvez toujours obtenir un
légèrement
plus grand nombre en demandant à fio de générer des requêtes vraiment séquentielles, mais dans le monde réel, celles-ci sont extrêmement rares. Si votre système d'exploitation a besoin d'écrire quelques lignes dans un journal système ou de lire quelques Ko de données à partir d'une bibliothèque système, votre lecture ou écriture "séquentielle" devient immédiatement, effectivement, 1 Mo d'E/S aléatoires car elle partage le temps avec le autre processus.
Installation de fio
les fenêtres
Vous pouvez trouver des programmes d'installation Windows pour fio sur
https://bsdio.com/fio/
. Notez que vous pouvez recevoir des avertissements Smartscreen lors de l'exécution de l'un de ces programmes d'installation, car ils ne sont pas signés numériquement. Ces forfaits sont fournis par Rebecca Cran et sont disponibles sans garantie.
Notez que Windows a une sélection limitée d'ioengines disponibles, ce qui informera votre sélection d'arguments de ligne de commande plus tard. Pour la plupart, les utilisateurs de Windows doivent utiliser
--ioengine=windowsaio
(Entrée/Sortie asynchrone) avec leurs arguments fio.
Linux / FreeBSD
Les instructions pour les utilisateurs des distributions Linux et BSD sont un peu différentes les unes des autres, mais fio se trouve dans presque tous les référentiels principaux, donc cela se résume à
installer fio
pour la grande majorité.
Debian ou Ubuntu :
sudo apt installer fio
FreeBSD :
sudo pkg installer fio
CentOS (et Red Hat Enterprise Linux) ont des référentiels principaux plus limités que la plupart des distributions ; si vous ne l'avez pas déjà fait, vous devrez ajouter le référentiel EPEL à CentOS/RHEL pour obtenir fio.
CentOS/RHEL :
sudo yum install epel-release -y ; sudo miam installer fio
Vous avez eu l'idée.
Mac OS
Sur un Mac, vous voudrez installer fio via brew. Si brew n'est pas déjà installé, sur le terminal, exécutez la commande suivante :
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
D'une part, ce qui précède est une procédure abominable ; d'un autre côté, vous pouvez confirmer que le script en cours d'extraction vous dit tout ce qu'il va faire, avant qu'il ne le fasse, et s'arrête pour vous permettre d'y consentir. Si vous êtes suffisamment paranoïaque, vous pouvez télécharger le fichier, l'inspecter, puis l'exécuter en tant qu'étapes distinctes à la place. Notez que le script d'installation homebrew n'a pas besoin de privilèges sudo et refusera en fait de s'exécuter si vous essayez de l'exécuter avec sudo.
Avec Brew installé, vous pouvez maintenant installer fio facilement :
infuser installer fio
Utiliser fio
Vous pouvez maintenant utiliser fio pour comparer le stockage. Tout d'abord, changez de répertoire à l'emplacement que vous voulez réellement tester : si vous exécutez fio dans votre répertoire personnel, vous testerez le disque interne de votre ordinateur, et si vous l'exécutez dans un répertoire situé sur un disque portable USB, vous comparer ce disque portable. Une fois que vous avez une invite de commande quelque part sur le disque que vous souhaitez tester, vous êtes prêt à exécuter fio.
La première course fio de bébé
Tout d'abord, nous examinerons la syntaxe nécessaire pour un simple test d'écriture aléatoire 4K. (Utilisateurs Windows : remplacez
--ioengine=windowsaio
pour
--ioengine=posixaio
dans cette commande et dans les commandes futures.)
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --numjobs=1 --size=4g --iodepth=1 --runtime=60 --time_based --end_fsync= 1
Décomposons ce que fait chaque argument.
--nom=
est un argument obligatoire, mais c'est essentiellement du fluff convivial pour l'homme - fio créera des fichiers basés sur ce nom pour tester avec, dans le répertoire de travail dans lequel vous vous trouvez actuellement.
--ioengine=posixaio
définit le mode d'interaction de fio avec le système de fichiers. POSIX est une norme Windows, Macs, Linux et BSD que tous comprennent, donc c'est génial pour la portabilité - bien qu'à l'intérieur de fio lui-même, les utilisateurs de Windows doivent invoquer
--ioengine=windowsaio
, ne pas
--ioengine=posixaio
, Malheureusement. AIO signifie Asynchronous Input Output et signifie que nous pouvons mettre en file d'attente plusieurs opérations à terminer dans l'ordre que le système d'exploitation décide de les terminer. (Dans cet exemple particulier, les arguments ultérieurs annulent effectivement cela.)
--rw=randwrite
signifie exactement ce que cela signifie : nous allons effectuer des opérations d'écriture aléatoires dans nos fichiers de test dans le répertoire de travail actuel. Les autres options incluent seqread, seqwrite, randread et randrw, qui devraient toutes, espérons-le, être assez explicites.
--bs=4k
taille de bloc 4K. Ce sont de très petites opérations individuelles. C'est là que vit la douleur ; c'est dur sur le disque, et cela signifie également une tonne de surcharge supplémentaire dans le SATA, USB, SAS, SMB ou tout autre canal de commande se trouvant entre nous et les disques, car une opération distincte doit être commandée pour chaque 4K de données .
--taille=4g
nos fichiers de test auront une taille de 4 Go chacun. (Nous n'en créons qu'un, voir l'argument suivant.)
--numjobs=1
nous ne créons qu'un seul fichier et exécutons un seul processus commandant des opérations dans ce fichier. Si nous voulions simuler plusieurs processus parallèles, nous ferions, par exemple,
--numjobs=16
, ce qui créerait 16 fichiers de test distincts de
--Taille
taille, et 16 processus distincts fonctionnant sur eux en même temps.
Publicité
--iodepth=1
c'est à quel point nous sommes prêts à essayer d'empiler les commandes dans la file d'attente du système d'exploitation. Puisque nous avons défini ce paramètre sur 1, c'est en fait à peu près la même chose que le moteur d'E/S de synchronisation - nous ne demandons qu'une seule opération à la fois, et le système d'exploitation doit accuser réception de chaque opération que nous demandons avant de pouvoir en demander un autre. (Il n'a pas à satisfaire la demande elle-même avant que nous lui demandions de faire plus d'opérations, il doit simplement reconnaître que nous l'avons réellement demandé.)
--runtime=60 --time_based
Exécutez pendant soixante secondes et même si nous terminons plus tôt, recommencez et continuez jusqu'à ce que 60 secondes se soient écoulées.
--end_fsync=1
Une fois que toutes les opérations ont été mises en file d'attente, maintenez le minuteur en marche jusqu'à ce que le système d'exploitation signale que la toute dernière d'entre elles s'est terminée avec succès, c'est-à-dire qu'elle a été écrite sur le disque.
Interprétation de la sortie de fio
Voici l'intégralité de la sortie des E/S aléatoires 4K exécutées sur mon poste de travail Ubuntu :
root@banshee:/tmp# fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --runtime=60 --time_based -- end_fsync=1random-write : (g=0) : rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=posixaiofio-3.12Démarrage de 1 processusJobs : 1 ( f=1) : [w(1)][100,0%][eta 00m:00s] écriture aléatoire : (groupid=0, jobs=1) : err= 0 : pid=16109 : Mer 5 février 15:09 : 36 2020 en écriture : IOPS=32,5k, BW=127 Mio/s (133 Mo/s)(8192 Mio/64602 ms) ; 0 zone réinitialise lamelle (nsec) : min=250, max=555439, moy=1388.31, stdev=833.19 clat (nsec) : min=90, max=20251k, moy=9642.34, stdev=179381.02 lat (usec) : min= 3, max=20252, moy=11.03, stdev=179.39 centiles clat (usec): | 1.00ème=[ 4], 5.00ème=[ 4], 10.00ème=[ 4], 20.00ème=[ 5], | 30,00e=[ 6], 40,00e=[ 6], 50,00e=[ 7], 60,00e=[ 8], | 70,00e=[ 9], 80,00e=[ 10], 90,00e=[ 11], 95,00e=[ 12], | 99,00e=[ 17], 99,50e=[ 20], 99,90e=[ 43], 99,95e=[ 77], | 99.99th=[12387] bw ( KiB/s) : min=22256, max=613312, per=100.00%, moy=335527.28, stdev=162778.06, samples=50 ios : min= 5564, max=153328, moy=83881.88 , stdev=40694.66, échantillons=50 lat (nsec) : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01% lat (usec) : 2=0.01%, 4=13.96 %, 10=68,85%, 20=16.68%, 50=0.41% lat (usec) : 100=0.04%, 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01% lat (msec) : 2=0.01%, 10=0.01%, 20=0.01%, 50=0.01% cpu : usr=6.35%, sys=11.96%, ctx=2348924, majf=0, minf=48 profondeurs IO : 1=100.0%, 2=0,0%, 4=0,0%, 8=0,0%, 16=0,0%, 32=0,0%, >=64=0,0% soumettre : 0=0,0%, 4=100,0%, 8=0,0%, 16= 0,0%, 32=0,0%, 64=0,0%, >=64=0,0% terminé : 0=0,0%, 4=100,0%, 8=0,0%, 16=0,0%, 32=0,0%, 64=0,0% , >=64=0.0% rwts émis : total=0,2097153,0,1 short=0,0,0,0 abandonné=0,0,0,0 latence : target=0, window=0, percentile=100.00 %, profondeur=1 Groupe d'état d'exécution 0 (tous les travaux) : run=64602-64602msecStatistiques du disque (lecture/écriture) : md0 : ios=7 1/749877, merge=0/0, ticks=0/0, in_queue=0, util=0.00%, aggrios=351/737911, aggrmerge=0/12145, aggrticks=1875/260901, aggrin_queue=30910, aggrutil=83.73 % sdb : ios=342/737392, merge=0/12663, ticks=1832/241034, in_queue=28672, util=83,35% sda : ios=361/738430, merge=0/11628, ticks=1918/280768, in_queue =33148, util=83,73 %
Cela peut sembler beaucoup. Ce
est
beaucoup! Mais dans la plupart des cas, il n'y a qu'un élément dont vous vous souciez probablement : la ligne située directement sous « Groupe d'état d'exécution 0 (tous les travaux) : » est celle avec le débit global. Fio est capable d'exécuter autant de tâches très différentes en parallèle que vous le souhaitez pour exécuter des modèles de charge de travail complexes. Mais comme nous n'exécutons qu'un seul groupe de tâches, nous n'avons qu'une seule ligne d'agrégats à parcourir.
Groupe d'état d'exécution 0 (tous les travaux) :
ÉCRITURE : bw=127 Mio/s (133 Mo/s)
, 127 Mio/s-127 Mio/s (133 Mo/s-133 Mo/s), io=8192 Mio (8590 Mo), exécution=64602-64602 msec
Premièrement, nous observons une sortie en MiB/sec et en Mo/sec. MiB signifie « mebioctets » – mesurés en puissances de deux – où MB signifie « mégaoctets », mesurés en puissances de dix. Les mébioctets (1024 x 1024 octets) sont les éléments dans lesquels les systèmes d'exploitation et les systèmes de fichiers mesurent réellement les données, c'est donc la lecture qui vous intéresse.
Groupe d'état d'exécution 0 (tous les travaux) : WRITE : bw=127 Mio/s (133 Mo/s),
127 Mio/s-127 Mio/s (133 Mo/s-133 Mo/s)
, io=8192MiB (8590MB), run=64602-64602msec
En plus de n'avoir qu'un seul groupe de tâches, nous n'avons qu'une seule tâche dans ce test - nous n'avons pas demandé à fio, par exemple, d'exécuter seize processus d'écriture aléatoire 4K en parallèle - donc, bien que le deuxième bit indique la plage minimale et maximale, dans ce cas, il s'agit simplement d'une répétition de l'agrégat global. Si nous avions eu plusieurs processus, nous verrions le processus le plus lent au processus le plus rapide représenté ici.
Groupe d'état d'exécution 0 (tous les travaux) : WRITE : bw=127 Mio/s (133 Mo/s), 127 Mio/s-127 Mio/s (133 Mo/s-133 Mo/s),
io=8192MiB (8590MB), run=64602-64602msec
Enfin, nous obtenons le total des E/S : 8192 Mio écrits sur le disque, en 6 4602 millisecondes. Divisez 8192 Mio par 64 602 secondes, et surprise, vous obtenez 126,8 Mio/s, arrondissez-le à 127 Mio/s, et c'est exactement ce que fio vous a dit dans le premier bloc de la ligne pour le débit global.
Si vous vous demandez pourquoi fio a écrit 8192 Mo au lieu de seulement 4096 Mo dans cette exécution, malgré notre
--Taille
l'argument étant 4g, et n'ayant qu'un seul processus en cours d'exécution, c'est parce que nous avons utilisé
--time_based
et
--runtime=60
. Et puisque nous testons sur un support de stockage rapide, nous avons réussi à boucler deux fois l'exécution d'écriture complète avant de terminer.
Vous pouvez sélectionner de nombreuses statistiques plus intéressantes à partir de la sortie fio complète, y compris les pourcentages d'utilisation, les IOPS par processus et l'utilisation du processeur, mais pour nos besoins, nous allons simplement nous en tenir au débit global à partir de maintenant.
Tests recommandés par Ars
Processus d'écriture aléatoire unique de 4 Kio
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=4k --size=4g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync= 1
Il s'agit d'un processus unique effectuant des écritures 4K aléatoires. C'est là que la douleur vit vraiment, vraiment ; c'est fondamentalement la pire chose que vous puissiez demander à un disque de faire. Où cela se produit le plus souvent dans la vie réelle : copier des répertoires personnels et des fichiers dotfiles, manipuler des éléments de courrier électronique, certaines opérations de base de données, des arborescences de code source.
Lorsque j'ai effectué ce test sur les SSD hautes performances de ma station de travail Ubuntu, ils ont poussé à 127 Mo/s. Le serveur juste en dessous dans le rack ne gérait que 33 Mio/s sur ses disques de rouille « haute performance » à 7 200 tr/min... mais même dans ce cas, la grande majorité de cette vitesse est due au fait que les données sont écrites de manière asynchrone, permettant au système d'exploitation de regroupez-le en opérations d'écriture plus importantes et plus efficaces.
Si on ajoute l'argument
--fsync=1
, forçant le système d'exploitation à effectuer des écritures synchrones (appel
fsync
après l'écriture de chaque bloc de données), l'image devient beaucoup plus sombre : 2,6 Mio/sec sur les SSD hautes performances mais seulement 184 Kio/sec sur la rouille "haute performance". Les SSD étaient environ quatre fois plus rapides que la rouille lorsque les données étaient écrites de manière asynchrone, mais un énorme
Quatorze
fois plus rapide lorsqu'il est réduit au pire des cas.
16 processus d'écriture aléatoire parallèles de 64 Ko
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=64k --size=256m --numjobs=16 --iodepth=16 --runtime=60 --time_based --end_fsync= 1
Cette fois, nous créons 16 fichiers distincts de 256 Mo (totalisant toujours 4 Go, une fois tous réunis) et nous publions des opérations d'écriture aléatoire de 64 Ko. Nous le faisons avec seize processus distincts exécutés en parallèle, et nous mettons en file d'attente jusqu'à 16 opérations asynchrones simultanées avant de faire une pause et d'attendre que le système d'exploitation commence à accuser réception.
Il s'agit d'une approximation assez décente d'un système très occupé. Il ne fait rien de particulièrement désagréable, comme exécuter un moteur de base de données ou copier des tonnes de fichiers de points à partir du répertoire personnel d'un utilisateur, mais il gère un tas d'applications faisant des choses modérément exigeantes en même temps.
C'est également une assez bonne approximation, légèrement pessimiste, d'un système multi-utilisateurs occupé comme un NAS, qui doit gérer plusieurs opérations de 1 Mo simultanément pour différents utilisateurs. Si plusieurs personnes ou processus essaient de lire ou d'écrire de gros fichiers (photos, films, etc.) à la fois, le système d'exploitation essaie de leur fournir toutes les données simultanément. Cela se résume assez rapidement à un modèle d'accès aléatoire multiple à de petits blocs. Donc, en plus de "bureau occupé avec beaucoup d'applications", pensez "serveur de fichiers occupé avec plusieurs personnes qui l'utilisent activement".
Vous verrez beaucoup plus de variation de vitesse lorsque vous regarderez cette opération se dérouler sur la console. Par exemple, le test de processus unique 4K que nous avons essayé en premier a écrit un débit assez constant de 11 Mio/s sur le disque interne de mon MacBook Air, mais ce travail de 16 processus a fluctué entre environ 10 Mio/s et 300 Mio/s au cours de l'exécution, se terminant avec une moyenne de 126 Mio/s.
La plupart des variations que vous voyez ici sont dues au fait que le système d'exploitation et le micrologiciel SSD sont parfois capables d'agréger plusieurs écritures. Lorsqu'il parvient à les agréger de manière utile, il peut les écrire d'une manière qui permet des écritures parallèles sur toutes les bandes de supports physiques individuelles à l'intérieur du SSD. Parfois, il finit toujours par abandonner et écrire sur une seule bande de support physique à la fois, ou une récupération de place ou une autre opération de maintenance au niveau du micrologiciel SSD doit s'exécuter brièvement en arrière-plan, ce qui ralentit les choses.
Processus d'écriture aléatoire unique de 1 Mio
fio --name=random-write --ioengine=posixaio --rw=randwrite --bs=1m --size=16g --numjobs=1 --iodepth=1 --runtime=60 --time_based --end_fsync= 1
C'est assez proche du meilleur scénario pour un système du monde réel faisant des choses du monde réel. Non, ce n'est pas aussi rapide qu'une seule écriture vraiment contiguë... mais la taille de bloc de 1 Mio est suffisamment grande pour être assez proche. En outre, si littéralement une autre activité de disque est demandée simultanément avec une écriture contiguë, l'écriture "contiguë" est transférée à ce niveau de performances presque instantanément, il s'agit donc d'un test beaucoup plus réaliste de l'extrémité supérieure des performances de stockage sur un système typique. .
Vous verrez des fluctuations étranges sur les SSD lors de ce test. Cela est en grande partie dû au fait que le micrologiciel du SSD a plus ou moins de chance à un moment donné, lorsqu'il essaie de mettre en file d'attente les opérations afin qu'il puisse écrire proprement sur toutes les bandes de supports physiques à la fois. Les disques antirouille auront tendance à fournir un débit beaucoup plus cohérent, bien que généralement inférieur, tout au long de l'exécution.
Vous pouvez également voir les performances SSD chuter ici si vous épuisez un cache d'écriture intégré. Les lecteurs TLC et QLC ont tendance à avoir de petites zones de cache d'écriture constituées de supports MLC ou SLC beaucoup plus rapides. Une fois ceux-ci épuisés, le disque doit passer à l'écriture directe sur le support TLC/QLC beaucoup plus lent où les données finissent par atterrir. C'est la principale différence entre, par exemple, les SSD Samsung EVO et Pro : les EVO ont un support TLC lent avec un cache MLC rapide, où les Pros utilisent le support MLC plus performant et plus durable sur l'ensemble du SSD.
Si vous avez le moindre doute sur la capacité d'un disque TLC ou QLC à supporter des écritures lourdes, vous voudrez peut-être étendre expérimentalement votre durée ici. Si vous observez le débit en direct au fur et à mesure que le travail progresse, vous verrez l'impact immédiatement lorsque vous manquez de cache. deviennent également beaucoup moins stables.
Cependant, vous pouvez choisir de prendre la position opposée : vous ne vous attendez peut-être pas à effectuer des écritures lourdes et soutenues très fréquemment, auquel cas vous êtes en fait plus intéressé par le comportement en cache. Ce qui est important ici, c'est que vous compreniez à la fois ce que vous voulez tester et comment le tester avec précision.
Conclusion
Utiliser fio est définitivement un exercice pour le vrai nerd (ou professionnel). Il ne vous tiendra pas la main, et bien qu'il fournisse des résultats incroyablement détaillés, ils ne sont pas automatiquement transformés en jolis graphiques pour vous.
Si tout cela vous semble beaucoup trop de travail, vous pouvez également trouver des outils graphiques plus simples à utiliser, tels que
HD Tune Pro
Pour les fenêtres. HD Tune Pro coûte 35 $, ou il existe une version non-Pro à capacité limitée qui est gratuite pour un usage personnel. C'est un bon outil, et il fera des graphiques brillants, mais il est considérablement plus limité pour les utilisateurs avancés, et le prix de l'interface utilisateur simplifiée est que vous êtes beaucoup plus éloigné de la réalité technique de ce que vous' re fais.
Apprendre à utiliser fio signifie vraiment
apprentissage
la différence entre les écritures asynchrones et synchrones et savoir avec une certitude absolue ce qu'il va faire à un niveau très bas sur la base d'un argument individuel. Vous ne pouvez pas être aussi certain de ce que des outils comme HD Tune Pro font réellement sous le capot - et avoir à gérer différents outils sur différents systèmes d'exploitation signifie qu'il est également plus difficile de comparer et de contraster directement les résultats.
