Configuração e desempenho do cache de dados local do ossfs 2.0 - Object Storage Service: Central de Documentação do Alibaba Cloud

Informações gerais

Ao usar o ossfs 2.0 para acessar o OSS, é necessário buscar dados remotamente sempre que um arquivo for lido. Em cenários que exigem múltiplas rodadas de leitura repetida dos mesmos dados, como treinamento de IA e carregamento de modelos, o acesso remoto frequente resulta em alta latência de rede e consumo elevado de largura de banda.

O cache de dados local do ossfs 2.0 retém os dados de arquivos lidos previamente em um disco local, permitindo atender acessos subsequentes diretamente desse disco. Isso melhora significativamente o desempenho de leituras repetidas e reduz os custos com requisições ao OSS.

O cache de dados local do ossfs 2.0 possui os seguintes recursos:

Melhor desempenho: Em cenários de leitura repetida, tanto para arquivos grandes quanto pequenos, a largura de banda é significativamente superior à do ossfs 1.0. Para mais informações, consulte a comparação de desempenho abaixo.
Evicção automática: Uma política de evicção LRU integrada recupera automaticamente os arquivos acessados menos recentemente quando o cache está cheio, eliminando a necessidade de limpeza manual.
Suporte a grande volume de arquivos pequenos: Quando utilizado em conjunto com o cache de metadados (--max_inode_cache_count e --attr_timeout), acelera consideravelmente o carregamento em múltiplas rodadas de conjuntos de dados para treinamento de IA.

Nota

O cache de dados local serve apenas para cache de leitura e não afeta o caminho de escrita. Operações de escrita não passam pelo cache local. Isso difere do parâmetro -ouse_cache do ossfs 1.0, que armazena em cache tanto dados de leitura quanto de escrita.

Princípios de funcionamento

Granularidade do cache

O cache utiliza objetos do OSS (arquivos) como unidade básica. Cada arquivo lido corresponde a um arquivo de cache no diretório de cache, e o preenchimento ocorre sob demanda.

Processo de leitura

Primeira leitura: O sistema obtém os dados do OSS e os grava sincronousmente no diretório de cache local.
Leituras subsequentes: A leitura dos dados ocorre diretamente do cache local.

Recuperação de espaço

Quando o cache se aproxima do limite de capacidade, o sistema remove automaticamente arquivos antigos com base na política LRU (menos recentemente usado) para liberar espaço para novos dados. A recuperação tem como menor unidade um único arquivo de cache.

Métodos de configuração

Item de configuração	Obrigatório	Descrição	Valor padrão
disk_data_cache_dir	Não	Caminho do diretório de cache local. O cache de dados é ativado quando este item recebe um valor não vazio.	Vazio
disk_data_cache_size	Condicionalmente obrigatório	Capacidade máxima do cache, alinhada a GiB. Não pode exceder o espaço disponível no disco ou partição onde reside o diretório de cache. O parâmetro disk_data_cache_dir pode permanecer vazio. Caso disk_data_cache_dir seja especificado, defina um valor válido para este parâmetro.	Vazio
disk_data_cache_io_engine	Não	Mecanismo de IO para o cache de disco. Valores válidos: psync e libaio.	psync

Restrições:

O diretório apontado por --disk_data_cache_dir deve existir e estar vazio. Recomendamos garantir que o caminho do cache resida em uma partição independente ou em um disco dedicado.
O valor de --disk_data_cache_size não pode exceder o espaço disponível no disco onde o diretório de cache está localizado.
Ao montar várias instâncias do ossfs2 na mesma máquina, utilize um diretório de cache independente para cada instância.
Quando o processo do ossfs2 é encerrado, o diretório de cache não é limpo automaticamente; limpe-o manualmente.
Após a montagem, evite realizar operações no caminho do diretório de cache para prevenir erros desconhecidos.

Exemplo de comando de montagem:

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

Requisitos de ambiente

Parâmetro	Requisito
Sistema de arquivos do disco de cache	ext4, xfs ou tmpfs (apenas modo psync). Outros sistemas de arquivos não foram validados.
Tipo de disco de cache	Recomenda-se disco efêmero elástico ou NVMe local. O throughput de ESSD PL0/PL1/PL2 pode facilmente se tornar um gargalo, resultando em uma experiência ruim. Quando houver memória suficiente, é possível usar tmpfs (apenas psync).
Espaço disponível no disco de cache	Não inferior ao valor definido em --disk_data_cache_size

Recomendações de uso

O cache de dados local é adequado para cenários com muitas leituras e poucas escritas, que exigem acesso repetido aos mesmos dados.

Recomendações para configurar o mecanismo de IO (disk_data_cache_io_engine):

psync: Utiliza chamadas de sistema de leitura/escrita síncronas, e os dados passam pelo PageCache do sistema operacional durante as leituras. Quando a quantidade de dados em cache se aproxima ou é menor que a memória disponível, os dados quentes residem naturalmente no PageCache, atingindo velocidades de leitura próximas às da memória. Indicado para cenários de uso geral, discos cloud de baixa especificação e discos de cache tmpfs (tmpfs não suporta libaio).
libaio: Usa a interface de IO assíncrona do Linux e ignora o PageCache para operar o disco diretamente. Ideal para cenários com NVMe local de grande capacidade e conjuntos de dados muito maiores que a memória, oferecendo geralmente uma melhoria de desempenho adicional de cerca de 20% em comparação ao psync.

A tabela a seguir lista cenários típicos e configurações recomendadas:

Cenário	Recomendação de uso
Carregamento de dados de treinamento de IA em múltiplas rodadas (acesso repetido ao mesmo conjunto de dados em várias épocas) ou múltiplas consultas/análises de um conjunto de dados fixo	Ative o cache de dados local e defina --disk_data_cache_size como o tamanho do conjunto de dados × 1,1. Se o disco de cache for NVMe local e o volume de dados for grande, recomenda-se --disk_data_cache_io_engine=libaio para aproveitar totalmente o desempenho do disco.
Inferência de modelos grandes / carregamento vLLM (carregamento repetido de arquivos de modelo na escala de GB)	Se a memória do tipo de instância recomendado for maior que o tamanho total do modelo, use um disco tmpfs como disco de cache. Caso a memória seja insuficiente para armazenar completamente os arquivos do modelo em cache, também é possível usar um disco local como disco de cache, mas o desempenho ficará limitado pelo disco. Nessa situação, faça uma avaliação específica antes de decidir se deve ativar o cache de dados local.

Importante

Em cenários com altos requisitos de atualidade dos dados e onde há modificações frequentes, não recomendamos ativar o cache de dados (o cache apresenta um certo grau de diferença de atualidade).

Comparação de desempenho

Alvos do teste: ossfs 2.0.9 vs ossfs 1.91.10. Na tabela, "primeira leitura / leitura subsequente" correspondem, respectivamente, a uma falha de cache (os dados precisam ser buscados no OSS) e a um acerto no cache local. "—" indica que a configuração não possui cache e não distingue entre primeira leitura e leituras subsequentes.

Cenário 1: Leitura sequencial de arquivos grandes (4 threads lendo um arquivo de 100 GB)

Ambiente de teste

Máquina: ecs.i4.4xlarge (16 vCPUs, 128 GiB)
Disco NVMe local: 3576 GiB NVMe (largura de banda de leitura de 6 GB/s, largura de banda de escrita de 3 GB/s, IOPS 900.000)
ossfs 2.0: --disk_data_cache_dir=<path> --disk_data_cache_size=3T, testado separadamente com --disk_data_cache_io_engine=psync e libaio
ossfs 1.0: -ouse_cache=<path> -oparallel_count=128

Resultados

Configuração	Modo de IO	Largura de banda (primeira leitura / leitura subsequente)	CPU (méd/máx)	Pico de memória
ossfs 2.0 (sem cache)	-	2841 MB/s —	385% / 468%	5170 MB
ossfs 2.0	psync	2561 / 4516 MB/s	371% / 526%	2118 MB
ossfs 2.0	libaio	2343 / 6625 MB/s	298% / 322%	2146 MB
ossfs 1.0	-	1249 / 2648 MB/s	815% / 1214%	137 MB

Conclusão:

Com o cache ativado, no cenário de leitura subsequente de arquivos grandes, o ossfs 2.0 entrega cerca de 2,5 vezes o desempenho do ossfs 1.0 (modo libaio: 6625 vs 2648 MB/s), atingindo o teto de desempenho do NVMe local. Simultaneamente, o uso de CPU é reduzido significativamente (≈300% vs 800%).

Cenário 2: Leitura de grande volume de arquivos pequenos (carregamento do conjunto de dados de treinamento ImageNet)

Ambiente de teste

Máquina: ecs.i4.32xlarge (128 vCPUs, 1024 GiB)
Discos NVMe locais: 8 × 3576 GiB NVMe
Conjunto de dados: Conjunto de treinamento ImageNet (cerca de 1,3 milhão de imagens), carregado repetidamente em múltiplas épocas
ossfs 2.0: --disk_data_cache_dir=<path> --disk_data_cache_size=1500G --disk_data_cache_io_engine=libaio --attr_timeout=36000 --max_inode_cache_count=11000000 (cache de metadados ativado)
ossfs 1.0: -ouse_cache=<path> -oreaddir_optimize -omax_stat_cache_size=11000000 -ostat_cache_expire=72000

Resultados

Configuração	Largura de banda (primeira leitura / leitura subsequente)	CPU (méd/máx)	Pico de memória
ossfs 2.0 (sem cache)	304 MB/s — (cerca de 2400 img/s)	67% / 209%	5062 MB
ossfs 2.0	286 / 1292 MB/s (cerca de 10000 img/s)	219% / 1068%	6470 MB
ossfs 1.0	38 / 224 MB/s (cerca de 2000 img/s)	66,1% / 206%	31,6 GB

Conclusão:

Após ativar o cache de disco e o cache de metadados, o desempenho de carregamento do ossfs 2.0 nas épocas subsequentes atinge 4,25 vezes o desempenho sem cache de disco (1292 vs 304 MB/s), e as requisições de rede ao OSS são completamente eliminadas. Para cargas de trabalho de treinamento de IA que carregam repetidamente o mesmo conjunto de dados em várias rodadas, recomendamos fortemente o cache de dados local do ossfs 2.0 + libaio.