Best practice per l'ottimizzazione delle prestazioni

La messa a punto delle funzionalità e delle configurazioni chiave di Cloud Storage FUSE ti aiuta a massimizzare il throughput e le prestazioni, in particolare per i workload di intelligenza artificiale e machine learning (AI/ML) come l'addestramento, la gestione e il checkpointing. Questo documento descrive le best practice per l'ottimizzazione delle prestazioni di Cloud Storage FUSE.

Considerazioni

Prima di applicare le configurazioni consigliate in questa pagina, tieni presente quanto segue:

  • Puoi applicare le configurazioni consigliate in questa pagina utilizzando i seguenti metodi:

  • Assicurati di utilizzare l'ultima versione di Cloud Storage FUSE. Le configurazioni consigliate devono essere applicate solo a Cloud Storage FUSE versione 3.0 o successive e al driver CSI di Cloud Storage FUSE per Google Kubernetes Engine eseguito su cluster GKE versione 1.32.2-gke.1297001 o successive.

  • Le configurazioni consigliate memorizzano nella cache i metadati di Cloud Storage per la durata del job e non vengono controllate dopo il montaggio iniziale del file system. Pertanto, per prestazioni ottimali, consigliamo che il file system sia di sola lettura o che la semantica del file system sia di tipo write-to-new, ovvero che le applicazioni scrivano sempre in nuovi file. I seguenti workload AI/ML sono di tipo write-to-new:

    • Checkpointing

    • Formazione

    • Pubblicazione

    • Memorizzazione nella cache di jax.jit()

  • Le configurazioni consigliate in questa pagina sono state convalidate per i tipi di macchine di grandi dimensioni Cloud GPU e Cloud TPU su larga scala, dove è presente una grande quantità di memoria e un'interfaccia di rete con larghezza di banda elevata. I tipi di macchine Cloud GPU e Cloud TPU possono differire in termini di numero di risorse disponibili, come CPU, memoria e spazio di archiviazione locale, all'interno della configurazione del nodo host. Ciò può influire direttamente sulle prestazioni per configurazioni come le seguenti:

Supporto di Rapid Bucket

A partire dalla versione 3.7.1, Cloud Storage FUSE supporta Rapid Bucket con un percorso di lettura ottimizzato.

Il percorso di lettura ottimizzato migliora significativamente le prestazioni utilizzando l'algoritmo di read-ahead del kernel Linux per impostazione predefinita. Per utilizzare questo percorso di lettura ottimizzato, sono necessarie modifiche di configurazione specifiche a livello di macchina per i parametri read_ahead_kb, max_background e congestion_threshold. Negli ambienti Google Kubernetes Engine (GKE) che utilizzano il driver CSI di Cloud Storage FUSE, queste configurazioni sono completamente gestite e applicate automaticamente. Per le VM di Compute Engine e altri ambienti non GKE, Cloud Storage FUSE richiede le autorizzazioni sudo per applicare automaticamente queste modifiche oppure devi configurare questi parametri manualmente.

Quando utilizzi il percorso di lettura ottimizzato per i bucket Rapid, tieni presente i seguenti comportamenti e limitazioni:

  • Compatibilità con la cache dei file e il lettore con buffer: poiché il percorso di lettura ottimizzato si basa sull'algoritmo di read-ahead del kernel, non è compatibile con la cache dei file e il lettore con buffer di Cloud Storage FUSE. Per impostazione predefinita, queste funzionalità sono non attive (no-op) per i bucket Rapid. Se il tuo workload richiede la cache dei file o il lettore con buffer, devi disattivare esplicitamente il lettore del kernel impostando enable-kernel-reader: false durante il montaggio. In questo modo, Cloud Storage FUSE utilizzerà il percorso di lettura standard, compatibile con la memorizzazione nella cache dei file e le letture con buffer.
  • Requisiti di montaggio: il nuovo percorso di lettura è supportato solo per i montaggi statici. Non è supportato quando si utilizza il montaggio dinamico.

Utilizza i bucket con lo spazio dei nomi gerarchico abilitato

Utilizza sempre bucket con lo spazio dei nomi gerarchico abilitato. Lo spazio dei nomi gerarchico organizza i dati in una struttura di file system gerarchica, che rende più efficienti le operazioni all'interno del bucket, con tempi di risposta più rapidi e un numero inferiore di chiamate di elenco complessive per ogni operazione.

I vantaggi dello spazio dei nomi gerarchico includono:

  • I bucket con spazio dei nomi gerarchico forniscono un numero di query al secondo (QPS) iniziali fino a otto volte superiore rispetto ai bucket piatti. Lo spazio dei nomi gerarchico supporta 40.000 richieste di lettura di oggetti iniziali al secondo e 8000 richieste di scrittura di oggetti iniziali, un numero significativamente superiore rispetto ai tipici bucket piatti di Cloud Storage FUSE, che offrono inizialmente solo 5000 richieste di lettura di oggetti al secondo e 1000 richieste di scrittura di oggetti iniziali.

  • Lo spazio dei nomi gerarchico fornisce ridenominazioni atomiche delle directory, necessarie per il checkpoint con Cloud Storage FUSE per garantire l'atomicità. L'utilizzo di bucket con lo spazio dei nomi gerarchico abilitato è particolarmente vantaggioso quando si esegue il checkpoint su larga scala, perché i framework di ML utilizzano la ridenominazione delle directory per finalizzare i checkpoint, che è un comando atomico rapido ed è supportato solo nei bucket con lo spazio dei nomi gerarchico abilitato. Se scegli di non utilizzare un bucket con spazio dei nomi gerarchico abilitato, consulta Aumenta il limite di ridenominazione per i bucket non HNS.

Per scoprire come creare un bucket con lo spazio dei nomi gerarchico abilitato, consulta Crea bucket con lo spazio dei nomi gerarchico abilitato. Per scoprire come montare un bucket con spazio dei nomi gerarchico abilitato, consulta Monta i bucket con spazio dei nomi gerarchico abilitato. Lo spazio dei nomi gerarchico è supportato su Google Kubernetes Engine versione 1.31.1-gke.2008000 o successive.

Esegui un montaggio specifico per la directory

Se vuoi accedere a una directory specifica all'interno di un bucket, puoi montare solo la directory specifica utilizzando l'opzione di montaggio only-dir anziché montare l'intero bucket. L'esecuzione di un montaggio specifico per la directory accelera le chiamate di elenco e riduce il numero complessivo di chiamate di elenco e statistiche limitando il numero di directory da attraversare durante la risoluzione di un nome file, perché le chiamate LookUpInode e le richieste di accesso ai bucket o alle directory generano automaticamente chiamate di elenco e statistiche per ogni file o directory nel percorso.

Per montare una directory specifica, utilizza uno dei seguenti metodi:

Google Kubernetes Engine

Per i volumi permanenti, utilizza la seguente configurazione di montaggio con il driver CSI di Cloud Storage FUSE per Google Kubernetes Engine:

mountOptions:
    - only-dir:DIRECTORY_NAME

Per i volumi temporanei, aggiungi la configurazione di montaggio a volumeAttributes.mountOptions, con i flag separati da virgole:

mountOptions: "OTHER_OPTIONS,only-dir:DIRECTORY_NAME"

Sostituisci DIRECTORY_NAME con il nome della directory che vuoi montare.

Compute Engine

Esegui il comando gcsfuse --only-dir per montare una directory specifica su una macchina virtuale Compute Engine:

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket in cui vuoi montare la directory.

  • DIRECTORY_NAME è il nome della directory che vuoi montare.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

Per ulteriori informazioni su come eseguire il montaggio di una directory, consulta Monta una directory all'interno di un bucket.

Aumenta i valori della cache dei metadati

Per migliorare le prestazioni delle letture ripetute, puoi configurare Cloud Storage FUSE in modo da memorizzare nella cache una grande quantità di metadati e ignorare la scadenza dei metadati, evitando così richieste ripetute di metadati a Cloud Storage e migliorando notevolmente le prestazioni.

L'aumento dei valori della cache dei metadati è utile per i workload con letture ripetute per evitare chiamate Cloud Storage ripetitive e per i volumi di sola lettura in cui è possibile impostare un TTL infinito.

Prima di aumentare i valori della cache dei metadati, tieni presente quanto segue:

  • Una durata (TTL) infinita deve essere impostata solo per i volumi di sola lettura o di sola scrittura su nuovi file.

  • La cache dei metadati deve essere abilitata per aumentare in modo significativo le dimensioni solo sui nodi con configurazioni di memoria di grandi dimensioni, perché memorizza nella cache tutti i metadati per il punto di montaggio specificato in ogni nodo ed elimina la necessità di un accesso aggiuntivo a Cloud Storage.

  • Le configurazioni in questa sezione memorizzano nella cache tutti i metadati a cui è stato eseguito l'accesso con un TTL infinito, il che può influire sulle garanzie di coerenza quando vengono apportate modifiche allo stesso bucket Cloud Storage da qualsiasi altro client, ad esempio sovrascritture o eliminazioni di un file.

  • Per verificare che il consumo di memoria non sia influenzato, controlla che la quantità di memoria consumata dalla cache dei metadati sia accettabile per te. Questa quantità può crescere fino a gigabyte e dipende dal numero di file nei bucket montati e dal numero di punti di montaggio utilizzati. Ad esempio, i metadati di ogni file occupano circa 1,5 KiB di memoria e, in proporzione, i metadati di un milione di file occupano circa 1,5 GiB di memoria. Per saperne di più, consulta Panoramica della memorizzazione nella cache.

Utilizza le seguenti istruzioni per configurare Cloud Storage FUSE in modo da memorizzare nella cache una grande quantità di metadati e ignorare la scadenza dei metadati:

Opzioni gcsfuse

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

File di configurazione

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

Google Kubernetes Engine 

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

Compute Engine 

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

Precompila la cache dei metadati

Prima di eseguire un workload, ti consigliamo di precompilare la cache dei metadati, in modo da migliorare significativamente le prestazioni e ridurre sostanzialmente il numero di chiamate ai metadati in Cloud Storage, in particolare se viene utilizzato il campo implicit-dirs o l'opzione --implicit-dirs. Il driver CSI di Cloud Storage FUSE per GKE fornisce un'API che gestisce la precompilazione della cache dei metadati. Consulta Utilizza il precaricamento dei metadati per precompilare la cache dei metadati.

Per precompilare la cache dei metadati, utilizza uno dei seguenti metodi:

Google Kubernetes Engine

Imposta il flag dell'attributo del volume CSI gcsfuseMetadataPrefetchOnMount su true:

In Google Kubernetes Engine versione 1.32.1-gke.1357001 o successive, puoi attivare il precaricamento dei metadati per un determinato volume utilizzando l'opzione di configurazione gcsfuseMetadataPrefetchOnMount nel campo volumeAttributes della definizione di PersistentVolume. Il metodo initContainer non è necessario quando utilizzi l'opzione di configurazione gcsfuseMetadataPrefetchOnMount.

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

Le risorse del container init possono variare in base ai contenuti del bucket e al layout gerarchico, quindi valuta la possibilità di impostare risorse sidecar di precaricamento dei metadati personalizzati per limiti più elevati.

Linux

Esegui manualmente il comando ls -R sul punto di montaggio di Cloud Storage FUSE per elencare in modo ricorsivo tutti i file e precompilare la cache dei metadati:

ls -R MOUNT_POINT > /dev/null

Sostituisci quanto segue:

MOUNT_POINT: il percorso del punto di montaggio di Cloud Storage FUSE.

Compute Engine

Esegui manualmente il comando ls -R sul punto di montaggio di Cloud Storage FUSE per elencare in modo ricorsivo tutti i file e precompilare la cache dei metadati:

ls -R MOUNT_POINT > /dev/null

Sostituisci quanto segue:

MOUNT_POINT: il percorso del punto di montaggio di Cloud Storage FUSE.

Abilita la memorizzazione dei file nella cache e i download paralleli

La memorizzazione dei file nella cache ti consente di archiviare localmente sulla tua macchina i dati dei file a cui accedi di frequente, velocizzando le letture ripetute e riducendo i costi di Cloud Storage. Quando attivi la memorizzazione nella cache dei file, vengono attivati automaticamente anche i download paralleli. I download paralleli utilizzano più worker per scaricare un file in parallelo utilizzando la directory della cache dei file come buffer di precaricamento, con un tempo di caricamento del modello nove volte più rapido.

Per scoprire come attivare e configurare la memorizzazione dei file nella cache e i download paralleli, consulta Attiva e configura il comportamento di memorizzazione dei file nella cache. Per utilizzare una configurazione di esempio, consulta Configurazione di esempio per l'attivazione della memorizzazione nella cache dei file e dei download paralleli.

Considerazioni su Cloud GPU e Cloud TPU per l'utilizzo della memorizzazione nella cache dei file e dei download paralleli

La cache dei file può essere ospitata su SSD locali, RAM, Persistent Disk o Google Cloud Hyperdisk con le seguenti linee guida. In tutti i casi, i dati o il singolo file di grandi dimensioni devono rientrare nella capacità disponibile della directory della cache dei file, che viene controllata utilizzando il campo max-size-mb o l'opzione --file-cache-max-size-mb.

Considerazioni sulle Cloud GPU

Le unità SSD locali sono ideali per i dati di addestramento e i download dei checkpoint. I tipi di macchine Cloud GPU includono una capacità SSD che può essere utilizzata, ad esempio i tipi di macchine A4 che includono 12 TiB di SSD.

  • Un disco RAM offre le migliori prestazioni per il caricamento dei pesi del modello grazie alle sue dimensioni ridotte rispetto alla quantità di RAM inutilizzata sul sistema.

  • Sia Persistent Disk che Google Cloud Hyperdisk possono essere utilizzati come cache.

Considerazioni su Cloud TPU

Cloud TPU non supporta gli SSD locali. Se utilizzi la memorizzazione nella cache dei file su Cloud TPU senza modifiche, la località predefinita utilizzata è il volume di avvio, che non è consigliata e comporta prestazioni scadenti.

Anziché il volume di avvio, ti consigliamo di utilizzare un disco RAM, che è preferibile per le sue prestazioni e per il fatto che non comporta costi incrementali. Tuttavia, un disco RAM è spesso di dimensioni limitate ed è più utile per la pubblicazione dei pesi del modello o per i download dei checkpoint, a seconda delle dimensioni del checkpoint e della RAM disponibile. Inoltre, ti consigliamo di utilizzare Persistent Disk e Google Cloud Hyperdisk per scopi di memorizzazione nella cache.

Configurazione di esempio per l'attivazione della memorizzazione dei file nella cache e dei download paralleli

Per impostazione predefinita, la cache dei file utilizza un'unità SSD locale se la modalità ephemeral-storage-local-ssd è abilitata per il nodo Google Kubernetes Engine. Se non è disponibile un'unità SSD locale, ad esempio sulle macchine Cloud TPU, la cache dei file utilizza il disco di avvio del nodo Google Kubernetes Engine, il che non è consigliato. In questo caso, puoi utilizzare un disco RAM come directory della cache, ma considera la quantità di RAM disponibile per la memorizzazione dei file nella cache rispetto a quella necessaria per il pod.

Opzioni gcsfuse

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

File di configurazione

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

Cloud GPU 

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

Cloud TPU 

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

Compute Engine 

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

Disattiva le voci della cache stat negativa

Per impostazione predefinita, Cloud Storage FUSE memorizza nella cache le voci di stato negative, ovvero le voci per i file che non esistono, con un TTL di cinque secondi. Nei workload in cui i file vengono creati o eliminati di frequente, come il checkpointing distribuito, queste voci memorizzate nella cache possono diventare rapidamente obsolete, causando problemi di prestazioni. Per evitare questo problema, ti consigliamo di disattivare la cache delle statistiche negative per i workload di addestramento, distribuzione e checkpoint utilizzando il campo negative-ttl-secs o l'opzione --metadata-cache-negative-ttl-secs.

Segui queste istruzioni per disattivare la cache delle statistiche negative:

gcsfuse opzione

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

File di configurazione

metadata-cache:
 negative-ttl-secs: 0

Google Kubernetes Engine 

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

Compute Engine 

gcsfuse --metadata-cache-negative-ttl-secs=0 \
  BUCKET_NAME MOUNT_POINT

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

Abilita scritture in streaming

Le scritture in modalità flusso caricano i dati direttamente su Cloud Storage man mano che vengono scritti, riducendo la latenza e l'utilizzo dello spazio su disco. Ciò è particolarmente vantaggioso per scritture sequenziali di grandi dimensioni, come i checkpoint. Le scritture in modalità flusso sono abilitate per impostazione predefinita su Cloud Storage FUSE versione 3.0 e successive.

Se le scritture in modalità flusso non sono abilitate per impostazione predefinita, utilizza le seguenti istruzioni per abilitarle. L'abilitazione delle scritture in streaming richiede Cloud Storage FUSE versione 3.0, disponibile su Google Kubernetes Engine versione 1.32.1-gke.1729000 o successive.

gcsfuse opzione

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

File di configurazione

write:
 enable-streaming-writes: true

Google Kubernetes Engine 

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

Compute Engine 

gcsfuse --enable-streaming-writes=true \
  BUCKET_NAME MOUNT_POINT

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

Abilita letture con buffer

Le letture con buffer possono migliorare le prestazioni di lettura sequenziale per i file di grandi dimensioni da due a cinque volte eseguendo il precaricamento asincrono di parti di un oggetto Cloud Storage in un buffer in memoria. In questo modo, le letture successive possono essere gestite dal buffer anziché richiedere chiamate di rete.

Prima di attivare le letture con buffer, tieni presente quanto segue:

  • Le letture con buffer non sono compatibili con la memorizzazione dei file nella cache. Se sono abilitate sia le letture con buffer sia la memorizzazione dei file nella cache, quest'ultima ha la precedenza e le letture con buffer vengono ignorate.

  • Le letture con buffer possono consumare una quantità significativa di memoria e risorse di computing.

Per attivare le letture con buffer, segui queste istruzioni:

Opzioni CLI

gcsfuse --enable-buffered-read=true \
  BUCKET_NAME

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

File di configurazione

read:
 enable-buffered-read: true

Aumenta le dimensioni di read-ahead del kernel

Per i workload che prevedono principalmente letture sequenziali di file di grandi dimensioni, come l'addestramento e i ripristini dei checkpoint, l'aumento delle dimensioni della lettura anticipata può migliorare significativamente le prestazioni. Per farlo, utilizza il parametro del kernel Linux read_ahead_kb sulla tua macchina locale. Ti consigliamo di aumentare il parametro kernel read_ahead_kb a 1 MB anziché utilizzare la quantità predefinita di 128 kB impostata sulla maggior parte delle distribuzioni Linux. Per le istanze di Compute Engine, sono necessarie le autorizzazioni sudo o root per aumentare correttamente il parametro del kernel.

Per aumentare il parametro del kernel read_ahead_kb a 1 MB per una directory specifica montata su Cloud Storage FUSE, segui queste istruzioni. Il bucket deve essere montato su Cloud Storage FUSE prima di eseguire il comando, altrimenti il parametro del kernel non aumenta.

Per i bucket a livello di zona, Cloud Storage FUSE gestisce automaticamente il parametro kernel read_ahead_kb in Google Kubernetes Engine versione 1.35.0-gke.3047001 o successive e negli ambienti Compute Engine utilizzando Cloud Storage FUSE versione 3.7.0 o successive. Poiché questa operazione viene gestita automaticamente, l'opzione di montaggio read_ahead_kb non è più applicabile; qualsiasi valore fornito verrà ignorato. Tieni presente che negli ambienti Compute Engine, Cloud Storage FUSE richiede autorizzazioni root o sudo senza password per gestire automaticamente questo parametro.

Google Kubernetes Engine 

mountOptions:
    - read_ahead_kb=1024

Compute Engine 

export MOUNT_POINT=/path/to/mount/point
echo 1024 | sudo tee /sys/class/bdi/0:$(stat -c "%d" $MOUNT_POINT)/read_ahead_kb

Sostituisci quanto segue:

  • /path/to/mount/point: il percorso nel file system locale in cui è montato il bucket Cloud Storage.

Disattiva Security Token Service per evitare controlli ridondanti

Il driver CSI di Cloud Storage FUSE per Google Kubernetes Engine dispone di controlli di accesso per garantire la recuperabilità dei pod in caso di errori di configurazione da parte dell'utente delle associazioni di Workload Identity tra il bucket e il account di servizio GKE, che possono raggiungere le quote predefinite dell'API Security Token Service su larga scala. Questa opzione può essere disattivata impostando l'attributo del volume skipCSIBucketAccessCheck del driver CSI del volume permanente. Ti consigliamo di assicurarti che il account di servizio GKE disponga dell'accesso corretto al bucket Cloud Storage di destinazione per evitare errori di montaggio per il pod.

Inoltre, la quota di Security Token Service deve essere aumentata oltre il valore predefinito di 6000 se un cluster Google Kubernetes Engine è composto da più di 6000 nodi, il che può causare errori 429 se non viene aumentata nei deployment su larga scala. La quota di Security Token Service deve essere aumentata tramite la pagina Quote e limiti. Ti consigliamo di mantenere la quota uguale al numero di montaggi. Ad esempio, se nel cluster sono presenti 10.000 montaggi, la quota deve essere aumentata a 10000.

Per impostare l'attributo del volume skipCSIBucketAccessCheck, consulta la seguente configurazione di esempio:

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"

Ottimizza le prestazioni per i checkpoint Orbax OCDBT

Per i workload che utilizzano checkpoint Orbax formattati in OCDBT, puoi migliorare le prestazioni di distribuzione e ripristino dei checkpoint seguendo queste indicazioni:

  • Imposta le transparent huge page su always: l'impostazione delle transparent huge page su always migliora le prestazioni riducendo la frammentazione della memoria e le chiamate di sistema. Questa impostazione è più efficace quando vengono allocate grandi quantità di memoria, come accade spesso in questi workload. Questa impostazione è configurata per impostazione predefinita sulle macchine Cloud TPU e deve essere impostata solo su altri tipi di macchine. Per attivare le pagine enormi trasparenti sulla tua macchina locale, esegui questo comando con le autorizzazioni root.

    echo always | tee /sys/kernel/mm/transparent_hugepage/enabled

    In un ambiente GKE, puoi creare un pod con privilegi per fare la stessa cosa.

  • Aumenta le dimensioni di read-ahead del kernel: l'aumento delle dimensioni di read-ahead del kernel a 1024 kB migliora le prestazioni di lettura sequenziale. Per saperne di più, consulta Aumenta le dimensioni di read-ahead del kernel.

  • Imposta ocdbt_target_data_file_size su 200 MiB: imposta ocdbt_target_data_file_size su 200 MiB, che è il valore ottimale per le prestazioni di lettura con Cloud Storage FUSE.

  • Utilizza la memorizzazione nella cache DNS: la memorizzazione nella cache DNS riduce la latenza memorizzando nella cache le ricerche DNS localmente. In GKE, puoi abilitare NodeLocal DNSCache per memorizzare nella cache le ricerche DNS. In alternativa, utilizza Cloud Storage FUSE versione 3.5 o successive su Compute Engine o GKE versione 1.34.1-gke.3899000 o successive in un ambiente GKE.

Altre considerazioni sulle prestazioni

Oltre alle ottimizzazioni principali discusse, diversi altri fattori possono influire in modo significativo sulle prestazioni complessive di Cloud Storage FUSE. Le sezioni seguenti descrivono ulteriori considerazioni sulle prestazioni che ti consigliamo di tenere presenti quando utilizzi Cloud Storage FUSE.

Aumenta il limite di ridenominazione per i bucket non HNS

I workload di checkpoint devono essere sempre eseguiti con un bucket con spazio dei nomi gerarchico abilitato per via delle ridenominazioni atomiche e più rapide e delle QPS più elevate per le letture e le scritture. Tuttavia, se accetti il rischio che le ridenominazioni delle directory non siano atomiche e richiedano più tempo, puoi utilizzare il campo rename-dir-limit o l'opzione --rename-dir-limit se esegui il checkpoint utilizzando bucket senza namespace gerarchico per specificare un limite al numero di file o operazioni coinvolti in un'operazione di ridenominazione della directory in un determinato momento.

Ti consigliamo di specificare un valore elevato per questa impostazione per evitare errori di checkpoint. Poiché Cloud Storage FUSE utilizza uno spazio dei nomi semplice e gli oggetti sono immutabili, un'operazione di ridenominazione di una directory comporta la ridenominazione e l'eliminazione di tutti i singoli file al suo interno. Puoi controllare il numero di file interessati da un'operazione di ridenominazione impostando l'opzione gcsfuse di rename-dir-limit.

Utilizza le seguenti istruzioni per impostare l'opzione di configurazione rename-dir-limit:

gcsfuse opzione

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

File di configurazione

file-system:
 rename-dir-limit: 200000

Google Kubernetes Engine 

mountOptions:
    - rename-dir-limit=200000

Compute Engine 

gcsfuse --rename-dir-limit=200000 \
  BUCKET_NAME MOUNT_POINT

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

Memorizzazione nella cache dell'elenco dei kernel

La cache degli elenchi è una cache per le risposte degli elenchi di directory e file o ls che migliora la velocità delle operazioni sugli elenchi. A differenza della cache delle statistiche, gestita da Cloud Storage FUSE, la cache degli elenchi viene conservata nella cache delle pagine del kernel ed è controllata dal kernel in base alla disponibilità della memoria.

L'attivazione della memorizzazione nella cache dell'elenco dei kernel è particolarmente utile per i seguenti casi d'uso:

  • Workload con elenchi di directory ripetuti: questa configurazione è particolarmente utile per i workload che eseguono elenchi di directory completi frequenti, come le esecuzioni di addestramento AI/ML. Questo può essere utile sia per i workload di distribuzione che per quelli di addestramento.

  • Montaggi di sola lettura: la memorizzazione nella cache degli elenchi è consigliata con i montaggi di sola lettura per evitare problemi di coerenza.

L'abilitazione della memorizzazione nella cache degli elenchi del kernel deve essere eseguita con cautela e deve essere utilizzata solo se il file system è effettivamente di sola lettura e non sono previste modifiche ai contenuti della directory durante l'esecuzione di un job. Questo perché con questo flag l'applicazione locale non vede mai gli aggiornamenti, soprattutto se il TTL è impostato su -1.

Ad esempio, Client 1 elenca directoryA, il che fa sì che directoryA sia un residente nella cache dell'elenco del kernel. Il client 2 crea fileB in directoryA nel bucket Cloud Storage. Client 1 controlla continuamente la presenza di fileB in directoryA, il che consiste essenzialmente nel controllare la voce della cache dell'elenco del kernel e non passa mai attraverso la rete. Il Client 1 non vede che nella directory è presente un nuovo file perché l'elenco dei file viene fornito continuamente dalla cache dell'elenco del kernel locale. Client 1 va in timeout e il programma si interrompe.

Per attivare la memorizzazione nella cache degli elenchi, segui queste istruzioni:

gcsfuse opzione

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

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

File di configurazione

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

Google Kubernetes Engine 

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

Compute Engine 

gcsfuse --kernel-list-cache-ttl-secs=-1 \
  BUCKET_NAME MOUNT_POINT

Sostituisci quanto segue:

  • BUCKET_NAME è il nome del bucket.

  • MOUNT_POINT è la directory locale in cui verrà montato il bucket. Ad esempio, /path/to/mount/point.

Quando utilizzi l'opzione di montaggio file-system:kernel-list-cache-ttl-secs, i valori significano quanto segue:

  • Un valore positivo rappresenta il TTL in secondi per mantenere la risposta dell'elenco di directory nella cache di pagina del kernel.

  • Un valore -1 ignora la scadenza della voce e restituisce la risposta dell'elenco dalla cache, se disponibile.

Utilizza la cache di compilazione (JIT) persistente di JAX con Cloud Storage FUSE

JAX supporta la cache Just-In-Time (JIT), una cache di compilazione permanente facoltativa che archivia gli artefatti delle funzioni compilate. Quando utilizzi questa cache, puoi velocizzare notevolmente le esecuzioni successive degli script evitando passaggi di compilazione ridondanti.

Per abilitare la memorizzazione nella cache JIT, devi soddisfare i seguenti requisiti:

  • Utilizza l'ultima versione di JAX: utilizza le versioni 0.5.1 o successive di JAX per le funzionalità e le ottimizzazioni più recenti della cache.

  • Massimizza la capacità della cache: per evitare un peggioramento delle prestazioni dovuto all'eliminazione della cache, valuta la possibilità di impostare una dimensione della cache illimitata, in particolare se vuoi eseguire l'override delle impostazioni predefinite. Per farlo, imposta la variabile di ambiente:

    export JAX_COMPILATION_CACHE_MAX_SIZE=-1

  • Assicurati che il file YAML del pod di checkpoint utilizzi la configurazione del checkpoint per il punto di montaggio della cache JIT JAX.

Configura Receive Flow Steering (RFS) per A4X

Nelle istanze di Compute Engine, Receive Packet Steering (RPS) e Receive Flow Steering (RFS) collaborano per migliorare le prestazioni di rete distribuendo in modo intelligente l'elaborazione dei pacchetti di rete su più CPU. Consigliamo queste impostazioni per il traffico di rete ad alta frequenza su tipi di macchine come A4X.

  • RPS distribuisce i pacchetti di rete in entrata tra diverse CPU per l'elaborazione. In questo modo, il carico viene bilanciato e si evita che una singola CPU diventi un collo di bottiglia, il che è particolarmente utile per il traffico di rete ad alta frequenza e può contribuire a ridurre la latenza.

  • RFS si basa su RPS per ridurre ulteriormente la latenza di rete migliorando l'efficienza della cache della CPU. Indirizza i pacchetti al core della CPU specifico in cui è in esecuzione l'applicazione che li utilizzerà, il che aumenta il successo della cache dei dati della CPU e riduce la latenza di rete.

Vantaggi in termini di prestazioni

RFS migliora significativamente le prestazioni in vari workload, aumentando il throughput fino al 40%.

Considerazioni

Sebbene siano efficaci in condizioni di carico, queste impostazioni potrebbero non essere utili in tutti gli scenari:

  • Workload single-thread o a flusso singolo: un workload a flusso singolo si verifica quando tutto il traffico di rete utilizza una singola connessione di rete (ad esempio, un singolo trasferimento di file di grandi dimensioni su una connessione TCP). Queste applicazioni spesso traggono pochi vantaggi e potrebbero persino subire una leggera riduzione del throughput (ad esempio, ~7,7% in test nginx specifici). Le applicazioni a flusso singolo sono generalmente rare in contesti ad alte prestazioni.

  • Frequente migrazione dei thread: se i thread dell'applicazione si spostano spesso tra le CPU, RFS aggiorna costantemente le mappature delle CPU(ad esempio, le applicazioni che utilizzano pool di thread di lavoro dinamici di grandi dimensioni in cui le richieste vengono spesso trasferite tra core diversi), il che può portare a un traffico eccessivo tra le CPU e al riordinamento dei pacchetti.

Script di configurazione

Esegui questo script sul sistema operativo guest della tua istanza Compute Engine. Lo script richiede le autorizzazioni sudo o root per modificare i parametri del kernel.

Lo script attiva RPS, mappa le code di rete alle CPU disponibili in modalità round robin e imposta la dimensione della tabella di flusso per coda su 65536.

#!/bin/bash
set -e

# Note: This script uses 'apt' and is intended for Debian-based systems.
# If 'iproute2' is not found, you may need to run 'sudo apt update' first.
sudo apt install -y iproute2

# This script enables and configures RPS (Receive Packet Steering) and RFS
# (Receive Flow Steering) for the primary network interface.
# It creates a 1:1 mapping of CPUs to receive queues and sets a specific
# flow count for each queue.

# --- Configuration ---
# The desired number of flow entries per receive queue.
RPS_FLOW_CNT_PER_QUEUE=65536

# --- Script Body ---

# 1. Auto-detect the primary network interface.
INTERFACE=$(ip route | grep default | awk '{print $5}' | head -n 1)

if [ -z "$INTERFACE" ]; then
  echo "Error: Could not determine the primary network interface."
  exit 1
fi
echo "Primary network interface detected: $INTERFACE"

echo "Starting RPS/RFS configuration for interface: $INTERFACE"

# 2. Determine the number of receive queues for the interface.
NUM_QUEUES=$(ls -d /sys/class/net/$INTERFACE/queues/rx-* 2>/dev/null | wc -l)
if [ "$NUM_QUEUES" -eq 0 ]; then
  echo "Error: No receive queues found for interface $INTERFACE."
  echo "Please check if the network driver supports multi-queue."
  exit 1
fi
echo "Found $NUM_QUEUES receive queues for interface $INTERFACE."

# 3. Determine the number of CPUs.
NUM_CPUS=$(nproc)
if [ -z "$NUM_CPUS" ] || [ "$NUM_CPUS" -eq 0 ]; then
  echo "Error: Could not determine the number of CPUs."
  exit 1
fi
echo "Found $NUM_CPUS CPUs."

# 4. Calculate and set the total socket flow entries.
# This is the total number of entries in the global socket flow table.
RPS_SOCK_FLOW_ENTRIES=$((NUM_QUEUES * RPS_FLOW_CNT_PER_QUEUE))
echo "Setting the total RPS socket flow entries to $RPS_SOCK_FLOW_ENTRIES..."
if ! echo "$RPS_SOCK_FLOW_ENTRIES" | sudo tee /proc/sys/net/core/rps_sock_flow_entries > /dev/null; then
  echo "Error: Failed to set rps_sock_flow_entries. Please run with sufficient privileges."
  exit 1
fi

# 5. Configure each receive queue.
for i in $(seq 0 $((NUM_QUEUES - 1))); do
  RX_QUEUE="/sys/class/net/$INTERFACE/queues/rx-$i"

  # a) Assign a CPU to this queue (round-robin).
  CPU_INDEX=$((i % NUM_CPUS))
  CPU_BITMAP_HEX=$(printf '%x' $((1 << CPU_INDEX)))
  echo "Assigning CPU $CPU_INDEX (bitmap: $CPU_BITMAP_HEX) to queue rx-$i"
  if ! echo "$CPU_BITMAP_HEX" | sudo tee "$RX_QUEUE/rps_cpus" > /dev/null; then
    echo "Error writing bitmap to $RX_QUEUE/rps_cpus"
    exit 1
  fi

  # b) Set the flow count for this queue.
  echo "Setting flow count for $RX_QUEUE to $RPS_FLOW_CNT_PER_QUEUE"
  if ! echo "$RPS_FLOW_CNT_PER_QUEUE" | sudo tee "$RX_QUEUE/rps_flow_cnt" > /dev/null; then
    echo "Error writing to $RX_QUEUE/rps_flow_cnt"
    exit 1
  fi
done

echo "RPS and RFS configuration updated successfully for $INTERFACE."

Passaggi successivi