Object Storage Service:Local data cache

Informations générales

Lorsque vous utilisez ossfs 2,0 pour accéder à OSS, les données doivent être récupérées depuis le serveur distant à chaque lecture de fichier. Dans les scénarios nécessitant plusieurs cycles de lectures répétées des mêmes données, tels que l'entraînement d'IA et le chargement de modèles, les accès distants fréquents entraînent une latence réseau élevée et une consommation importante de bande passante.

Le cache de données local d'ossfs 2,0 conserve les données de fichiers précédemment lues sur un disque local, de sorte que les accès ultérieurs sont servis directement depuis ce disque. Cela améliore considérablement les performances des lectures répétées et réduit les coûts liés aux requêtes OSS.

Le cache de données local d'ossfs 2,0 présente les caractéristiques suivantes :

• Meilleures performances : Dans les scénarios de lectures répétées, qu'il s'agisse de fichiers volumineux ou de petits fichiers, la bande passante est nettement supérieure à celle d'ossfs 1,0. Pour plus d'informations, consultez la comparaison des performances ci-dessous.

• Éviction automatique : Une politique d'éviction LRU (Least Recently Used) intégrée libère automatiquement l'espace occupé par les fichiers les moins récemment consultés lorsque le cache est plein, sans nécessiter de nettoyage manuel.

• Prise en charge d'un grand nombre de petits fichiers : Lorsqu'il est utilisé conjointement avec le cache de métadonnées (--max_inode_cache_count et --attr_timeout), il peut accélérer considérablement le chargement en plusieurs cycles des jeux de données d'entraînement d'IA.

Principes de fonctionnement

Granularité du cache

Le cache utilise les objets OSS (fichiers) comme unité de base. Chaque fichier lu correspond à un fichier de cache dans le répertoire de cache, et le remplissage du cache s'effectue à la demande.

Processus de lecture

• Première lecture : Les données sont récupérées depuis OSS et écrites de manière synchrone dans le répertoire de cache local.

• Lectures ultérieures : Les données sont lues directement depuis le cache local.

Libération d'espace

Lorsque le cache approche sa limite de capacité, les anciens fichiers sont automatiquement évincés selon la politique LRU (Least Recently Used) afin de libérer de l'espace pour les nouvelles données. La libération s'effectue au niveau du fichier de cache individuel, qui constitue l'unité minimale.

Méthodes de configuration

Contraintes :

• Le répertoire pointé par --disk_data_cache_dir doit exister et être vide. Nous vous recommandons de vous assurer que le chemin du cache réside sur une partition indépendante ou un disque indépendant.

• --disk_data_cache_size ne peut pas dépasser l'espace disponible du disque où réside le répertoire de cache.

• Lorsque vous montez plusieurs instances ossfs2 sur la même machine, chaque instance doit utiliser un répertoire de cache indépendant.

• Lorsque le processus ossfs2 se termine, le répertoire de cache n'est pas nettoyé automatiquement et doit être supprimé manuellement.

• Après le montage, évitez d'effectuer des opérations sur le chemin du répertoire de cache pour prévenir des erreurs inconnues.

Exemple de commande de montage :

ossfs2 mount /mnt/oss/ \
  --oss_bucket <your-bucket> \
  --oss_endpoint <your-endpoint> \
  --oss_access_key_id <ak> \
  --oss_access_key_secret <sk> \
  --disk_data_cache_dir /mnt/disk/ossfs2/cache \
  --disk_data_cache_size 256G

Configuration requise

Recommandations d'utilisation

Le cache de données local convient aux scénarios à forte intensité de lecture et faible intensité d'écriture, nécessitant un accès répété aux mêmes données.

Recommandations pour la configuration du moteur d'E/S (disk_data_cache_io_engine) :

• psync : Utilise des appels système de lecture/écriture synchrones ; les données transitent par le PageCache du système d'exploitation lors des lectures. Lorsque la quantité de données mises en cache est proche ou inférieure à la mémoire disponible, les données fréquemment utilisées résident naturellement dans le PageCache, atteignant ainsi des vitesses de lecture proches de celles de la mémoire. Cette option convient aux scénarios généraux, aux disques cloud de faible spécification et aux disques de cache tmpfs (tmpfs ne supporte pas libaio).

• libaio : Utilise l'interface d'E/S asynchrone de Linux et contourne le PageCache pour opérer directement sur le disque. Cette option convient aux scénarios disposant de disques NVMe locaux de grande capacité et dont les jeux de données sont beaucoup plus volumineux que la mémoire. Elle offre généralement une amélioration supplémentaire des performances d'environ 20 % par rapport à psync.

Le tableau suivant répertorie les scénarios typiques et les configurations recommandées :

Comparaison des performances

Cibles du test : ossfs 2.0.9 contre ossfs 1.91.10. Dans le tableau, « première lecture / lectures ultérieures » correspondent respectivement à un échec du cache (les données doivent être récupérées depuis OSS) et à un succès du cache local. « — » indique que la configuration ne dispose pas de cache et ne distingue pas la première lecture des lectures ultérieures.

Scénario 1 : Lecture séquentielle de fichiers volumineux (4 threads lisant un fichier de 100 Go)

Environnement de test

• Machine : ecs.i4,4xlarge (16 vCPU, 128 GiB)

• Disque NVMe local : 3576 GiB NVMe (bande passante en lecture 6 Go/s, bande passante en écriture 3 Go/s, IOPS 900 000)

• ossfs 2,0 : --disk_data_cache_dir=<path> --disk_data_cache_size=3T, testé séparément avec --disk_data_cache_io_engine=psync et libaio

• ossfs 1,0 : -ouse_cache=<path> -oparallel_count=128

Résultats

Conclusion :

• Une fois le cache activé, dans le scénario de lectures ultérieures de fichiers volumineux, ossfs 2,0 offre des performances environ 2,5 fois supérieures à celles d'ossfs 1,0 (mode libaio : 6625 contre 2648 Mo/s), atteignant le plafond de performance du NVMe local. Parallèlement, l'utilisation du CPU est considérablement réduite (≈300 % contre 800 %).

Scénario 2 : Lecture d'un grand nombre de petits fichiers (chargement du jeu de données d'entraînement ImageNet)

Environnement de test

• Machine : ecs.i4,32xlarge (128 vCPU, 1024 GiB)

• Disques NVMe locaux : 8 × 3576 GiB NVMe

• Jeu de données : Jeu d'entraînement ImageNet (environ 1,3 million d'images), chargé de manière répétée sur plusieurs époques

• ossfs 2,0 : --disk_data_cache_dir=<path> --disk_data_cache_size=1500G --disk_data_cache_io_engine=libaio --attr_timeout=36000 --max_inode_cache_count=11000000 (cache de métadonnées activé)

• ossfs 1,0 : -ouse_cache=<path> -oreaddir_optimize -omax_stat_cache_size=11000000 -ostat_cache_expire=72000

Résultats

Conclusion :

• Une fois le cache disque et le cache de métadonnées activés, les performances de chargement d'ossfs 2,0 lors des époques ultérieures atteignent 4,25 fois celles observées sans cache disque (1292 contre 304 Mo/s), et les requêtes réseau vers OSS sont complètement éliminées. Pour les charges de travail d'entraînement d'IA qui chargent de manière répétée le même jeu de données sur plusieurs cycles, nous recommandons vivement le cache de données local d'ossfs 2,0 combiné à libaio.