Guide d'évaluation des performances de JuiceFS

JuiceFS est un système de fichiers POSIX hautes performances conçu pour les environnements natifs du cloud.Toutes les données stockées dans JuiceFS seront divisées en blocs de données et stockées dans le stockage d'objets (comme Amazon S3) selon certaines règles, et les métadonnées correspondantes seront conservées. dans une base de données séparée. Cette structure détermine que l'espace de stockage de JuiceFS peut être mis à l'échelle de manière élastique en fonction de la quantité de données et peut stocker des données à grande échelle de manière fiable. En même temps, il prend en charge les montages partagés entre plusieurs hôtes pour réaliser le partage et la migration des données entre les nuages ​​et Régions.

Pendant le fonctionnement de JuiceFS, les performances réelles peuvent être différentes en raison de différences de matériel et de logiciel, de configuration du système, de taille de fichier et d'autres raisons. J'ai partagé auparavant [Comment utiliser les outils de performance de JuiceFS pour l'analyse et le réglage] Dans cet article, nous présenterons plus en détail comment effectuer une évaluation précise des performances de JuiceFS, dans l'espoir d'aider tout le monde.

avant-propos

Avant d'effectuer des tests de performances, il est conseillé de rédiger une description approximative du scénario d'utilisation, notamment :

1. Qu'est-ce que l'application d'accueil ? Comme Apache Spark, PyTorch ou des programmes écrits par vous-même, etc.
2. Configuration des ressources pour l'exécution de l'application, y compris la taille du processeur, de la mémoire, du réseau et du nœud
3. Taille estimée des données, y compris le nombre et la taille des fichiers
4. Taille du fichier et mode d'accès (grand ou petit, séquentiel ou aléatoire)
5. Les exigences de performance, telles que la quantité de données à écrire ou à lire par seconde, le QPS accédé ou la latence de l'opération, etc.

Plus le contenu ci-dessus est clair et détaillé, plus il est facile de formuler un plan de test approprié et des indicateurs de performance qui nécessitent une attention particulière pour déterminer les exigences de l'application pour divers aspects du système de stockage, y compris la configuration des métadonnées JuiceFS, les exigences de bande passante réseau et la configuration. paramètres. Bien sûr, il n'est pas facile d'écrire clairement tout le contenu ci-dessus au début, et certains contenus peuvent être progressivement clarifiés au cours du processus de test, mais à la fin d'un test complet, la description du scénario d'utilisation ci-dessus et les méthodes de test correspondantes, données de test, les résultats du test doivent être complets .

Si le contenu ci-dessus n'est pas clair, cela n'a pas d'importance, l'outil de test intégré de JuiceFS peut obtenir les indicateurs de base des performances de référence d'une seule machine avec une seule ligne de commandes. Dans le même temps, cet article présentera également deux outils d'analyse de performances intégrés de JuiceFS.Lorsque vous effectuez des tests plus complexes, ces deux outils peuvent vous aider à analyser facilement et clairement les raisons des performances de JuiceFS.

Démarrage rapide avec les tests de performance

L'exemple suivant décrit l'utilisation de base de l'outil de banc intégré à JuiceFS.

Configuration de l'environnement

• Hôte de test : un Amazon EC2 c5.xlarge
• Système d'exploitation : Ubuntu 20.04.1 LTS (noyau 5.4.0-1029-aws)
• Moteur de métadonnées : Redis 6.2.3, le stockage (dir) est configuré sur le disque système
• Stockage d'objets : Amazon S3
• Version JuiceFS：0.17-dev (2021-09-23 2ec2badf)

Banc JuiceFS

Les commandes JuiceFS benchpeuvent vous aider à effectuer rapidement le test de performances sur une seule machine et à déterminer si la configuration et les performances de l'environnement sont normales grâce aux résultats du test. En supposant que vous avez monté JuiceFS à l' /mnt/jfsemplacement (si vous avez besoin d'aide pour initialiser et monter JuiceFS, veuillez vous référer au Guide de démarrage rapide et exécuter les commandes suivantes (les -pparamètres recommandés sont définis sur le nombre de cœurs de processeur de la machine de test machine):

$ juicefs bench /mnt/jfs -p 4

Les résultats du test afficheront divers indicateurs de performance en vert, jaune ou rouge. S'il y a un indicateur rouge dans vos résultats, veuillez d'abord vérifier la configuration appropriée. Si vous avez besoin d'aide, vous pouvez décrire votre problème en détail dans les discussions GitHub.

Le processus spécifique du test de performance du benchmark JuiceFS benchest le suivant (sa logique de mise en œuvre est très simple, si vous êtes intéressé par les détails, vous pouvez directement regarder le code source :

1. N écrivez simultanément 1 gros fichier de 1 Gio chacun, la taille des E/S est de 1 Mio
2. N lit simultanément 1 gros fichier de 1 Gio précédemment écrit, la taille des E/S est de 1 Mio
3. N écrit simultanément 100 petits fichiers de 128 Kio et la taille des E/S est de 128 Kio
4. N lit simultanément 100 petits fichiers de 128 Kio précédemment écrits, la taille des E/S est de 128 Ko
5. N stat simultané 100 petits fichiers de 128 KiB précédemment écrits
6. Nettoyer le répertoire temporaire pour les tests

La valeur du nombre de concurrents N est spécifiée benchpar le -pparamètre dans la commande.

Voici une comparaison des performances avec plusieurs types de stockage courants fournis par AWS :

• Capacité EFS 1 TiB, lire 150 Mo/s, écrire 50 Mo/s, le prix est de 0,08 $/Go-mois
• EBS st1 est un disque dur à débit optimisé, avec un débit maximal de 500 Mio/s, un IOPS maximal (E/S de 1 Mio) de 500 et une capacité maximale de 16 Tio. Le prix est de 0,045 $/Go-mois.
• EBS gp2 est un SSD à usage général avec un débit maximal de 250 Mo/s, un IOPS maximal (E/S de 16 Ko) de 16 000 et une capacité maximale de 16 To. Le prix est de 0,10 $/Go-mois

Il n'est pas difficile de voir que dans le test ci-dessus, la capacité de lecture et d'écriture séquentielle de JuiceFS est nettement meilleure que celle d'AWS EFS, et la capacité de débit dépasse également l'EBS couramment utilisé. Cependant, la vitesse d'écriture de petits fichiers n'est pas rapide, car chaque fichier doit être persistant sur S3, et il y a généralement une surcharge fixe de 10 à 30 ms pour appeler l'API de stockage d'objets.

Remarque 1 : Les performances et la capacité d'Amazon EFS sont linéairement liées à la référence ( document officiel AWS ), il n'est donc pas adapté à une utilisation dans des scénarios avec un petit volume de données et un débit élevé.

Remarque 2 : Les prix se réfèrent à la région AWS USA Est, Ohio et les prix des différentes régions sont légèrement différents.

Remarque 3 : Les données ci-dessus proviennent de documents officiels AWS et l'indice de performance est la valeur maximale. Les performances réelles d'EBS sont liées à la capacité de volume et au type d'instance EC2 sur laquelle il est monté. De manière générale, plus le capacité, plus la configuration EC2 est élevée, plus l'EBS obtenu est meilleure, mais ne dépasse pas le maximum mentionné ci-dessus.

Outils d'observation et d'analyse de la performance

Ensuite, deux outils d'observation et d'analyse des performances sont introduits, qui sont des outils nécessaires dans le processus de test, d'utilisation et de réglage de JuiceFS.

Statistiques de JuiceFS

JuiceFS statsest un outil de statistiques en temps réel des indicateurs de performance de JuiceFS. Semblable aux dstatcommandes , il peut afficher les changements d'indicateurs des clients JuiceFS en temps réel (voir le document de suivi des performances pour les détails et l'utilisation ). juicefs benchLors de l'exécution de , exécutez les commandes suivantes dans une autre session :

$ juicefs stats /mnt/jfs --verbosity 1

Les résultats sont les suivants, qui peuvent être plus facilement compris en le comparant au processus de benchmarking décrit ci-dessus :

Les significations spécifiques des indicateurs sont les suivantes :

• usage
  • cpu : Le CPU consommé par le processus JuiceFS
  • mem : mémoire physique occupée par le processus JuiceFS
  • buf : la taille du tampon de lecture-écriture à l'intérieur du processus JuiceFS, --buffer-sizelimitée
  • cache : indicateurs internes, ne faites pas attention
• fusible
  • ops/lat : Le nombre de requêtes traitées par l'interface FUSE par seconde et son délai moyen (unité : millisecondes, idem ci-dessous)
  • lecture/écriture : la valeur de la bande passante de l'interface FUSE traitant les requêtes de lecture et d'écriture par seconde
• méta
  • ops/lat : Le nombre de requêtes traitées par le moteur de métadonnées par seconde et son délai moyen (veuillez noter que certaines requêtes pouvant être traitées directement dans le cache ne sont pas incluses dans les statistiques afin de mieux refléter l'interaction entre le client et les métadonnées moteur. Temps)
  • txn/lat : le nombre de transactions d'écriture traitées par le moteur de métadonnées par seconde et sa latence moyenne (requêtes en lecture seule telles que ops getattruniquement mais pas txn)
  • retry : le nombre de fois que le moteur de métadonnées réessaie la transaction d'écriture par seconde
• bloc cache
  • lecture/écriture : trafic de lecture et d'écriture par seconde du cache de données local du client
• objet
  • get/get_c/lat : la valeur de la bande passante du stockage d'objets traitant les requêtes de lecture par seconde , le nombre de requêtes et leur latence moyenne
  • put/put_c/lat : la valeur de la bande passante des requêtes d'écriture de traitement de stockage d'objets par seconde , le nombre de requêtes et leur latence moyenne
  • del_c/lat : le nombre de demandes de suppression traitées par le magasin d'objets par seconde et le délai moyen

Profil JuiceFS

D'une part, JuiceFS profileest utilisé pour générer tous les journaux d'accès des clients JuiceFS en temps réel, y compris des informations sur chaque requête. Dans le même temps, il peut également être utilisé pour lire et compter les journaux d'accès JuiceFS, afin que les utilisateurs puissent comprendre intuitivement le fonctionnement de JuiceFS (pour des instructions détaillées et l'utilisation, voir le document de diagnostic des performances ). juicefs benchLors de l'exécution de , exécutez les commandes suivantes dans une autre session :

$ cat /mnt/jfs/.accesslog > access.log

Parmi eux .accesslogse trouve un fichier virtuel, qui ne génère généralement aucune donnée, uniquement lors de la lecture (telle que l'exécution cat) il y aura la sortie du journal d'accès de JuiceFS. Utilisez <kbd>Ctrl-C</kbd> pour terminer la catcommande lorsque vous avez terminé, et exécutez :

$ juicefs profile access.log --interval 0

Le --intervalparamètre définit l'intervalle d'échantillonnage du journal d'accès. Lorsqu'il est défini sur 0, il est utilisé pour relire rapidement un fichier journal spécifié et générer des informations statistiques, comme illustré dans la figure suivante :

Comme le montre la description du processus de test de référence précédent, un total de (1 + 100) * 4 = 404 fichiers ont été créés dans ce processus de test, et chaque fichier est passé par "créer → écrire → fermer → ouvrir → lire → fermer → supprimer", il y a donc un total de :

• 404 demandes de création, d'ouverture et de dissociation
• 808 requêtes de vidage : un vidage est automatiquement appelé à chaque fois que le fichier est fermé
• 33168 requêtes d'écriture/lecture : chaque fichier volumineux écrit 1024 1 Mio d'E/S, et la requête maximale par défaut au niveau de la couche FUSE est de 128 Kio, ce qui signifie que chaque E/S d'application sera divisée en 8 requêtes FUSE, soit un total de (1024 * 8 + 100) * 4 = 33168 requêtes. Lire IO est similaire et le nombre est le même.

Toutes les valeurs ci-dessus correspondent exactement profileaux résultats de . De plus, les résultats montrent également que le délai moyen d'écriture est très faible (45 microsecondes), et que le principal point chronophage est flush. En effet, l'écriture de JuiceFS écrit d'abord dans la mémoire tampon par défaut, puis appelle flush pour télécharger les données dans le stockage d'objets lorsque le fichier est fermé, ce qui est conforme aux attentes.

Autres exemples de configuration d'outil de test

Test de performance autonome Fio

Fio est un outil de test de performance couramment utilisé dans l'industrie. Après avoir terminé le banc JuiceFS, vous pouvez l'utiliser pour effectuer des tests de performance plus complexes.

Configuration de l'environnement

Compatible avec l'environnement de test JuiceFS Bench.

tâche d'essai

Effectuez les quatre tâches Fio suivantes pour effectuer des tests d'écriture séquentielle, de lecture séquentielle, d'écriture aléatoire et de lecture aléatoire :

# Sequential
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=write --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=read --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting

# Random
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=randwrite --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting
$ fio --name=jfs-test --directory=/mnt/jfs --ioengine=libaio --rw=randread --bs=1m --size=1g --numjobs=4 --direct=1 --group_reporting

Description du paramètre :

• --name: nom de test spécifié par l'utilisateur, qui affectera le nom du fichier de test
• --directory: répertoire de test
• --ioengine: La façon d'émettre des IO pendant les tests ; généralement libaio peut être utilisé
• --rw: Couramment utilisés sont read, write, randread, randwrite, qui représentent respectivement la lecture et l'écriture séquentielles et la lecture et l'écriture aléatoires
• --bs: La taille de chaque IO
• --size: taille totale des E/S par thread ; généralement égale à la taille du fichier de test
• --numjobs: nombre de threads de test simultanés ; par défaut, chaque thread exécute un fichier de test distinct
• --direct: Ajoutez le bit d' O_DIRECTindicateur sans utiliser la mise en mémoire tampon du système, ce qui peut rendre le résultat du test plus stable et précis

Le résultat est le suivant :

# Sequential
WRITE: bw=703MiB/s (737MB/s), 703MiB/s-703MiB/s (737MB/s-737MB/s), io=4096MiB (4295MB), run=5825-5825msec
READ: bw=817MiB/s (856MB/s), 817MiB/s-817MiB/s (856MB/s-856MB/s), io=4096MiB (4295MB), run=5015-5015msec

# Random
WRITE: bw=285MiB/s (298MB/s), 285MiB/s-285MiB/s (298MB/s-298MB/s), io=4096MiB (4295MB), run=14395-14395msec
READ: bw=93.6MiB/s (98.1MB/s), 93.6MiB/s-93.6MiB/s (98.1MB/s-98.1MB/s), io=4096MiB (4295MB), run=43773-43773msec

Test de performance multi-machine Vdbench

Vdbench est également un outil d'évaluation de système de fichiers courant dans l'industrie et prend bien en charge les tests simultanés sur plusieurs machines.

environnement d'essai

Semblable à l'environnement de test JuiceFS Bench, seuls deux autres hôtes avec la même configuration sont ouverts, pour un total de trois.

Prêt à travailler

Vous devez installer vdbench dans le même chemin sur chaque nœud :

1. Téléchargez la version 50406 sur le site officiel
2. Installez Java :apt-get install openjdk-8-jre
3. Testez l'installation réussie de vdbench :./vdbench -t

Ensuite, en supposant que les noms des trois nœuds sont node0, node1 et node2, vous devez créer un fichier de configuration sur node0 comme suit (pour tester un grand nombre de petits fichiers à lire et à écrire) :

$ cat jfs-test
hd=default,vdbench=/root/vdbench50406,user=root
hd=h0,system=node0
hd=h1,system=node1
hd=h2,system=node2

fsd=fsd1,anchor=/mnt/jfs/vdbench,depth=1,width=100,files=3000,size=128k,shared=yes

fwd=default,fsd=fsd1,operation=read,xfersize=128k,fileio=random,fileselect=random,threads=4
fwd=fwd1,host=h0
fwd=fwd2,host=h1
fwd=fwd3,host=h2

rd=rd1,fwd=fwd*,fwdrate=max,format=yes,elapsed=300,interval=1

Description du paramètre :

• vdbench=/root/vdbench50406: spécifie le chemin d'installation de l'outil vdbench
• anchor=/mnt/jfs/vdbench: spécifie le chemin pour exécuter la tâche de test sur chaque nœud
• depth=1,width=100,files=3000,size=128k : définit l'arborescence des fichiers de la tâche de test, c'est-à-dire crée 100 répertoires supplémentaires sous le répertoire de test, chaque répertoire contient 3 000 fichiers d'une taille de 128 Kio, soit un total de 300 000 fichiers
• operation=read,xfersize=128k,fileio=random,fileselect=random: définit la tâche de test réelle, c'est-à-dire sélectionne au hasard un fichier et envoie une demande de lecture de 128 Kio

Le résultat est le suivant :

FILE_CREATES        Files created:                              300,000        498/sec
READ_OPENS          Files opened for read activity:             188,317        627/sec

Le système global crée 128 fichiers KiB à 498 par seconde et lit à 627 par seconde.

Résumer

Cet article partage de manière exhaustive le processus global d'évaluation des performances de JuiceFS du point de vue de la configuration de l'environnement, de l'introduction d'outils et des tests d'instance. Une évaluation précise des performances peut aider à optimiser JuiceFS pour mieux s'adapter à vos scénarios d'application. Enfin, tout le monde est invité à enregistrer activement et à partager son processus de test et ses résultats sur le forum ou le groupe d'utilisateurs JuiceFS.

Lecture recommandée : Zhihu x JuiceFS : Utilisation de JuiceFS pour accélérer le démarrage du conteneur Flink

Si cela vous est utile, veuillez suivre notre projet Juicedata/JuiceFS ! (0ᴗ0✿)

{{o.name}}

{{m.name}}