Práticas recomendadas para otimizar o desempenho

Esta página fornece orientações sobre como pode melhorar o Cloud Storage FUSE através das principais funcionalidades e configurações do Cloud Storage FUSE para alcançar o débito máximo e o desempenho ideal, especialmente para cargas de trabalho de inteligência artificial e aprendizagem automática (IA/AA), como preparação, publicação e criação de pontos de verificação.

Considerações

Antes de aplicar as configurações que recomendamos nesta página, considere o seguinte:

  • Pode aplicar as configurações recomendadas nesta página através de três métodos:

  • Certifique-se de que está a executar a versão mais recente do Cloud Storage FUSE. As configurações recomendadas só devem ser aplicadas à versão 3.0 ou posterior do Cloud Storage FUSE e ao controlador CSI do Cloud Storage FUSE para o Google Kubernetes Engine que é executado em clusters do GKE com a versão 1.32.2-gke.1297001 ou posterior.

  • As configurações recomendadas colocam em cache os metadados do Cloud Storage durante a duração da tarefa e não são verificadas após a montagem inicial do sistema de ficheiros. Por conseguinte, recomendamos que o sistema de ficheiros seja apenas de leitura ou que a semântica do sistema de ficheiros seja de gravação em novas aplicações, o que significa que as aplicações gravam sempre em novos ficheiros, para um desempenho ideal. As seguintes cargas de trabalho de IA/ML são de escrita para novo:

    • Criação de pontos de restauro

    • Formação

    • a servir

    • Colocar em cache de jax.jit()

  • As configurações recomendadas nesta página foram validadas para tipos de máquinas grandes de GPUs e TPUs na nuvem em grande escala, onde existe uma grande quantidade de memória e uma interface de rede de largura de banda elevada. Os tipos de máquinas de GPUs na nuvem e TPUs na nuvem podem diferir em termos do número de recursos disponíveis, como CPU, memória e armazenamento local, na respetiva configuração do nó anfitrião. Isto pode afetar diretamente o desempenho das configurações, como as seguintes:

Use contentores com o espaço de nomes hierárquico ativado

Use sempre contentores com o espaço de nomes hierárquico ativado. O espaço de nomes hierárquico organiza os seus dados numa estrutura de sistema de ficheiros hierárquica, o que torna as operações no contentor mais eficientes, resultando em tempos de resposta mais rápidos e menos chamadas de listas gerais para cada operação.

As vantagens do espaço de nomes hierárquico incluem o seguinte:

  • Os contentores com espaço de nomes hierárquico oferecem um número de consultas por segundo (CPS) inicial até oito vezes superior em comparação com os contentores simples. O espaço de nomes hierárquico suporta 40 000 pedidos de leitura de objetos iniciais por segundo e 8000 pedidos de escrita de objetos iniciais, o que é significativamente superior aos recipientes simples do FUSE do Cloud Storage típicos, que oferecem apenas 5000 pedidos de leitura de objetos por segundo inicialmente e 1000 pedidos de escrita de objetos iniciais.

  • O espaço de nomes hierárquico oferece renomeações de diretórios atómicas, que são necessárias para a criação de pontos de verificação com o Cloud Storage FUSE para garantir a atomicidade. A utilização de contentores com o espaço de nomes hierárquico ativado é especialmente vantajosa quando se faz checkpointing em grande escala, porque as frameworks de ML usam a mudança de nome de diretórios para finalizar os pontos de verificação, o que é um comando rápido e atómico, e só é suportado em contentores com o espaço de nomes hierárquico ativado. Se optar por não usar um contentor com o espaço de nomes hierárquico ativado, consulte o artigo Aumente o limite de mudança de nome para contentores não HNS.

Para saber como criar um contentor com o espaço de nomes hierárquico ativado, consulte o artigo Crie contentores com o espaço de nomes hierárquico ativado. Para saber como montar um contentor com o espaço de nomes hierárquico ativado, consulte o artigo Monte contentores com o espaço de nomes hierárquico ativado. O espaço de nomes hierárquico é suportado nas versões do Google Kubernetes Engine 1.31.1-gke.2008000 ou posteriores.

Faça uma montagem específica do diretório

Se quiser aceder a um diretório específico num contentor, pode montar apenas o diretório específico através da opção de montagem only-dir, em vez de montar o contentor inteiro. A execução de uma montagem específica do diretório acelera as chamadas de lista e reduz o número total de chamadas de lista e estatísticas, limitando o número de diretórios a percorrer ao resolver um nome de ficheiro, porque as chamadas LookUpInode e os pedidos de acesso a diretórios ou contentores geram automaticamente chamadas de lista e estatísticas para cada ficheiro ou diretório no caminho.

Para montar um diretório específico, use um dos seguintes métodos:

Google Kubernetes Engine

Use a seguinte configuração de montagem com o controlador CSI FUSE do Cloud Storage para o Google Kubernetes Engine:

volumeHandle: BUCKET_NAME
    - only-dir:DIRECTORY_NAME

Onde:

  • BUCKET_NAME é o nome do contentor no qual quer montar o diretório.

  • DIRECTORY_NAME é o nome do diretório que quer montar.

Compute Engine

Execute o comando gcsfuse --only-dir para montar um diretório específico numa máquina virtual do Compute Engine:

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

Onde:

  • BUCKET_NAME é o nome do contentor no qual quer montar o diretório.

  • DIRECTORY_NAME é o nome do diretório que quer montar.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Para mais informações sobre como realizar uma montagem de diretório, consulte o artigo Monte um diretório num contentor.

Aumente os valores da cache de metadados

Para melhorar o desempenho das leituras repetidas, pode configurar o Cloud Storage FUSE para: armazenar em cache uma grande quantidade de metadados e ignorar a expiração dos metadados, o que evita pedidos de metadados repetidos ao Cloud Storage e melhora significativamente o desempenho.

O aumento dos valores da cache de metadados é benéfico para cargas de trabalho com leituras repetidas, para evitar chamadas repetitivas do Cloud Storage e para volumes só de leitura onde se pode definir um TTL infinito.

Considere o seguinte antes de aumentar os valores da cache de metadados:

  • Um tempo de vida (TTL) infinito só deve ser definido para volumes que sejam só de leitura ou só de gravação em novos volumes.

  • A cache de metadados só deve ser ativada para aumentar significativamente de tamanho em nós com configurações de memória grandes, porque armazena em cache todos os metadados do ponto de montagem especificado em cada nó e elimina a necessidade de acesso adicional ao Cloud Storage.

  • As configurações nesta secção colocam em cache todos os metadados acedidos com um TTL infinito, o que pode afetar as garantias de consistência quando são feitas alterações no mesmo contentor do Cloud Storage por qualquer outro cliente, por exemplo, substituições num ficheiro ou eliminações de um ficheiro.

  • Para verificar se o consumo de memória não é afetado, valide se a quantidade de memória consumida pela cache de metadados é aceitável para si, que pode crescer até atingir gigabytes e depende do número de ficheiros nos contentores montados e de quantos pontos de montagem estão a ser usados. Por exemplo, os metadados de cada ficheiro ocupam aproximadamente 1,5 KiB de memória e, relativamente, os metadados de um milhão de ficheiros ocupam aproximadamente 1,5 GiB de memória. Para mais informações, consulte o artigo Vista geral do armazenamento em cache.

Siga estas instruções para configurar o Cloud Storage FUSE de modo a colocar em cache uma grande quantidade de metadados e ignorar a expiração dos metadados:

Opções de gcsfuse

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Ficheiro de configuração

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

Google Kubernetes Engine 

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

Compute Engine 

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Pré-preencha a cache de metadados

Antes de executar uma carga de trabalho, recomendamos que pré-preencha a cache de metadados, o que melhora significativamente o desempenho e reduz substancialmente o número de chamadas de metadados para o Cloud Storage, especialmente se for usado o campo implicit-dirs ou a opção --implicit-dirs. O controlador CSI do FUSE do Cloud Storage para GKE fornece uma API que processa o pré-preenchimento da cache de metadados. Consulte o artigo Use o pré-obtenção de metadados para pré-preencher a cache de metadados.

Para pré-preencher a cache de metadados, use um dos seguintes métodos:

Google Kubernetes Engine

Defina o sinalizador do atributo de volume de CSI como true:gcsfuseMetadataPrefetchOnMount

Nas versões 1.32.1-gke.1357001 ou posteriores do Google Kubernetes Engine, pode ativar a pré-obtenção de metadados para um determinado volume através da opção de configuração gcsfuseMetadataPrefetchOnMount no campo volumeAttributes da sua definição PersistentVolume. O método initContainer não é necessário quando usa a opção de configuração gcsfuseMetadataPrefetchOnMount.

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

Os recursos do contentor de inicialização podem variar consoante o conteúdo do contentor e o esquema hierárquico, por isso, considere definir recursos auxiliares de obtenção prévia de metadados personalizados para limites mais elevados.

Linux

Execute manualmente o comando ls -R no ponto de montagem do FUSE do Cloud Storage para listar recursivamente todos os ficheiros e pré-preencher a cache de metadados:

ls -R MOUNT_POINT > /dev/null

Onde:

MOUNT_POINT: o caminho para o ponto de montagem do FUSE do Cloud Storage.

Compute Engine

Execute manualmente o comando ls -R no ponto de montagem do FUSE do Cloud Storage para listar recursivamente todos os ficheiros e pré-preencher a cache de metadados:

ls -R MOUNT_POINT > /dev/null

Onde:

MOUNT_POINT: o caminho para o ponto de montagem do FUSE do Cloud Storage.

Ative a colocação em cache de ficheiros e as transferências em paralelo

A colocação em cache de ficheiros permite-lhe armazenar dados de ficheiros acedidos com frequência localmente na sua máquina, o que acelera as leituras repetidas e reduz os custos do Cloud Storage. Quando ativa a colocação em cache de ficheiros, as transferências paralelas também são ativadas automaticamente. As transferências paralelas usam vários trabalhadores para transferir um ficheiro em paralelo usando o diretório da cache de ficheiros como um buffer de obtenção prévia, o que resulta num tempo de carregamento do modelo nove vezes mais rápido.

Para saber como ativar e configurar a colocação em cache de ficheiros e as transferências paralelas, consulte o artigo Ative e configure o comportamento da colocação em cache de ficheiros. Para usar uma configuração de exemplo, consulte o artigo Configuração de exemplo para ativar o armazenamento em cache de ficheiros e as transferências paralelas.

Considerações sobre as Cloud GPUs e as Cloud TPUs para usar a colocação em cache de ficheiros e as transferências paralelas

A cache de ficheiros pode ser alojada em SSDs locais, RAM, discos persistentes ou Google Cloud Hyperdisk com as seguintes orientações. Em todos os casos, os dados ou o ficheiro grande individual têm de caber na capacidade disponível do diretório da cache de ficheiros, que é controlada através do campo max-size-mb ou da opção --file-cache-max-size-mb.

Considerações sobre as GPUs do Cloud

Os SSDs locais são ideais para dados de preparação e transferências de pontos de verificação. Os tipos de máquinas com GPUs na nuvem incluem capacidade de SSD que pode ser usada, como os tipos de máquinas A4, que incluem 12 TiBs de SSD.

  • Um disco RAM oferece o melhor desempenho para carregar os pesos do modelo devido ao seu tamanho pequeno em comparação com a quantidade não utilizada de RAM no sistema.

  • O Persistent Disk ou o Google Cloud Hyperdisk podem ser usados como uma cache.

Considerações sobre o Cloud TPU

As TPUs na nuvem não suportam SSDs locais. Se usar o armazenamento em cache de ficheiros na Cloud TPU sem modificação, a localização predefinida usada é o volume de arranque, que não é recomendado e resulta num desempenho fraco.

Em vez do volume de arranque, recomendamos que use um disco RAM, que é preferível pelo seu desempenho e sem custo incremental. No entanto, um disco RAM tem, muitas vezes, um tamanho limitado e é mais útil para publicar ponderações de modelos ou transferências de pontos de verificação, consoante o tamanho do ponto de verificação e a RAM disponível. Além disso, recomendamos a utilização do Persistent Disk e do Google Cloud Hyperdisk para fins de colocação em cache.

Exemplo de configuração para ativar a colocação em cache de ficheiros e as transferências paralelas

Por predefinição, a cache de ficheiros usa um SSD local se o ephemeral-storage-local-ssdmodo estiver ativado para o nó do Google Kubernetes Engine. Se não estiver disponível nenhum SSD local, por exemplo, em máquinas de TPU na nuvem, a cache de ficheiros usa o disco de arranque do nó do Google Kubernetes Engine, o que não é recomendado. Neste caso, pode usar um disco RAM como o diretório da cache, mas considere a quantidade de RAM disponível para o armazenamento em cache de ficheiros em comparação com o que é necessário para o pod.

Opções de gcsfuse

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

Ficheiro de configuração

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

GPUs do Cloud 

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Desative as entradas de cache de estatísticas negativas

Por predefinição, o Cloud Storage FUSE armazena em cache entradas de estatísticas negativas, ou seja, entradas para ficheiros que não existem, com um TTL de cinco segundos. Em cargas de trabalho em que os ficheiros são criados ou eliminados com frequência, como a criação de pontos de verificação distribuídos, estas entradas em cache podem ficar desatualizadas rapidamente, o que leva a problemas de desempenho. Para evitar esta situação, recomendamos que desative a cache de estatísticas negativas para cargas de trabalho de preparação, publicação e verificação de pontos de controlo através do campo negative-ttl-secs ou da opção --metadata-cache-negative-ttl-secs.

Siga as instruções abaixo para desativar a cache de estatísticas negativas:

Opção gcsfuse

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

Ficheiro de configuração

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Ative as gravações de streaming

As gravações de streaming carregam dados diretamente para o Cloud Storage à medida que são escritos, o que reduz a latência e a utilização do espaço em disco. Isto é particularmente benéfico para escritas sequenciais grandes, como pontos de verificação. As escritas de streaming estão ativadas por predefinição na versão 3.0 e posteriores do FUSE do Cloud Storage.

Se as gravações de streaming não estiverem ativadas por predefinição, siga as instruções abaixo para as ativar. A ativação de gravações de streaming requer a versão 3.0 do FUSE do Cloud Storage, que está disponível nas versões 1.32.1-gke.1729000 ou posteriores do Google Kubernetes Engine.

Opção gcsfuse

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

Ficheiro de configuração

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Ative as leituras em buffer

As leituras em buffer podem melhorar o desempenho de leitura sequencial de ficheiros grandes entre duas e cinco vezes através da obtenção prévia assíncrona de partes de um objeto do Cloud Storage num buffer na memória. Isto permite que as leituras subsequentes sejam publicadas a partir do buffer, em vez de exigirem chamadas de rede.

Considere o seguinte antes de ativar as leituras em buffer:

  • As leituras com buffer são incompatíveis com o armazenamento em cache de ficheiros. Se as leituras em buffer e o armazenamento em cache de ficheiros estiverem ativados, o armazenamento em cache de ficheiros tem prioridade e as leituras em buffer são ignoradas.

  • As leituras em buffer podem ocupar uma quantidade significativa de memória e recursos de computação.

Para ativar as leituras em buffer, siga estas instruções:

Opções da CLI

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

Ficheiro de configuração

write:
 enable-buffered-read: true

Aumente o tamanho de leitura antecipada do kernel

Para cargas de trabalho que envolvem principalmente leituras sequenciais de ficheiros grandes, como a publicação e as restaurações de pontos de verificação, o aumento do tamanho de leitura antecipada pode melhorar significativamente o desempenho. Isto pode ser feito através do read_ahead_kbparâmetro do kernel do Linux na sua máquina local. Recomendamos que aumente o parâmetro do kernel read_ahead_kb para 1 MB em vez de usar a quantidade predefinida de 128 KB definida na maioria das distribuições Linux. Para as instâncias do Compute Engine, são necessárias as autorizações sudo ou root para aumentar com êxito o parâmetro do kernel.

Para aumentar o parâmetro do kernel read_ahead_kb para 1 MB para um diretório montado do FUSE do Cloud Storage específico, use as seguintes instruções. O contentor tem de ser montado no FUSE do Cloud Storage antes de executar o comando. Caso contrário, o parâmetro do kernel não aumenta.

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

Onde:

  • /path/to/mount/point: o caminho no seu sistema de ficheiros local onde o contentor do Cloud Storage está montado.

Desative o serviço de tokens de segurança para evitar verificações redundantes

O controlador CSI do FUSE do Cloud Storage para o Google Kubernetes Engine tem verificações de acesso para garantir a capacidade de recuperação do pod devido à configuração incorreta pelo utilizador das associações do Workload Identity entre o contentor e a conta de serviço do GKE, o que pode atingir as quotas predefinidas da API Security Token Service em grande escala. Esta opção pode ser desativada definindo o atributo de volume skipCSIBucketAccessCheck do controlador CSI de volume persistente. Recomendamos que se certifique de que a conta de serviço do GKE tem o acesso correto ao contentor do Cloud Storage de destino para evitar falhas de montagem para o pod.

Além disso, a quota do serviço de tokens de segurança tem de ser aumentada para além do valor predefinido de 6000 se um cluster do Google Kubernetes Engine consistir em mais de 6000 nós, o que pode resultar em erros 429 se não for aumentado em implementações de grande escala. A quota do serviço de tokens de segurança tem de ser aumentada através da página Quotas e limites. Recomendamos que mantenha a quota igual ao número de montagens. Por exemplo, se existirem 10 000 montagens no cluster, a quota deve ser aumentada para 10000.

Para definir o atributo skipCSIBucketAccessCheck volume, consulte a seguinte configuração de exemplo:

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"

Outras considerações de desempenho

Além das otimizações principais abordadas, vários outros fatores podem afetar significativamente o desempenho geral do FUSE do Cloud Storage. As secções seguintes descrevem considerações de desempenho adicionais que recomendamos ter em conta quando usa o FUSE do Cloud Storage.

Aumente o limite de mudança de nome para contentores que não sejam HNS

Os pontos de verificação das cargas de trabalho devem ser sempre feitos com um contentor que tenha o espaço de nomes hierárquico ativado devido às renomeações atómicas e mais rápidas, e ao QPS mais elevado para leituras e escritas. No entanto, se aceitar o risco de as renomeações de diretórios não serem atómicas e demorarem mais tempo, pode usar o campo rename-dir-limit ou a opção --rename-dir-limit se estiver a realizar a criação de pontos de verificação com contentores sem espaço de nomes hierárquico para especificar um limite no número de ficheiros ou operações envolvidas numa operação de renomeação de diretórios em qualquer altura.

Recomendamos que especifique esta definição com um valor elevado para evitar falhas de criação de pontos de verificação. Uma vez que o Cloud Storage FUSE usa um espaço de nomes simples e os objetos são imutáveis, uma operação de mudança do nome de um diretório envolve a mudança do nome e a eliminação de todos os ficheiros individuais no diretório. Pode controlar o número de ficheiros afetados por uma operação de mudança de nome definindo a opção rename-dir-limit gcsfuse.

Siga as instruções que se seguem para definir a opção de configuração rename-dir-limit:

Opção gcsfuse

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

Ficheiro de configuração

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Colocação em cache da lista do kernel

A cache de listas é uma cache para respostas de diretórios e listas de ficheiros, ou ls, que melhora a velocidade das operações de listas. Ao contrário das caches de estatísticas e tipos, que são geridas pelo FUSE do Cloud Storage, a cache de listas é mantida na cache de páginas do kernel e é controlada pelo kernel com base na disponibilidade de memória.

A ativação da colocação em cache da lista do kernel é mais vantajosa para os seguintes exemplos de utilização:

  • Cargas de trabalho com listas de diretórios repetidas: esta configuração é especialmente útil para cargas de trabalho que executam listas de diretórios completas com frequência, como execuções de preparação de IA/AA. Isto pode beneficiar as cargas de trabalho de publicação e de preparação.

  • Montagens só de leitura: recomenda-se o armazenamento em cache de listas com montagens só de leitura para evitar problemas de consistência.

A ativação da colocação em cache da lista do kernel deve ser feita com precaução e só deve ser usada se o sistema de ficheiros for verdadeiramente só de leitura, sem alterações esperadas ao conteúdo do diretório durante a execução de uma tarefa. Isto deve-se ao facto de, com esta flag, a aplicação local nunca ver atualizações, especialmente se o TTL estiver definido como -1.

Por exemplo, Cliente 1 lista directoryA, o que faz com que directoryA seja um residente na cache da lista do kernel. O cliente 2 cria fileB em directoryA no contentor do Cloud Storage. O cliente 1 verifica continuamente a existência de fileB em directoryA, o que consiste essencialmente em verificar a entrada da cache da lista do kernel e nunca acede à rede. O cliente 1 não vê que existe um novo ficheiro no diretório porque a lista de ficheiros é servida continuamente a partir da cache da lista do kernel local. O cliente 1 excede o tempo limite e o programa é interrompido.

Siga esta instrução para ativar a colocação em cache de listas:

Opção gcsfuse

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

Ficheiro de configuração

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

Onde:

  • BUCKET_NAME é o nome do seu contentor.

  • MOUNT_POINT é o diretório local onde o seu contentor vai ser montado. Por exemplo, /path/to/mount/point.

Quando usa a opção de montagem file-system:kernel-list-cache-ttl-secs, os valores significam o seguinte:

  • Um valor positivo representa o TTL em segundos para manter a resposta da lista de diretórios na cache de páginas do kernel.

  • Um valor de -1 ignora a expiração da entrada e devolve a resposta da lista da cache quando estiver disponível.

Use a cache de compilação persistente (JIT) do JAX com o FUSE do Cloud Storage

O JAX suporta a cache Just-In-Time (JIT), uma cache de compilação persistente opcional que armazena artefactos de funções compiladas. Quando usa esta cache, pode acelerar significativamente as execuções de scripts subsequentes, evitando passos de compilação redundantes.

Para ativar o armazenamento em cache JIT, tem de cumprir os seguintes requisitos:

  • Use a versão mais recente do JAX: use as versões 0.5.1 ou posteriores do JAX para as funcionalidades e otimizações de cache mais recentes.

  • Maximize a capacidade da cache: para evitar a degradação do desempenho devido à remoção da cache, considere definir um tamanho ilimitado para a cache, especialmente se quiser substituir as predefinições. Pode fazê-lo definindo a variável de ambiente:

    export JAX_COMPILATION_CACHE_MAX_SIZE=-1

  • Certifique-se de que o YAML do pod de posto de controlo: use a configuração do posto de controlo para o ponto de montagem da cache JIT do JAX.

O que se segue?