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

Artigo
09/02/2024

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

Sintonizáveis de cache do sistema de arquivos

Você precisa entender os seguintes fatores sobre os sintonizá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 tampão atinge a idade definida por este sintonizável, ele deve ser marcado para limpeza (ou seja, lavagem 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 sintonizáveis. Cada ajuste pode ser ajustado dinamicamente e persistentemente usando tuned ou sysctl no /etc/sysctl.conf arquivo. O ajuste dessas variáveis melhora o desempenho dos aplicativos.

Nota

As informações discutidas neste artigo foram descobertas durante os exercícios de validação SAS GRID e SAS Viya. Como tal, os sintonizá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 sintonizáveis definem a quantidade de RAM tornada utilizável para dados modificados, mas ainda não gravados em armazenamento estável. Qualquer ajuste definido automaticamente define o outro ajustável como zero; A RedHat desaconselha a configuração manual de qualquer um dos dois sintonizáveis para zero. A opção vm.dirty_ratio (o padrão dos dois) é definida pela Redhat 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 a configuração vm.dirty_bytes em vez de vm.dirty_ratio 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 Redhat tem como padrão 10% da 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 ajuste define a idade que um buffer sujo pode ter antes de ser marcado para gravação assíncrona. Tomemos como exemplo a carga de trabalho CAS do SAS Viya. Uma carga de trabalho efêmera dominante de gravação descobriu que definir esse valor para 300 centisegundos (3 segundos) era o ideal, com 3000 centisegundos (30 segundos) sendo o padrão.

O SAS Viya compartilha dados CAS em vários pequenos blocos de alguns megabytes cada. Em vez de fechar essas alças de arquivo depois de gravar dados em cada fragmento, as alças são deixadas abertas e os buffers dentro são mapeados pela memória pelo aplicativo. Sem um fechamento, não há flush até a passagem da pressão da memória ou 30 segundos. Esperar pela pressão da memória mostrou-se subótimo, assim como esperar por um longo temporizador para expirar. 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 do flusher do kernel é responsável por liberar de forma assíncrona buffers sujos entre cada suspensão do flush thread. Este ajuste define a quantidade gasta dormindo entre rubores. 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 ajustado

Quando você considera os sintonizáveis de memória virtual padrão e a quantidade de RAM em sistemas modernos, o write-back potencialmente retarda outras operações ligadas ao armazenamento da perspetiva do cliente específico que conduz essa carga de trabalho mista. Os sintomas a seguir podem ser esperados de uma máquina Linux desajustada, pesada em gravação e carregada de cache.

As listas de diretórios ls demoram o suficiente para parecerem sem resposta.
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 gravam latências em segundos ou mais.

Você pode enfrentar esse comportamento somente pela máquina Linux executando a carga de trabalho mista de gravação pesada. 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 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 está acontecendo com a memória virtual e o write-back, considere o trecho 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 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 o vm.dirty_ratio e a vm.dirty_background proporção foram definidos para 2% e 1% de memória física, respectivamente. Neste caso, o flushing começou em 3,8 GiB, 1% do sistema de memória de 384 GiB. O write-back se assemelhava 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

Partilhar via