Bonnes pratiques pour optimiser les performances

Cette page vous explique comment améliorer les performances de Cloud Storage FUSE à l'aide des principales fonctionnalités et configurations de Cloud Storage FUSE pour obtenir un débit maximal et des performances optimales, en particulier pour les charges de travail d'intelligence artificielle et de machine learning (IA/ML) telles que l'entraînement, le serving et le checkpointing.

Remarques

Avant d'appliquer les configurations que nous recommandons sur cette page, tenez compte des points suivants :

• Vous pouvez appliquer les configurations recommandées sur cette page de trois manières :

  • Fichier de configuration Cloud Storage FUSE

  • Options de l'interface de ligne de commande Cloud Storage FUSE

  • Pour Google Kubernetes Engine uniquement : exemples de fichiers YAML Google Kubernetes Engine

• Assurez-vous d'exécuter la dernière version de Cloud Storage FUSE. Les configurations recommandées ne doivent être appliquées qu'à Cloud Storage FUSE version 3.0 ou ultérieure, ainsi qu'au pilote CSI Cloud Storage FUSE pour Google Kubernetes Engine qui s'exécute sur les clusters GKE version 1.32.2-gke.1297001 ou ultérieure.

• Les configurations recommandées mettent en cache les métadonnées Cloud Storage pendant toute la durée du job et ne sont pas vérifiées après le montage initial du système de fichiers. Par conséquent, pour des performances optimales, nous recommandons que le système de fichiers soit en lecture seule ou que la sémantique du système de fichiers soit write-to-new (écriture dans un nouveau fichier), ce qui signifie que les applications écrivent toujours dans de nouveaux fichiers. Les charges de travail d'IA/ML suivantes sont de type "écrire dans un nouveau" :

  • Points de contrôle

  • Formation

  • Diffusion

  • Mise en cache de jax.jit()

• Les configurations recommandées sur cette page ont été validées pour les grands types de machines Cloud GPU et Cloud TPU à grande échelle, où la mémoire est importante et l'interface réseau à bande passante élevée. Les types de machines Cloud GPU et Cloud TPU peuvent différer en termes de nombre de ressources disponibles, telles que le processeur, la mémoire et le stockage local, dans la configuration de leur nœud hôte. Cela peut avoir un impact direct sur les performances pour les configurations telles que les suivantes :

  • A3 Ultra

  • A3 Mega : 1,8 Tio de mémoire, avec 6 Tio de LSSD

  • Cloud TPU v5e : 188 Gio de mémoire, sans LSSD

  • Cloud TPU v5p : 448 Gio de mémoire, sans LSSD

  • Cloud TPU v6 (Trillium) : 1,5 Tio de mémoire, sans LSSD

Utiliser des buckets avec l'espace de noms hiérarchique activé

Utilisez toujours des buckets avec l'espace de noms hiérarchique activé. L'espace de noms hiérarchique organise vos données dans une structure de système de fichiers hiérarchique, ce qui rend les opérations dans le bucket plus efficaces. Vous obtenez ainsi des temps de réponse plus rapides et réduisez le nombre d'appels de liste pour chaque opération.

Voici les avantages de l'espace de noms hiérarchique :

• Les buckets avec espace de noms hiérarchique offrent un nombre de requêtes par seconde (RPS) initial jusqu'à huit fois plus élevé que les buckets plats. L'espace de noms hiérarchique accepte 40 000 requêtes de lecture d'objets par seconde et 8 000 requêtes d'écriture d'objets par seconde au départ, ce qui est nettement supérieur aux buckets plats Cloud Storage FUSE standards, qui n'offrent que 5 000 requêtes de lecture d'objets par seconde et 1 000 requêtes d'écriture d'objets par seconde au départ.

• L'espace de noms hiérarchique permet de renommer les répertoires de manière atomique, ce qui est nécessaire pour la création de points de contrôle avec Cloud Storage FUSE afin de garantir l'atomicité. L'utilisation de buckets avec un espace de noms hiérarchique activé est particulièrement utile pour la création de points de contrôle à grande échelle, car les frameworks de ML utilisent le renommage de répertoires pour finaliser les points de contrôle. Il s'agit d'une commande rapide et atomique, qui n'est compatible qu'avec les buckets dont l'espace de noms hiérarchique est activé. Si vous choisissez de ne pas utiliser de bucket avec l'espace de noms hiérarchique activé, consultez Augmenter la limite de renommage pour les buckets non HNS.

Pour savoir comment créer un bucket avec l'espace de noms hiérarchique activé, consultez Créer des buckets avec l'espace de noms hiérarchique activé. Pour savoir comment installer un bucket avec l'espace de noms hiérarchique activé, consultez Installer des buckets avec l'espace de noms hiérarchique activé. Les espaces de noms hiérarchiques sont compatibles avec les versions 1.31.1-gke.2008000 ou ultérieures de Google Kubernetes Engine.

Effectuer un montage spécifique à un répertoire

Si vous souhaitez accéder à un répertoire spécifique dans un bucket, vous pouvez installer uniquement ce répertoire à l'aide de l'option de montage only-dir au lieu d'installer l'intégralité du bucket. L'exécution d'un montage spécifique à un répertoire accélère les appels de liste et réduit le nombre total d'appels de liste et de statistiques en limitant le nombre de répertoires à parcourir lors de la résolution d'un nom de fichier, car les appels LookUpInode et les demandes d'accès aux buckets ou aux répertoires génèrent automatiquement des appels de liste et de statistiques pour chaque fichier ou répertoire du chemin d'accès.

Pour installer un répertoire spécifique, utilisez la configuration d'installation suivante :

volumeHandle: BUCKET_NAME
 - only-dir:DIRECTORY_NAME

Où :

• BUCKET_NAME est le nom du bucket dans lequel vous souhaitez installer le répertoire.

• DIRECTORY_NAME correspond au nom du répertoire que vous souhaitez installer.

Pour savoir comment effectuer un montage de répertoire, consultez Monter un répertoire dans un bucket.

Augmenter les valeurs du cache de métadonnées

Pour améliorer les performances des lectures répétées, vous pouvez configurer Cloud Storage FUSE pour mettre en cache une grande quantité de métadonnées et ignorer l'expiration des métadonnées. Cela évite les demandes de métadonnées répétées à Cloud Storage et améliore considérablement les performances.

L'augmentation des valeurs du cache de métadonnées est bénéfique pour les charges de travail avec des lectures répétées afin d'éviter les appels Cloud Storage répétitifs, ainsi que pour les volumes en lecture seule pour lesquels un TTL infini peut être défini.

Avant d'augmenter les valeurs du cache de métadonnées, tenez compte des points suivants :

• Une valeur TTL (Time To Live) infinie ne doit être définie que pour les volumes en lecture seule ou en écriture uniquement.

• Le cache de métadonnées ne doit être activé que pour augmenter considérablement la taille des nœuds avec de grandes configurations de mémoire, car il met en cache toutes les métadonnées du point de montage spécifié dans chaque nœud et élimine le besoin d'accès supplémentaire à Cloud Storage.

• Les configurations de cette section mettent en cache toutes les métadonnées consultées avec une valeur TTL infinie, ce qui peut affecter les garanties de cohérence lorsque des modifications sont apportées au même bucket Cloud Storage par un autre client (par exemple, des remplacements ou des suppressions de fichiers).

• Pour vérifier que la consommation de mémoire n'est pas affectée, assurez-vous que la quantité de mémoire consommée par le cache de métadonnées est acceptable pour vous. Elle peut atteindre plusieurs gigaoctets et dépend du nombre de fichiers dans les buckets montés et du nombre de points de montage utilisés. Par exemple, les métadonnées de chaque fichier occupent environ 1,5 Kio de mémoire. Par conséquent, les métadonnées d'un million de fichiers occupent environ 1,5 Gio de mémoire. Pour en savoir plus, consultez Présentation de la mise en cache.

Suivez les instructions ci-dessous pour configurer Cloud Storage FUSE afin de mettre en cache une grande quantité de métadonnées et de contourner l'expiration des métadonnées :

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

metadata-cache:
stat-cache-max-size-mb: -1
ttl-secs: -1
type-cache-max-size-mb: -1

  mountOptions:
      - metadata-cache:ttl-secs:-1
      - metadata-cache:stat-cache-max-size-mb:-1
      - metadata-cache:type-cache-max-size-mb:-1

Préremplir le cache des métadonnées

Avant d'exécuter une charge de travail, nous vous recommandons de préremplir le cache de métadonnées, ce qui améliore considérablement les performances et réduit considérablement le nombre d'appels de métadonnées à Cloud Storage, en particulier si l'option de configuration implicit-dirs est utilisée. Le pilote CSI Cloud Storage FUSE pour GKE fournit une API qui gère le préremplissage du cache de métadonnées. Pour en savoir plus, consultez Utiliser la prélecture des métadonnées pour préremplir le cache de métadonnées.

Pour préremplir le cache de métadonnées, utilisez l'une des méthodes suivantes :

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: training-bucket-pv
  spec:
    ...
    csi:
      volumeHandle: BUCKET_NAME
      volumeAttributes:
        ...
        gcsfuseMetadataPrefetchOnMount: "true"
  

ls -R MOUNT_POINT > /dev/null

Activer la mise en cache des fichiers et les téléchargements parallèles

La mise en cache des fichiers vous permet de stocker localement sur votre machine les données de fichiers auxquelles vous accédez fréquemment. Cela accélère les lectures répétées et réduit les coûts Cloud Storage. Lorsque vous activez la mise en cache de fichiers, les téléchargements parallèles sont également activés automatiquement. Les téléchargements parallèles utilisent plusieurs nœuds de calcul pour télécharger un fichier en parallèle à l'aide du répertoire de cache de fichiers comme tampon de préchargement, ce qui permet de charger les modèles neuf fois plus rapidement.

Pour savoir comment activer et configurer la mise en cache de fichiers et les téléchargements parallèles, consultez Activer et configurer le comportement de mise en cache. Pour utiliser un exemple de configuration, consultez Exemple de configuration pour activer la mise en cache des fichiers et les téléchargements parallèles.

Considérations concernant les GPU Cloud et les Cloud TPU pour l'utilisation de la mise en cache de fichiers et des téléchargements parallèles

Le cache de fichiers peut être hébergé sur des disques SSD locaux, de la RAM, des disques persistants ou des Google Cloud Hyperdisk, en suivant les conseils ci-dessous. Dans tous les cas, les données ou le fichier volumineux individuel doivent correspondre à la capacité disponible du répertoire de cache de fichiers, qui est contrôlée à l'aide de la configuration max-size-mb.

Considérations concernant les GPU sur Google Cloud

Les disques SSD locaux sont idéaux pour les données d'entraînement et les téléchargements de points de contrôle. Les types de machines GPU Cloud incluent une capacité SSD utilisable, comme les types de machines A4 qui incluent 12 Tio de SSD.

• Un disque RAM offre les meilleures performances pour le chargement des pondérations de modèle en raison de leur petite taille par rapport à la quantité de RAM inutilisée sur le système.

• Vous pouvez utiliser Persistent Disk ou Google Cloud Hyperdisk comme cache.

Points à prendre en compte concernant Cloud TPU

Les Cloud TPU ne sont pas compatibles avec les disques SSD locaux. Si vous utilisez la mise en cache de fichiers sur Cloud TPU sans modification, l'emplacement par défaut utilisé est le volume de démarrage, ce qui n'est pas recommandé et entraîne de mauvaises performances.

Au lieu du volume de démarrage, nous vous recommandons d'utiliser un disque RAM, qui est préférable pour ses performances et son absence de coût supplémentaire. Toutefois, la taille d'un disque RAM est souvent limitée et ne convient pas à la diffusion des pondérations de modèle. Nous vous recommandons également d'utiliser Persistent Disk et Google Cloud Hyperdisk à des fins de mise en cache.

Exemple de configuration pour activer la mise en cache de fichiers et les téléchargements parallèles

Par défaut, le cache de fichiers utilise un disque SSD local si le mode ephemeral-storage-local-ssd est activé pour le nœud Google Kubernetes Engine. Si aucun SSD local n'est disponible (par exemple, sur les machines Cloud TPU), le cache de fichiers utilise le disque de démarrage du nœud Google Kubernetes Engine, ce qui n'est pas recommandé. Dans ce cas, vous pouvez utiliser un disque RAM comme répertoire de cache, mais tenez compte de la quantité de RAM disponible pour la mise en cache des fichiers par rapport à celle requise par le pod.

gcsfuse --file-cache-max-size-mb: -1 \
      --file-cache-cache-file-for-range-read: true \
      --file-cache-enable-parallel-downloads: true \
      BUCKET_NAME

file-cache:
  max-size-mb: -1
  cache-file-for-range-read: true
  enable-parallel-downloads: true

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

# RAM disk file cache if LSSD not available. Uncomment to use
# volumes:
#   - name: gke-gcsfuse-cache
#     emptyDir:
#       medium: Memory

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true 
    - file-cache:enable-parallel-downloads:true 

volumes:
    - name: gke-gcsfuse-cache
      emptyDir:
        medium: Memory

Désactiver les entrées de cache de statistiques négatives

Par défaut, Cloud Storage FUSE met en cache les entrées de statistiques négatives (c'est-à-dire les entrées pour les fichiers qui n'existent pas) avec une valeur TTL de cinq secondes. Dans les charges de travail où des fichiers sont fréquemment créés ou supprimés, comme la création de points de contrôle distribués, ces entrées mises en cache peuvent rapidement devenir obsolètes, ce qui entraîne des problèmes de performances. Pour éviter cela, nous vous recommandons de désactiver le cache de statistiques négatives pour les charges de travail d'entraînement, de diffusion et de checkpointing à l'aide de l'option de configuration negative-ttl-secs.

Suivez les instructions ci-dessous pour désactiver le cache de statistiques négatives :

gcsfuse --metadata-cache-negative-ttl-secs: 0 \
  BUCKET_NAME

metadata-cache:
 negative-ttl-secs: 0

mountOptions:
    - metadata-cache:negative-ttl-secs:0

Activer les écritures de flux

Les écritures en flux continu importent les données directement dans Cloud Storage au fur et à mesure de leur écriture, ce qui réduit la latence et l'utilisation de l'espace disque. Cela est particulièrement utile pour les grandes écritures séquentielles, comme les points de contrôle. Les écritures en flux continu sont activées par défaut sur Cloud Storage FUSE version 3.0 et ultérieure.

Si les écritures en flux continu ne sont pas activées par défaut, suivez les instructions ci-dessous pour les activer. Pour activer les écritures en flux continu, vous devez utiliser Cloud Storage FUSE version 3.0, disponible sur Google Kubernetes Engine version 1.32.1-gke.1729000 ou ultérieure.

gcsfuse --enable-streaming-writes: true \
  BUCKET_NAME

write:
 enable-streaming-writes: true

mountOptions:
    - write:enable-streaming-writes:true

Augmenter la taille de lecture anticipée du noyau

Pour les charges de travail qui impliquent principalement des lectures séquentielles de fichiers volumineux, comme la diffusion et la restauration de points de contrôle, l'augmentation de la taille de lecture anticipée peut améliorer considérablement les performances. Pour ce faire, utilisez le paramètre du noyau Linux read_ahead_kb sur votre ordinateur local. Nous vous recommandons d'augmenter le paramètre de noyau read_ahead_kb à 1 Mo au lieu d'utiliser la valeur par défaut de 128 Ko définie sur la plupart des distributions Linux. Pour les instances Compute Engine, les autorisations sudo ou root sont requises pour augmenter le paramètre du noyau.

Pour augmenter le paramètre de noyau read_ahead_kb à 1 Mo pour un répertoire Cloud Storage FUSE installé spécifique, utilisez la commande suivante, où /path/to/mount/point est votre point d'installation Cloud Storage FUSE. Votre bucket doit être installé sur Cloud Storage FUSE avant d'exécuter la commande. Sinon, le paramètre du noyau n'augmente pas.

  mountOptions:
    - read_ahead_kb=1024
  

Désactiver le service Security Token pour éviter les vérifications redondantes

Le pilote CSI Cloud Storage FUSE pour Google Kubernetes Engine effectue des vérifications d'accès pour assurer la récupération des pods en cas de configuration incorrecte par l'utilisateur des liaisons d'identité de charge de travail entre le bucket et le compte de service GKE, ce qui peut atteindre les quotas par défaut de l'API Security Token Service à grande échelle. Vous pouvez désactiver cette option en définissant l'attribut de volume skipCSIBucketAccessCheck du pilote CSI de volume persistant. Nous vous recommandons de vous assurer que le compte de service GKE dispose des droits d'accès appropriés au bucket Cloud Storage cible pour éviter les échecs de montage du pod.

De plus, le quota Security Token Service doit être augmenté au-delà de la valeur par défaut de 6000 si un cluster Google Kubernetes Engine comporte plus de 6 000 nœuds, ce qui peut entraîner des erreurs 429 s'il n'est pas augmenté dans les déploiements à grande échelle. Le quota du Security Token Service doit être augmenté sur la page Quotas et limites. Nous vous recommandons de conserver un quota égal au nombre de points de montage. Par exemple, s'il y a 10 000 points de montage dans le cluster, le quota doit être augmenté à 10000.

Pour définir l'attribut de volume skipCSIBucketAccessCheck, consultez l'exemple de configuration suivant :

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"
   

Autres considérations sur les performances

Au-delà des optimisations principales abordées, plusieurs autres facteurs peuvent avoir un impact significatif sur les performances globales de Cloud Storage FUSE. Les sections suivantes décrivent d'autres considérations relatives aux performances que nous vous recommandons de prendre en compte lorsque vous utilisez Cloud Storage FUSE.

Augmenter la limite de renommage pour les buckets non HNS

Les charges de travail de point de contrôle doivent toujours être effectuées avec un bucket pour lequel l'espace de noms hiérarchique est activé, en raison des renommages atomiques et plus rapides, et des RPS plus élevés pour les lectures et les écritures. Toutefois, si vous acceptez le risque que les renommages de répertoires ne soient pas atomiques et prennent plus de temps, vous pouvez utiliser l'option de configuration rename-dir-limit si vous effectuez des points de contrôle à l'aide de buckets sans espace de noms hiérarchique pour spécifier une limite au nombre de fichiers ou d'opérations impliqués dans une opération de renommage de répertoire à un moment donné.

Nous vous recommandons de définir l'option de configuration rename-dir-limit sur une valeur élevée pour éviter les échecs de point de contrôle. Étant donné que Cloud Storage FUSE utilise un espace de noms unique et que les objets sont immuables, une opération de changement de nom de répertoire implique de renommer et de supprimer tous les fichiers individuels du répertoire. Vous pouvez contrôler le nombre de fichiers concernés par une opération de renommage en définissant l'option de configuration rename-dir-limit.

Suivez les instructions ci-dessous pour définir l'option de configuration rename-dir-limit :

gcsfuse --rename-dir-limit: 200000 \
  BUCKET_NAME

file-system:
 rename-dir-limit: 200000

mountOptions:
    - rename-dir-limit=200000

Mise en cache de la liste des kernels

Le cache de liste est un cache pour les réponses de liste de répertoires et de fichiers, ou ls, qui améliore la vitesse des opérations de liste. Contrairement aux caches de statistiques et de types, qui sont gérés par Cloud Storage FUSE, le cache de liste est conservé dans le cache de pages du noyau et est contrôlé par le noyau en fonction de la disponibilité de la mémoire.

L'activation de la mise en cache de la liste des noyaux est particulièrement utile dans les cas d'utilisation suivants :

• Charges de travail avec des listes de répertoires répétées : cette configuration est particulièrement utile pour les charges de travail qui effectuent fréquemment des listes de répertoires complètes, comme les exécutions d'entraînement d'IA/ML. Cela peut être bénéfique pour les charges de travail d'entraînement et de diffusion.

• Montages en lecture seule : la mise en cache des listes est recommandée avec les montages en lecture seule pour éviter les problèmes de cohérence.

L'activation de la mise en cache de la liste des noyaux doit être effectuée avec précaution et ne doit être utilisée que si le système de fichiers est réellement en lecture seule et qu'aucun changement de contenu de répertoire n'est attendu lors de l'exécution d'un job. En effet, avec cet indicateur, l'application locale ne voit jamais les mises à jour, surtout si la TTL est définie sur -1.

Par exemple, Client 1 liste directoryA, ce qui fait que directoryA est résident dans le cache de liste du noyau. Le client 2 crée fileB sous directoryA dans le bucket Cloud Storage. Le client 1 recherche en permanence fileB dans directoryA, ce qui revient à vérifier l'entrée du cache de la liste des kernels et ne passe jamais par le réseau. Client 1 ne voit pas qu'un nouveau fichier se trouve dans le répertoire, car la liste des fichiers est diffusée en continu à partir du cache local de la liste du noyau. Client 1 expire alors et le programme est interrompu.

Utilisez l'instruction suivante pour activer la mise en cache des listes :

gcsfuse --kernel-list-cache-ttl-secs: -1 \
  BUCKET_NAME

file-system:
 kernel-list-cache-ttl-secs: -1

mountOptions:
    - file-system:kernel-list-cache-ttl-secs:-1

Lorsque vous utilisez l'option de montage file-system:kernel-list-cache-ttl-secs, les valeurs ont la signification suivante :

• Une valeur positive représente le TTL en secondes pour conserver la réponse de la liste d'annuaires dans le cache de page du noyau.

• La valeur -1 contourne l'expiration de l'entrée et renvoie la réponse de la liste à partir du cache lorsqu'elle est disponible.

Utiliser le cache de compilation persistante (JIT) JAX avec Cloud Storage FUSE

JAX est compatible avec le cache Just-In-Time (JIT), un cache de compilation persistant facultatif qui stocke les artefacts de fonction compilés. Lorsque vous utilisez ce cache, vous pouvez accélérer considérablement les exécutions de script ultérieures en évitant les étapes de compilation redondantes.

Pour activer la mise en cache JIT, vous devez remplir les conditions suivantes :

• Utilisez la dernière version de JAX : utilisez JAX version 0.5.1 ou ultérieure pour bénéficier des dernières fonctionnalités et optimisations du cache.

• Maximisez la capacité du cache : pour éviter la dégradation des performances due à l'éviction du cache, envisagez de définir une taille de cache illimitée, en particulier si vous souhaitez remplacer les paramètres par défaut. Pour ce faire, définissez la variable d'environnement :

  export JAX_COMPILATION_CACHE_MAX_SIZE=-1
  

• Assurez-vous que le fichier YAML du pod de point de contrôle utilise la configuration du point de contrôle pour le point de montage du cache JIT JAX.

Étapes suivantes

• Utilisez un exemple de fichier YAML Google Kubernetes Engine pour configurer les bonnes pratiques d'optimisation.

• En savoir plus sur les options du fichier de configuration Cloud Storage FUSE

• En savoir plus sur les options de la CLI Cloud Storage FUSE