ZFS L2ARC: O Turbo que Pode Frear seu Storage (E Como Saber a Diferença)

Você chega à cena do crime: um servidor de arquivos ZFS lento. O administrador, em uma tentativa desesperada de performance, instalou um SSD NVMe caro e o adicionou ao pool como cache (L2ARC). O resultado? O sistema não apenas não acelerou, como em alguns casos, ficou mais lento.

Como investigador forense de sistemas, já vi esse cenário centenas de vezes. O L2ARC (Level 2 Adaptive Replacement Cache) é a funcionalidade mais mal compreendida do ZFS. Ele é frequentemente vendido como um "botão turbo", mas na prática, funciona mais como um turbocompressor complexo: se mal dimensionado para o motor, ele apenas gera calor e resistência.

Vamos dissecar a anatomia desse problema, isolar as variáveis e entender quando esse cache é a solução e quando é o culpado.

A Hierarquia da Latência: Onde o Suspeito se Esconde

Para entender por que o L2ARC pode falhar, você precisa abandonar a ideia de que ele é "RAM extra". Ele não é. Ele é um disco.

O ZFS opera com uma obsessão primária: não ler do disco magnético (HDD). Para isso, ele usa o ARC (RAM).

ARC (RAM): Latência de nanossegundos. Acesso instantâneo.
L2ARC (SSD): Latência de microssegundos. Rápido, mas ordens de magnitude mais lento que a RAM.
Pool (HDD): Latência de milissegundos. Uma eternidade.

O L2ARC serve apenas para estender a capacidade de leitura aleatória quando a RAM está cheia. Ele fica entre a memória e o disco rotacional. Se o seu pool principal já é composto por SSDs rápidos (All-Flash), a vantagem do L2ARC diminui drasticamente, muitas vezes tornando-se irrelevante ou prejudicial devido à sobrecarga de gerenciamento.

O Imposto Oculto: A Autópsia dos Headers

Aqui está a evidência técnica que a maioria ignora: O L2ARC consome RAM para existir.

O ZFS precisa saber o que está guardado no cache SSD. Para isso, ele mantém uma tabela de indexação (headers) na RAM principal (no ARC). Cada bloco de dados armazenado no L2ARC custa aproximadamente 70 bytes de RAM para ser rastreado.

Pode parecer pouco, mas faça as contas. Se você tem muitos arquivos pequenos (recordsize de 4K ou 8K) e adiciona um L2ARC de 1TB, você pode estar consumindo gigabytes de RAM apenas para dizer ao ZFS onde os dados estão no SSD.

O Efeito Canibal: Se o seu sistema tem pouca memória (digamos, 32GB ou 64GB), ao ativar um L2ARC grande, o ZFS é forçado a expulsar dados reais do ARC (RAM) para dar espaço aos headers do L2ARC.

Você está trocando dados que seriam servidos em nanossegundos (RAM) por um índice que aponta para dados que serão servidos em microssegundos (SSD). Você criou um gargalo artificial.

Figura: O Trade-off do L2ARC: Para gerenciar dados no SSD, o ZFS precisa comer RAM para criar o índice. Se o L2ARC for grande demais em um sistema com pouca memória, você reduz o cache mais rápido (RAM) para alimentar o cache mais lento (SSD).

Definindo o "Working Set"

Antes de receitar o remédio, precisamos diagnosticar a doença. A pergunta fundamental não é "o storage está lento?", mas sim "os dados quentes cabem na RAM?".

Chamamos de Working Set o conjunto de dados acessados frequentemente em um intervalo de tempo relevante.

Cenário A: Seu Working Set é de 10GB. Seu servidor tem 64GB de RAM. O L2ARC é inútil. Tudo já está na RAM. O SSD ficará ocioso.
Cenário B: Seu Working Set é de 200GB. Seu servidor tem 64GB de RAM. Aqui o L2ARC brilha. Ele captura o transbordo (os 136GB restantes) e evita que o sistema busque isso nos HDDs lentos.

Se você não sabe o tamanho do seu Working Set, você está operando às cegas.

Evidência Forense com `arcstat`

Não confie em sentimentos. Confie na telemetria. O utilitário arcstat (geralmente disponível em distribuições Linux com ZFS e FreeBSD) é sua ferramenta de diagnóstico.

Execute o comando abaixo durante um momento de carga alta:

arcstat -f time,read,hits,miss,hit%,l2_size,l2_hits,l2_miss,l2_read,l2_hit% 1

O que procurar na autópsia:

hit% (ARC Hit Rate): Se estiver consistentemente acima de 95-99%, pare. Você não precisa de L2ARC. Sua RAM está dando conta.
l2_size: O cache está enchendo? Se estiver zerado ou muito baixo após dias de uso, seus dados não são elegíveis para cache (talvez sejam leituras sequenciais, que o ZFS ignora por padrão no L2ARC).
l2_hits vs l2_miss:
- Muitos misses no ARC seguidos de muitos hits no L2ARC? Sucesso. O sistema está funcionando como projetado.
- Muitos misses no ARC e muitos misses no L2ARC? Fracasso. O cache não contém os dados que o usuário quer. Você está apenas adicionando latência ao verificar o SSD antes de ir ao HDD.

A Lista Fantasma (Ghost List)

O ZFS é inteligente. Ele mantém uma lista de "metadados de dados despejados recentemente" (Ghost List). Ele sabe o que acabou de jogar fora da RAM. Se você verificar as estatísticas internas (/proc/spl/kstat/zfs/arcstats no Linux) e vir contadores altos de "ghost hits", isso é a prova definitiva: o ZFS está dizendo "Eu tinha esse dado, joguei fora por falta de espaço, e você acabou de pedi-lo de novo". Isso justifica expandir o cache (seja RAM ou L2ARC).

Cenários de Fracasso Comuns

Durante minhas investigações, identifiquei três perfis de sistemas onde o L2ARC é o vilão:

O Streamer: Servidores de mídia ou backup. Esses dados são lidos sequencialmente e raramente relidos imediatamente. O L2ARC apenas desgasta o SSD gravando dados que nunca serão solicitados novamente.
O Faminto por RAM: Sistemas com menos de 64GB de RAM (regra geral, mas varia). A penalidade dos headers do L2ARC geralmente supera o benefício.
O Bloco Minúsculo: Bancos de dados rodando com recordsize=4k ou 8k em pools gigantes. A tabela de indexação explode na RAM, expulsando o cache primário.

Configuração Cirúrgica

Se as evidências provam que você precisa de L2ARC, não use os padrões de fábrica. Ajuste para evitar a queima prematura do SSD e a saturação do barramento.

1. Limite a Velocidade de Gravação

O preenchimento do L2ARC compete por I/O. Não deixe ele engarrafar o sistema tentando "aquecer" rápido demais.

# Exemplo: Limitar a 100MB/s (valor depende do seu SSD)
echo 104857600 > /sys/module/zfs/parameters/l2arc_write_max

2. Não Faça Cache de Streaming

Garanta que o sistema não esteja jogando lixo sequencial no seu SSD precioso.

# Geralmente o padrão é 0 (desligado), mas verifique.
# 1 = cacheia streaming. 0 = não cacheia.
cat /sys/module/zfs/parameters/l2arc_noprefetch

3. A Estratégia "Metadata Only"

Esta é frequentemente a melhor configuração para sistemas com HDDs giratórios e RAM limitada. Você instrui o ZFS a usar o L2ARC apenas para metadados (onde estão os arquivos, permissões, etc.), deixando os dados brutos nos HDDs. Isso acelera drasticamente operações como ls, find e navegação de diretórios, com custo mínimo de RAM.

zfs set secondarycache=metadata tank/dataset

Veredito: O Checklist Definitivo

A decisão de adicionar complexidade ao storage nunca deve ser baseada em "pode ajudar", mas sim em "medi e comprovei que falta espaço".

Seu fluxo de decisão deve seguir rigorosamente a lógica abaixo. Note que "Adicionar L2ARC" é o último recurso, não o primeiro.

Figura: O Algoritmo de Decisão: Não adicione complexidade a menos que a telemetria exija. A maioria dos problemas de performance se resolve com mais RAM, não com L2ARC.

Resumo do Investigador

RAM é Rei: Antes de comprar um SSD para L2ARC, maximize a RAM da placa-mãe. 32GB de RAM adicional valem mais que 500GB de L2ARC.
Meça os Ghost Hits: Se o ZFS não está lamentando a perda de dados recentes, ele não precisa de mais espaço.
Cuidado com o Overhead: Em dúvida, use secondarycache=metadata. É o upgrade mais seguro e com melhor custo-benefício para arrays de discos mecânicos.

Se você não consegue provar com números que seu Working Set é maior que sua RAM, remova o L2ARC. Seu sistema agradecerá a simplicidade.