Práticas recomendadas de cache do sistema de arquivos do Linux para o Azure NetApp Files

Artigo
10/16/2024

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

Ajustáveis de cache do sistema de arquivos

Você precisa entender os seguintes fatores sobre os ajustáveis de cache do sistema de arquivos:

A liberação de um buffer sujo deixa os dados em um estado limpo para leituras futuras até que a pressão de memória leve à remoção.
Há três gatilhos para uma operação de liberação assíncrona:
- Com base em tempo: quando um buffer atinge a idade definida por esse ajustável, ele deve ser marcado para limpeza (ou seja, liberação ou gravação no armazenamento).
- Pressão de memória: consulte vm.dirty_ratio | vm.dirty_bytes para obter detalhes.
- Fechamento: quando um identificador de arquivo é fechado, todos os buffers sujos são liberados de forma assíncrona para o armazenamento.

Esses fatores são controlados por quatro ajustáveis. Cada ajustável pode ser ajustado de maneira 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 reveladas durante os exercícios de validação do SAS GRID e do SAS Viya. Por consequência, os ajustáveis se baseiam nas lições aprendidas com os exercícios de validação. Muitos aplicativos se beneficiam do ajuste desses parâmetros de maneira similar.

`vm.dirty_ratio | vm.dirty_bytes`

Esses dois ajustáveis definem a quantidade de RAM que se tornou utilizável para dados modificados, mas ainda não foi gravada no armazenamento estável. Qualquer ajustável que for definido também define automaticamente o outro ajustável para zero; a RedHat aconselha a não definir manualmente nenhum dos dois ajustáveis como zero. A opção vm.dirty_ratio (o padrão entre as duas) é definida pelo Redhat como 20% ou 30% da memória física a depender do sistema operacional, o que é uma quantidade significativa considerando o volume de memória dos sistemas modernos. Deve-se considerar a configuração 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 contínuo com SAS GRID determinou 30 MiB como sendo uma configuração apropriada para o melhor desempenho geral de carga de trabalho misturada.

`vm.dirty_background_ratio | vm.dirty_background_bytes`

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

`vm.dirty_expire_centisecs`

Esse ajustável define a idade de um buffer sujo antes de ser marcado para ser gravado de modo assíncrono. Use como exemplo a carga de trabalho de CAS do SAS Viya. Uma carga de trabalho efêmera dominante de gravação descobriu que definir esse valor como 300 centissegundos (3 segundos) foi o ideal, com o padrão sendo de 3000 centissegundos (30 segundos).

O SAS Viya compartilha dados CAS em várias partes pequenas de alguns megabytes cada. Em vez de fechar esses identificadores de arquivo depois de escrever dados em cada fragmento, os identificadores são deixados abertos e os buffers em seu interior são mapeados na memória pelo aplicativo. Sem um fechamento, não há liberação até que ocorra uma pressão de memória ou 30 segundos se passem. Aguardar a pressão de memória se mostrou longe do ideal, assim como esperar que um temporizador de longa duração expire. Ao contrário do SAS GRID, que buscava a melhor taxa de transferência geral, o SAS Viya buscava otimizar a largura de banda de gravação.

`vm.dirty_writeback_centisecs`

O thread de liberação do kernel é responsável por liberar buffers sujos de forma assíncrona entre cada thread de liberação. Esse ajustável define a quantidade gasta na suspensão entre as liberações. Considerando o valor de 3 segundos vm.dirty_expire_centisecs usado pelo SAS Viya, a SAS definiu esse ajustável como 100 centissegundos (1 segundo) em vez do padrão de 500 centissegundos (5 segundos) para encontrar o melhor desempenho geral.

Impacto de um cache do sistema de arquivos não ajustado

Ao considerar os ajustáveis de memória virtual padrão e a quantidade de RAM em sistemas modernos, o write-back reduz potencialmente a velocidade de outras operações vinculadas ao armazenamento da perspectiva do cliente específico que está impulsionando essa carga de trabalho mista. Os sintomas a seguir podem ser esperados de um computador Linux sem ajuste, com alta carga de gravação e uso intenso de cache.

As listas de diretórios ls demoram o suficiente para parecer sem resposta.
A taxa de transferência de leitura no sistema de arquivos diminui significativamente em comparação com a taxa de transferência de gravação.
Os relatórios nfsiostat escrevem latências em segundos ou unidades de tempo maiores.

Você pode experimentar esse comportamento somente pelo computador Linux executando a carga de trabalho de gravação intensa de forma mista. Além disso, a experiência é degradada em relação a todos os volumes NFS montados em um único ponto de extremidade de armazenamento. Se as montagens vêm de dois ou mais pontos de extremidade, somente os volumes que compartilham um ponto de extremidade apresentam esse comportamento.

Mostrou-se que a definição dos parâmetros de cache do sistema de arquivos, conforme descrito nesta seção, é capaz de resolver os problemas.

Monitoramento de máquina virtual

Para entender o que está acontecendo com a memória virtual e o write-back, considere o snippet de código e a saída a seguir. Sujo representa a quantidade de memória suja no sistema, e write-back representa a quantidade de memória 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 em que as taxas vm.dirty_ratio e vm.dirty_background foram definidas como 2% e 1% da memória física, respectivamente. Nesse caso, a liberação começou em 3.8 GiB, 1% do sistema de memória de 384 GiB. O write-back se assemelhou muito à taxa de transferência de gravação no 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

Compartilhar via