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 os dados na extremidade remota 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. Dessa forma, o acesso subsequente ocorre diretamente desse disco, o que 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 exclusivamente para cache de leitura e não afeta o caminho de escrita. As operações de escrita não passam pelo cache local. Isso difere da opção -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 busca os dados no 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 utiliza um único arquivo de cache como menor unidade.

Métodos de configuração

Item de configuração	Obrigatório	Descrição	Valor padrão
disk_data_cache_dir	Sim	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	Sim	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.	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 ou disco independente.
O valor de --disk_data_cache_size não pode ultrapassar 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, cada instância deve utilizar um diretório de cache independente.
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 verificados.
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 o volume 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 em nuvem 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, recomendamos --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, mas o desempenho ficará limitado por ele. Nesse caso, 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.8 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 6 GB/s, largura de banda de escrita 3 GB/s, IOPS 900.000)
ossfs 2.0: --disk_data_cache_dir=<path> --disk_data_cache_size=3T
ossfs 1.0: -ouse_cache=<path> -oparallel_count=128

Resultados

Configuração	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	2206 / 5947 MB/s	244% / 349%	2081 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,2 vezes o desempenho do ossfs 1.0 (modo libaio: 5947 vs 2648 MB/s), atingindo o teto de desempenho do NVMe local. Ao mesmo tempo, o uso de CPU é significativamente reduzido (≈250% 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	329 / 895 MB/s (cerca de 7100 img/s)	116% / 1216%	6802 MB
ossfs 1.0	38 / 224 MB/s (cerca de 2000 img/s)	66,1% / 206%	31,6 GB

Conclusão:

Após a ativação do cache de disco e do cache de metadados, o desempenho de carregamento do ossfs 2.0 nas épocas subsequentes atinge 2,7 vezes o da primeira leitura (895 vs 329 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 (mecanismo libaio) + cache de metadados.