Ajuste do ZFS ARC: Limites máximos, restrições e o que medir

Por predefinição, o ZFS ocupa discretamente cerca de metade da RAM do sistema para a sua cache de leitura e, num servidor inadequado, isso significa atividade de swap, encerramento de processos por falta de memória (OOM) ou uma base de dados a competir com o sistema de ficheiros pela memória. O ajuste do ARC do ZFS consiste em decidir quanta dessa RAM o ARC está efetivamente autorizado a manter e o que se abdica para definir o limite. Este artigo aborda a forma como o ARC utiliza a memória, o que deve ser avaliado antes de se alterar qualquer coisa, os parâmetros ajustáveis que vale a pena alterar e pontos de partida sensatos para servidores de ficheiros, hipervisores, bases de dados e destinos de cópias de segurança. No que diz respeito aos instantâneos do ZFS, consulte o nosso guia sobre instantâneos do ZFS.

Meça o ARC antes de ajustar qualquer coisa

Não altere nenhum parâmetro ajustável até ter valores de referência de um período normal de tráfego intenso. Os registos tirados em períodos de baixo tráfego podem induzi-lo em erro. As cópias de segurança noturnas, os relatórios semanais e os trabalhos em lote são, normalmente, os momentos em que o comportamento do ARC se torna mais interessante; por isso, recolha dados ao longo de vários dias.

Três ferramentas cobrem a maior parte do que precisa:

• arcstat 1 apresenta uma visualização em tempo real e com rolagem dos contadores de acertos e falhas, da atividade de procura versus pré-busca e do tamanho atual do ARC. Utilize-a durante testes de carga e janelas de cópia de segurança.
• arc_summary imprime um único instantâneo: tamanho e meta do ARC, divisão entre MFU e MRU, rácios de metadados e parâmetros de ajuste ativos. Execute arc_summary -s arc apenas para a secção ARC.
• Os contadores brutos encontram-se /proc/spl/kstat/zfs/arcstats no Linux e na diretiva kstat.zfs.misc e vfs.zfs árvores sysctl no FreeBSD. Recolha estes dados a partir do sistema de monitorização, em vez de analisar saídas formatadas.

Os contadores que vale a pena registar antes de qualquer alteração:

Há duas coisas que as pessoas costumam confundir aqui. Fique atento à memória disponível, não à memória livre; o Linux apresenta tranquilamente um baixo nível de RAM livre como um estado estável e isso, por si só, não é um problema. O sinal que importa é a memória disponível próxima de zero, combinada com atividade de swap sustentada (o manual básico de gestão de memória do Linux explica o porquê). E considere a taxa de acertos como uma tendência, não como uma meta. Uma taxa de acertos de 99% num sistema que está a utilizar o swap é um fracasso de otimização, não um sucesso.

Os quatro parâmetros ajustáveis do ARC que importam

A maior parte do ajuste em produção resume-se a quatro parâmetros. Ajuste a configuração de acordo com a pressão que mediu efetivamente na linha de base. A atividade de troca aponta para zfs_arc_max. A recuperação de dados que continua a limpar um cache ativo aponta para zfs_arc_min. As pesquisas lentas nos diretórios apontam para o limite de metadados.

Comece com a alteração mais pequena que resolva a pressão que consegue observar. Para zfs_arc_max, o limite máximo adequado depende da carga de trabalho (abordado na próxima secção). Para zfs_arc_min, um limite mínimo de 25% a 50% de zfs_arc_max é um ponto de partida razoável, caso seja necessário definir algum. No que diz respeito aos metadados, as predefinições recentes do OpenZFS já atribuem aos metadados 75% do ARC através de zfs_arc_meta_limit_percent, o que é generoso para a maioria das cargas de trabalho; só altere isto quando as falhas nos metadados forem claramente visíveis em arcstat.

Aplicar alterações no Linux e no FreeBSD

No Linux, teste uma alteração em tempo de execução escrevendo no ficheiro de parâmetros do sysfs. Não é necessário reiniciar:

echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max

Isso define zfs_arc_max para 16 GiB imediatamente. Para que a alteração se mantenha após um reinício, adicione-a ao /etc/modprobe.d/zfs.conf:

options zfs zfs_arc_max=17179869184

No FreeBSD, as alterações em tempo de execução utilizam sysctl:

sysctl vfs.zfs.arc_max=17179869184

Persista o mesmo valor em /boot/loader.conf:

vfs.zfs.arc_max="17179869184"

Altere uma configuração de cada vez, em pequenos incrementos de cerca de 10% da RAM total. Observe a janela de erros. Mantenha a alteração apenas se o swap permanecer em zero e a latência estiver estável. Torne a alteração permanente apenas após o teste em tempo de execução ser bem-sucedido.

Ajuste do ARC de acordo com a carga de trabalho

A memória RAM total não é o ponto de partida correto. O dimensionamento do ARC deve seguir a combinação de cargas de trabalho no equipamento.

Um anfitrião de máquinas virtuais precisa de partilhar memória com os seus convidados, pelo que um limite de 30% a 40% é um valor predefinido seguro e 50% já é demasiado elevado na maioria das configurações. Bases de dados como o PostgreSQL e o MySQL gerem os seus próprios caches de buffer, pelo que se deve reservar memória para o motor em primeiro lugar e deixar que o ARC fique com o que sobrar. Os destinos de cópia de segurança beneficiam disso primarycache=metadata porque os dados que estão a ser lidos raramente são necessários novamente, e não se quer que um backup noturno percorra todo o conjunto e esvazie o resto do cache à medida que avança. Em todas as cargas de trabalho, a atividade de swap enquanto o ARC está fixado em zfs_arc_max significa que o limite está demasiado alto; essa regra não muda.

Diagnosticar problemas e saber quando parar

Um ARC subdimensionado manifesta-se através de um elevado número de IOPS de leitura, baixas taxas de acertos de pedidos e navegação lenta nos diretórios, enquanto o sistema ainda dispõe de RAM livre. Um ARC sobredimensionado é menos óbvio. A taxa de acertos parece normal, mas o equipamento começa a recorrer ao swap, as médias de carga sobem, os processos ficam bloqueados no D estado enquanto o kernel recupera páginas do ARC sob demanda e, no pior dos casos, o OOM killer começa a escolher vítimas. O cache parece saudável e o servidor funciona muito mal.

A pressão dos metadados manifesta-se quando demand_metadata_bytes se situa muito acima de demand_data_bytes em arc_summary. É nessa altura que os metadados estão a disputar espaço com os dados, e vale a pena aumentar o limite percentual de metadados.

Compare o que vê com a primeira configuração a verificar:

O L2ARC não é gratuito. O índice das entradas do L2ARC reside no ARC primário e, se essa sobrecarga ultrapassar cerca de um terço da capacidade total do ARC, o cache secundário acaba por causar mais prejuízos do que benefícios. Recorra ao L2ARC apenas quando o conjunto de trabalho for maior do que a RAM, mas ainda couber num dispositivo NVMe rápido, e apenas quando a taxa de acertos do ARC primário já estiver saudável.

O momento certo para parar de ajustar é quando a latência se mantém estável, o swap permanece a zero durante o mesmo período de pico de atividade que causou o problema original e alterações adicionais já não trazem melhorias. Uma elevada taxa de acertos não significa nada se o servidor estiver a recorrer ao swap. Passado esse ponto, pare de ajustar as configurações e só as reveja se o mesmo problema voltar a ocorrer com a mesma carga de trabalho.

Se precisar de um servidor com capacidade de RAM suficiente para executar o ZFS corretamente sem competir por memória com as suas máquinas virtuais ou bases de dados (vale a pena ler primeiro «Quanta RAM precisa realmente?»), dê uma vista de olhos aos servidores dedicados da FDC.