Práticas recomendadas de ajuste de performance

Esta página oferece orientações sobre como melhorar o Cloud Storage FUSE usando recursos e configurações principais para alcançar a capacidade máxima de processamento e o desempenho ideal, especialmente para cargas de trabalho de inteligência artificial e machine learning (IA/ML), como treinamento, serviço e checkpoint.

Considerações

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

• É possível aplicar as configurações recomendadas nesta página usando três métodos:

  • Arquivo de configuração do Cloud Storage FUSE

  • Opções da CLI do Cloud Storage FUSE

  • Somente para o Google Kubernetes Engine: arquivos YAML de exemplo do Google Kubernetes Engine

• Verifique se você está executando a versão mais recente do Cloud Storage FUSE. As configurações recomendadas só devem ser aplicadas ao Cloud Storage FUSE versão 3.0 ou mais recente e ao driver CSI do Cloud Storage FUSE para Google Kubernetes Engine que é executado em clusters do GKE versão 1.32.2-gke.1297001 ou mais recente.

• As configurações recomendadas armazenam em cache os metadados do Cloud Storage pela duração do job e não são verificadas após a montagem inicial do sistema de arquivos. Por isso, recomendamos que o sistema de arquivos seja somente leitura ou que a semântica do sistema de arquivos seja de aplicativos gravar em novo, ou seja, aplicativos que sempre gravam em novos arquivos, para um desempenho ideal. As seguintes cargas de trabalho de IA/ML são de gravação em novo:

  • Como estabelecer pontos de verificação

  • Treinamento

  • Disponibilização

  • Armazenamento em cache de jax.jit()

• As configurações recomendadas nesta página foram validadas para GPUs do Cloud e tipos de máquinas grandes do Cloud TPU em grande escala, com uma grande quantidade de memória e uma interface de rede de alta largura de banda. Os tipos de máquinas de GPUs do Cloud e Cloud TPU podem variar em termos de número de recursos disponíveis, como CPU, memória e armazenamento local, na configuração do nó host. Isso pode afetar diretamente o desempenho de configurações como as seguintes:

  • A3 Ultra

  • A3 Mega: 1,8 TiB de memória, com 6 TiB de LSSD

  • Cloud TPU v5e: 188 GiB de memória, sem LSSD

  • Cloud TPU v5p: 448 GiB de memória, sem LSSD

  • Cloud TPU v6 (Trillium): 1,5 TiB de memória, sem LSSD

Usar buckets com namespace hierárquico ativado

Sempre use buckets com o namespace hierárquico ativado. O namespace hierárquico organiza os dados em uma estrutura hierárquica de sistema de arquivos, o que torna as operações no bucket mais eficientes, resultando em tempos de resposta mais rápidos e menos chamadas de lista em geral para cada operação.

Confira os benefícios do namespace hierárquico:

• Os buckets com namespace hierárquico oferecem até oito vezes mais consultas iniciais por segundo (QPS) em comparação com buckets simples. O namespace hierárquico aceita 40.000 solicitações iniciais de leitura de objetos por segundo e 8.000 solicitações iniciais de gravação de objetos, o que é significativamente maior do que os buckets simples típicos do Cloud Storage FUSE, que oferecem apenas 5.000 solicitações de leitura de objetos por segundo inicialmente e 1.000 solicitações iniciais de gravação de objetos.

• O namespace hierárquico oferece renomeações atômicas de diretórios, que são necessárias para o checkpointing com o Cloud Storage FUSE para garantir a atomicidade. Usar buckets com namespace hierárquico ativado é especialmente benéfico ao criar pontos de verificação em grande escala, porque os frameworks de ML usam renomeações de diretórios para finalizar pontos de verificação, que é um comando rápido e atômico, e só é compatível com buckets com namespace hierárquico ativado. Se você optar por não usar um bucket com namespace hierárquico ativado, consulte Aumentar o limite de renomeação para buckets não HNS.

Para saber como criar um bucket com namespace hierárquico ativado, consulte Criar buckets com namespace hierárquico ativado. Para saber como montar um bucket com namespace hierárquico ativado, consulte Montar buckets com namespace hierárquico ativado. O namespace hierárquico é compatível com as versões do Google Kubernetes Engine 1.31.1-gke.2008000 ou mais recentes.

Fazer uma montagem específica de diretório

Se você quiser acessar um diretório específico em um bucket, ative apenas o diretório específico usando a opção de ativação only-dir em vez de ativar todo o bucket. A execução de uma montagem específica do diretório acelera as chamadas de lista e reduz o número geral de chamadas de lista e estatísticas, limitando o número de diretórios a serem percorridos ao resolver um nome de arquivo, porque as chamadas LookUpInode e as solicitações de acesso a buckets ou diretórios geram automaticamente chamadas de lista e estatísticas para cada arquivo ou diretório no caminho.

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

volumeHandle: BUCKET_NAME



only-dir:DIRECTORY_NAME

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

Para mais informações sobre como fazer uma montagem de diretório, consulte Montar um diretório em um bucket.

Aumentar valores de cache de metadados

Para melhorar o desempenho de leituras repetidas, configure o Cloud Storage FUSE para armazenar em cache uma grande quantidade de metadados e ignorar o vencimento deles. Isso evita solicitações repetidas de metadados ao Cloud Storage e melhora significativamente o desempenho.

Aumentar os valores do cache de metadados é benéfico para cargas de trabalho com leituras repetidas para evitar chamadas repetitivas do Cloud Storage e para volumes somente leitura em que um TTL infinito pode ser definido.

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

• Um time to live (TTL) infinito só deve ser definido para volumes que são somente leitura ou somente gravação em novos.

• O cache de metadados só deve ser ativado para aumentar significativamente de tamanho em nós com configurações de memória grandes, porque ele 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 seção armazenam em cache todos os metadados acessados com um TTL infinito, o que pode afetar as garantias de consistência quando as mudanças são feitas no mesmo bucket do Cloud Storage por qualquer outro cliente, por exemplo, substituições ou exclusões de um arquivo.

• Para verificar se o consumo de memória não foi afetado, valide se a quantidade de memória consumida pelo cache de metadados é aceitável para você. Ela pode chegar a gigabytes e depende do número de arquivos nos buckets montados e de quantos pontos de montagem estão sendo usados. Por exemplo, os metadados de cada arquivo ocupam aproximadamente 1,5 KiB de memória, e os metadados de um milhão de arquivos ocupam aproximadamente 1,5 GiB. Para mais informações, consulte Visão geral do armazenamento em cache.

Siga estas instruções para configurar o Cloud Storage FUSE e armazenar em cache uma grande quantidade de metadados e ignorar o vencimento deles:

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

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

Pré-preencher o cache de metadados

Antes de executar uma carga de trabalho, recomendamos pré-preencher o cache de metadados, o que melhora significativamente o desempenho e reduz substancialmente o número de chamadas de metadados para o Cloud Storage, principalmente se a opção de configuração implicit-dirs for usada. O driver CSI do Cloud Storage FUSE para GKE fornece uma API que processa o pré-preenchimento do cache de metadados. Consulte Usar a pré-busca de metadados para pré-preencher o cache de metadados.

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

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

ls -R MOUNT_POINT > /dev/null

ls -R MOUNT_POINT > /dev/null

Ativar o armazenamento em cache de arquivos e os downloads paralelos

O armazenamento em cache de arquivos permite armazenar dados de arquivos acessados com frequência localmente na sua máquina, acelerando as leituras repetidas e reduzindo os custos do Cloud Storage. Quando você ativa o armazenamento em cache de arquivos, os downloads paralelos também são ativados automaticamente. Os downloads paralelos usam vários workers para baixar um arquivo em paralelo usando o diretório de cache de arquivos como um buffer de pré-busca, resultando em um tempo de carregamento do modelo nove vezes mais rápido.

Para saber como ativar e configurar o armazenamento em cache de arquivos e os downloads paralelos, consulte Ativar e configurar o comportamento do armazenamento em cache de arquivos. Para usar uma configuração de exemplo, consulte Exemplo de configuração para ativar o armazenamento em cache de arquivos e downloads paralelos.

Considerações sobre GPUs e Cloud TPU para usar o cache de arquivos e downloads paralelos

O cache de arquivos pode ser hospedado em SSDs locais, RAM, Persistent Disk ou Google Cloud Hyperdisk com as seguintes orientações. Em todos os casos, os dados ou arquivos grandes individuais precisam caber na capacidade disponível do diretório de cache de arquivos, que é controlada usando a configuração max-size-mb.

Considerações sobre as GPUs do Cloud

Os SSDs locais são ideais para dados de treinamento e downloads de pontos de verificação. Os tipos de máquina das GPUs do Cloud incluem capacidade de SSD que pode ser usada, como os tipos de máquina A4, que incluem 12 TiBs de SSD.

• Um disco RAM oferece o melhor desempenho para carregar pesos de modelo devido ao 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 um cache.

Considerações sobre a Cloud TPU

A Cloud TPU não são compatíveis com SSDs locais. Se você usar o cache de arquivos na Cloud TPU sem modificação, o local padrão usado será o volume de inicialização, o que não é recomendado e resulta em desempenho ruim.

Em vez do volume de inicialização, recomendamos usar um disco RAM, que é preferível pelo desempenho e por não ter custo incremental. No entanto, um disco RAM geralmente tem tamanho limitado e é mais útil para disponibilizar pesos de modelo ou downloads de pontos de verificação, dependendo do tamanho do ponto de verificação e da RAM disponível. Além disso, recomendamos o uso do Persistent Disk e do Google Cloud Hyperdisk para fins de caching.

Exemplo de configuração para ativar o armazenamento em cache de arquivos e downloads paralelos

Por padrão, o cache de arquivos usa um SSD local se o modo ephemeral-storage-local-ssd estiver ativado para o nó do Google Kubernetes Engine. Se nenhum SSD local estiver disponível, por exemplo, em máquinas da Cloud TPU, o cache de arquivos usará o disco de inicialização do nó do Google Kubernetes Engine, o que não é recomendado. Nesse caso, você pode usar um disco RAM como diretório de cache, mas considere a quantidade de RAM disponível para o cache de arquivos em comparação com o que é necessário para o 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

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

Desativar entradas negativas de cache de estatísticas

Por padrão, o Cloud Storage FUSE armazena em cache entradas de estatísticas negativas, ou seja, entradas de arquivos que não existem, com um TTL de cinco segundos. Em workloads em que os arquivos são criados ou excluídos com frequência, como checkpointing distribuído, essas entradas em cache podem ficar desatualizadas rapidamente, o que causa problemas de desempenho. Para evitar isso, recomendamos desativar o cache de estatísticas negativas para treinamento, veiculação e cargas de trabalho de checkpoint usando a opção de configuração negative-ttl-secs.

Use as instruções a seguir para desativar o cache de estatísticas negativas:

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

metadata-cache:
 negative-ttl-secs: 0

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

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

Ativar gravações de streaming

As gravações de streaming fazem upload de dados diretamente para o Cloud Storage à medida que são gravados, o que reduz a latência e o uso de espaço em disco. Isso é especialmente útil para gravações grandes e sequenciais, como pontos de verificação. As gravações de streaming são ativadas por padrão no Cloud Storage FUSE versão 3.0 e mais recentes.

Se as gravações de streaming não estiverem ativadas por padrão, siga estas instruções para ativá-las. Para ativar gravações de streaming, é necessário o Cloud Storage FUSE versão 3.0, que está disponível no Google Kubernetes Engine versões 1.32.1-gke.1729000 ou mais recentes.

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

write:
 enable-streaming-writes: true

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

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

Aumentar o tamanho de leitura antecipada do kernel

Para cargas de trabalho que envolvem principalmente leituras sequenciais de arquivos grandes, como veiculação e restaurações de pontos de controle, aumentar o tamanho da leitura antecipada pode melhorar significativamente o desempenho. Isso pode ser feito usando o parâmetro do kernel do Linux read_ahead_kb na máquina local. Recomendamos aumentar o parâmetro do kernel read_ahead_kb para 1 MB em vez de usar o valor padrão de 128 KB definido na maioria das distribuições Linux. Para instâncias do Compute Engine, as permissões sudo ou root são necessárias para aumentar o parâmetro do kernel.

Para aumentar o parâmetro do kernel read_ahead_kb para 1 MB em um diretório montado específico do Cloud Storage FUSE, use as instruções a seguir. Seu bucket precisa ser montado no Cloud Storage FUSE antes de executar o comando. Caso contrário, o parâmetro do kernel não vai aumentar.

mountOptions:



read_ahead_kb=1024

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

Desativar o Security Token Service para evitar verificações redundantes

O driver CSI do Cloud Storage FUSE para o Google Kubernetes Engine tem verificações de acesso para garantir a capacidade de recuperação do pod devido à configuração incorreta pelo usuário das vinculações de identidade da carga de trabalho entre o bucket e a conta de serviço do GKE, o que pode atingir as cotas padrão da API Security Token Service em grande escala. Isso pode ser desativado definindo o atributo de volume skipCSIBucketAccessCheck do driver CSI de volume permanente. Recomendamos que você verifique se a conta de serviço do GKE tem o acesso correto ao bucket de destino do Cloud Storage para evitar falhas de montagem do pod.

Além disso, a cota do Security Token Service precisa ser aumentada além do valor padrão de 6000 se um cluster do Google Kubernetes Engine tiver mais de 6.000 nós, o que pode resultar em erros de 429 se não for aumentada em implantações de grande escala. A cota do Security Token Service precisa ser aumentada na página "Cotas e limites". Recomendamos que você mantenha a cota igual ao número de montagens. Por exemplo, se houver 10.000 montagens no cluster, a cota deverá ser aumentada para 10000.

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

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"
   

Outras considerações sobre performance

Além das otimizações principais discutidas, vários outros fatores podem afetar significativamente o desempenho geral do Cloud Storage FUSE. As seções a seguir descrevem outras considerações de desempenho que recomendamos ao usar o Cloud Storage FUSE.

Aumentar o limite de renomeação para buckets que não são do HNS

As cargas de trabalho de checkpointing sempre devem ser feitas com um bucket que tenha namespace hierárquico ativado devido a renomeações atômicas e mais rápidas e QPS mais altas para leituras e gravações. No entanto, se você aceitar o risco de renomeações de diretórios não serem atômicas e levarem mais tempo, use a opção de configuração rename-dir-limit se estiver fazendo checkpointing usando buckets sem namespace hierárquico para especificar um limite no número de arquivos ou operações envolvidas em uma operação de renomeação de diretório a qualquer momento.

Recomendamos definir a opção de configuração rename-dir-limit com um valor alto para evitar falhas de checkpoint. Como o Cloud Storage FUSE usa um namespace simples e os objetos são imutáveis, uma operação de renomeação de diretório envolve renomear e excluir todos os arquivos individuais dentro do diretório. É possível controlar o número de arquivos afetados por uma operação de renomeação definindo a opção de configuração rename-dir-limit.

Use as instruções a seguir para definir a opção de configuração rename-dir-limit:

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

file-system:
 rename-dir-limit: 200000

mountOptions:
    - rename-dir-limit=200000

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

Armazenamento em cache da lista de kernels

O cache de lista é um cache para diretórios e listas de arquivos, ou respostas ls, que melhora a velocidade das operações de lista. Ao contrário dos caches de estatísticas e de tipos, que são gerenciados pelo Cloud Storage FUSE, o cache de lista é mantido no cache de página do kernel e é controlado pelo kernel com base na disponibilidade de memória.

Ativar o cache da lista de kernel é mais benéfico para os seguintes casos de uso:

• Cargas de trabalho com listagens de diretórios repetidas: essa configuração é especialmente útil para cargas de trabalho que realizam listagens completas de diretórios com frequência, como execuções de treinamento de IA/ML. Isso pode beneficiar as cargas de trabalho de disponibilização e treinamento.

• Montagens somente leitura: o cache de lista é recomendado com montagens somente leitura para evitar problemas de consistência.

A ativação do cache da lista de kernel deve ser feita com cuidado e usada somente se o sistema de arquivos for realmente somente leitura, sem alterações esperadas no conteúdo do diretório durante a execução de um job. Isso acontece porque, com essa flag, o aplicativo local nunca vê 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 no cache de lista do kernel. O cliente 2 cria fileB em directoryA no bucket do Cloud Storage. O cliente 1 verifica continuamente se há fileB em directoryA, que é essencialmente verificar a entrada do cache da lista do kernel e nunca acessar a rede. O cliente 1 não vê que um novo arquivo está no diretório porque a lista de arquivos é fornecida continuamente do cache de lista do kernel local. Cliente 1 atinge o tempo limite, e o programa é interrompido.

Use a instrução a seguir para ativar o armazenamento em cache de listas:

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

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

Ao usar 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 no cache de páginas do kernel.

• Um valor de -1 ignora a expiração da entrada e retorna a resposta da lista do cache quando ela está disponível.

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

O JAX oferece suporte ao cache Just-In-Time (JIT), um cache de compilação persistente opcional que armazena artefatos de função compilados. Ao usar esse cache, você pode acelerar significativamente as execuções de script subsequentes, evitando etapas de compilação redundantes.

Para ativar o cache JIT, é necessário atender aos seguintes requisitos:

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

• Maximize a capacidade do cache: para evitar a degradação da performance devido à remoção do cache, defina um tamanho ilimitado, principalmente se quiser substituir as configurações padrão. Para fazer isso, defina a variável de ambiente:

  export JAX_COMPILATION_CACHE_MAX_SIZE=-1
  

• Verifique o YAML do pod de checkpoint: use a configuração de checkpoint para o ponto de montagem do cache JIT do JAX.

A seguir

• Use um arquivo YAML de amostra do Google Kubernetes Engine para configurar as práticas recomendadas de ajuste.

• Saiba mais sobre as opções do arquivo de configuração do Cloud Storage FUSE.

• Saiba mais sobre as opções da CLI do Cloud Storage FUSE.