Partilhar via

Práticas recomendadas de cache de sistema de ficheiros Linux para Azure NetApp Files

Este artigo ajuda você a entender as práticas recomendadas de cache do sistema de arquivos para Arquivos NetApp do Azure.

Configurações de cache do sistema de arquivos

Você precisa entender os seguintes aspectos sobre os parâmetros ajustáveis de cache do sistema de arquivos.

  • Liberar um buffer sujo deixa os dados em um estado limpo utilizável para leituras futuras até que a pressão da memória leve à remoção.
  • Há três gatilhos para uma operação de descarga assíncrona:
    • Baseado no tempo: Quando um buffer atinge a idade definida por este ajuste, deve ser marcado para eliminação (ou seja, apagamento ou gravação no armazenamento).
    • Pressão da memória: Consulte vm.dirty_ratio | vm.dirty_bytes para obter detalhes.
    • Fechar: Quando um identificador de arquivo é fechado, todos os buffers sujos são liberados de forma assíncrona para o armazenamento.

Estes fatores são controlados por quatro parâmetros de ajuste. É possível ajustar cada parâmetro de forma dinâmica e persistente usando tuned ou sysctl no arquivo /etc/sysctl.conf. O ajuste dessas variáveis melhora o desempenho dos aplicativos.

Observação

As informações discutidas neste artigo foram descobertas durante os exercícios de validação SAS GRID e SAS Viya. Como tal, os parâmetros ajustáveis baseiam-se nas lições aprendidas com os exercícios de validação. Muitos aplicativos também se beneficiam do ajuste desses parâmetros.

vm.dirty_ratio | vm.dirty_bytes

Estes dois ajustes definem a quantidade de RAM disponibilizada para dados modificados, mas ainda não gravados em armazenamento estável. Sempre que um sintonizável é ajustado automaticamente, o outro é definido como zero; a RedHat desaconselha ajustar manualmente qualquer um dos dois sintonizáveis para zero. A opção vm.dirty_ratio (o padrão dos dois) é definida pela Red Hat para 20% ou 30% de memória física, dependendo do sistema operacional, o que é uma quantidade significativa considerando a pegada de memória dos sistemas modernos. Deve-se considerar definir vm.dirty_bytes em vez de vm.dirty_ratio para uma experiência mais consistente, independentemente do tamanho da memória. Por exemplo, o trabalho em curso com o SAS GRID determinou 30 MiB, uma configuração apropriada para o melhor desempenho geral da carga de trabalho mista.

vm.dirty_background_ratio | vm.dirty_background_bytes

Esses ajustáveis definem o ponto de partida onde o mecanismo de write-back do Linux começa a liberar blocos sujos para um armazenamento estável. O padrão da Red Hat é de 10% de memória física, o que, em um sistema de memória grande, é uma quantidade significativa de dados para iniciar a liberação. Com SAS GRID como exemplo, historicamente a recomendação era definir vm.dirty_background para 1/5 tamanho de vm.dirty_ratio ou vm.dirty_bytes. Considerando a agressividade com que a vm.dirty_bytes configuração é definida para SAS GRID, nenhum valor específico está sendo definido aqui.

vm.dirty_expire_centisecs

Esse parâmetro define quão antigo um buffer sujo pode ser antes que deva ser marcado para gravação assíncrona. Tomemos como exemplo a carga de trabalho do SAS Viya no CAS. Uma carga de trabalho efémera com predominância de operações de gravação revelou que a definição deste valor para 300 centisegundos (3 segundos) era o ideal, sendo 3000 centisegundos (30 segundos) o padrão.

O SAS Viya compartilha dados CAS em vários pequenos blocos de alguns megabytes cada. Em vez de fechar os descritores de ficheiro após gravar dados em cada partição, os descritores permanecem abertos e os buffers são mapeados na memória pelo aplicativo. Sem um fechamento, não há liberação até que ocorra pressão de memória ou passem 30 segundos. Esperar pela pressão da memória demonstrou ser subótimo, assim como esperar até que um longo timer expire. Ao contrário do SAS GRID, que procurava a melhor taxa de transferência geral, o SAS Viya procurava otimizar a largura de banda de escrita.

vm.dirty_writeback_centisecs

O thread de limpeza do kernel é responsável por esvaziar de forma assíncrona os buffers sujos enquanto o thread de flush está suspenso. Este ajuste define o tempo gasto a dormir entre limpezas. Considerando o valor de 3 segundos vm.dirty_expire_centisecs usado pelo SAS Viya, o SAS definiu esse ajuste para 100 centisegundos (1 segundo) em vez do padrão de 500 centisegundos (5 segundos) para encontrar o melhor desempenho geral.

Impacto de um cache de sistema de arquivos não otimizado

Quando se consideram os parâmetros ajustáveis de memória virtual padrão e a quantidade de RAM em sistemas modernos, a operação de write-back pode potencialmente atrasar outras operações dependentes de armazenamento do ponto de vista do cliente específico que conduz essa carga de trabalho mista. Os seguintes sintomas podem ser esperados de uma máquina Linux desajustada, com muitas gravações e carregada de cache.

  • As listas de diretórios ls demoram tanto que parecem não responder.
  • A taxa de transferência de leitura em relação ao sistema de arquivos diminui significativamente em comparação com a taxa de transferência de gravação.
  • nfsiostat Os relatórios indicam latências em segundos ou mais elevadas.

Pode experimentar este comportamento apenas quando a máquina Linux está a executar uma carga de trabalho pesada de gravação mista. Além disso, a experiência é degradada em relação a todos os volumes NFS montados num único ponto de acesso de armazenamento. Se as montagens vierem de dois ou mais pontos de extremidade, somente os volumes que compartilham um ponto de extremidade exibirão esse comportamento.

A definição dos parâmetros de cache do sistema de arquivos, conforme descrito nesta seção, mostrou resolver os problemas.

Monitorando a memória virtual

Para entender o que se passa com a memória virtual e o write-back, considere o seguinte trecho de código e a saída correspondente. Sujo representa a quantidade de memória suja no sistema e write-back representa a quantidade de memória que está sendo gravada ativamente no armazenamento.

# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done`

A saída a seguir vem de um experimento onde a razão entre o vm.dirty_ratio e o vm.dirty_background foi definida como 2% e 1% de memória física, respectivamente. Neste caso, o descarregamento começou em 3,8 GiB, 1% do sistema de memória de 384 GiB. O writeback assemelhava-se muito à taxa de transferência de gravação para NFS.

Cons
Dirty:                                    1174836 kB
Writeback:                         4 kB
###
Dirty:                                    3319540 kB
Writeback:                         4 kB
###
Dirty:                                    3902916 kB        <-- Writes to stable storage begins here
Writeback:                         72232 kB   
###
Dirty:                                    3131480 kB
Writeback:                         1298772 kB

Próximos passos

  • Last updated on