Melhores Práticas para Ajustar o Swappiness e o Comportamento do Cache no Linux

O Linux usará RAM livre. Isso surpreende as pessoas na primeira vez que veem um servidor com muito pouca memória "livre" em free -h. Grande parte dessa memória pode ser cache de página, dentries e cache de inodes, não um vazamento. A parte difícil é saber quando o kernel está fazendo bom uso da RAM e quando a recuperação de memória está começando a prejudicar suas aplicações.

Duas configurações do sysctl frequentemente aparecem durante o ajuste de memória do Linux: vm.swappiness e vm.vfs_cache_pressure. Elas são úteis, mas não são interruptores mágicos de desempenho. Um valor ruim pode esconder o problema real ou transferir a dor de uma carga de trabalho para outra.

Entendendo os Parâmetros de Gerenciamento de Memória do Linux

O Linux usa heurísticas para decidir quais páginas de memória recuperar quando o sistema precisa de mais RAM livre. As duas principais áreas controladas por parâmetros do kernel são swap (mover páginas de memória inativas para o disco) e cache (manter metadados do sistema de arquivos e dados na RAM).

1. `vm.swappiness`

vm.swappiness dita a tendência do kernel de mover processos da memória física para o espaço de swap no disco. É um valor entre 0 e 100.

Valor mais alto (por exemplo, 60, um padrão comum): O kernel está mais disposto a recuperar memória anônima e usar swap como parte do gerenciamento normal de memória. Isso pode preservar o cache de página, mas também pode prejudicar serviços sensíveis à latência se páginas ativas forem removidas.
Valor baixo (por exemplo, 10 ou menos): O kernel prefere recuperar memória do cache de página antes de começar a trocar processos. Isso mantém as aplicações em execução na RAM por mais tempo, melhorando a capacidade de resposta, mas potencialmente reduzindo o desempenho de E/S do disco se o sistema precisar constantemente descartar páginas de cache.
Valor 0: O kernel evita o swap tanto quanto razoavelmente possível, mas isso não desabilita o swap. Se você precisar desabilitar o swap, use swapoff e entenda primeiro o risco de falta de memória.

Aplicação Prática de `vm.swappiness`

A configuração ideal depende muito da carga de trabalho:

Tipo de Carga de Trabalho	Faixa de `swappiness` Recomendada	Justificativa
Servidores de Banco de Dados, Computação de Alto Desempenho (HPC)	1 - 10	Muitas vezes um bom ponto de partida quando a latência do swap é pior do que descartar o cache. Valide com métricas reais de carga de trabalho.
Servidores de Uso Geral, Desktops	30 - 60	Geralmente razoável, a menos que você tenha evidências de que o comportamento do swap está prejudicando você.
Sistemas de Servidor de Arquivos ou com uso intensivo de cache	60 ou mais em alguns casos	Pode preservar o cache de página, mas só faz sentido se o swap ocasional for aceitável para a carga de trabalho.

Como Verificar o Valor Atual:

cat /proc/sys/vm/swappiness

Como Alterar o Valor Temporariamente (até a reinicialização):

Para definir swappiness como 10:

sudo sysctl vm.swappiness=10

Como Alterar o Valor Permanentemente:

Edite o arquivo /etc/sysctl.conf e adicione ou modifique a linha:

# /etc/sysctl.conf
vm.swappiness = 10

Após salvar, aplique as alterações sem reiniciar usando:

sudo sysctl -p

Para bancos de dados com uso intensivo de memória, 1 a 10 é um ponto de partida comum. Não trate isso como uma regra. Um banco de dados que já possui seu próprio cache de buffer, como PostgreSQL ou MySQL/InnoDB, geralmente se beneficia ao evitar o swap. Um servidor de arquivos pode preferir um cache de página maior. Uma VM pequena com pouca RAM sofrerá independentemente do número que você escolher.

2. `vfs_cache_pressure`

vfs_cache_pressure controla o quão agressivamente o kernel recupera a memória usada para metadados de diretório e inode (o cache VFS).

Este valor varia de 0 a 1000.
O valor padrão é tipicamente 100.

Com um valor de 100, o kernel equilibra a recuperação da memória do cache VFS com a recuperação da memória usada pelo cache de página (dados do disco). Um valor de 100 significa que, quando há pressão de memória, o kernel tenta recuperar 1 parte da memória do cache de inode/dentry para cada 1 parte da memória do cache de página.

Ajustando `vfs_cache_pressure`

Aumentando o Valor (por exemplo, > 100): Torna o kernel mais agressivo na recuperação da memória do cache VFS. Isso libera RAM mais rapidamente, mas pode levar a consultas mais lentas do sistema de arquivos subsequentes, pois os metadados precisam ser lidos do disco novamente.
Diminuindo o Valor (por exemplo, < 100): Torna o kernel mais conservador na recuperação do cache VFS. Isso mantém as informações de diretório e inode na memória por mais tempo, acelerando as operações repetidas do sistema de arquivos.

Quando Diminuir vfs_cache_pressure:

Se o seu sistema acessa frequentemente as mesmas grandes estruturas de diretório (comum em aplicações complexas, orquestração de contêineres ou configurações de rede específicas), definir este valor mais baixo (por exemplo, 50) pode melhorar o desempenho, mantendo os metadados prontamente disponíveis na RAM.

Quando Aumentar vfs_cache_pressure:

Se o seu sistema está sofrendo de pressão geral de memória e você deseja que o kernel recupere qualquer memória não utilizada rapidamente, você pode aumentar este valor, embora isso seja menos comum do que diminuí-lo.

Como Verificar o Valor Atual:

cat /proc/sys/vm/vfs_cache_pressure

Como Alterar o Valor Permanentemente:

Edite /etc/sysctl.conf:

# /etc/sysctl.conf
vfs_cache_pressure = 50

Aplique as alterações com sudo sysctl -p.

Aviso: Valores muito baixos de vfs_cache_pressure podem fazer com que o kernel mantenha o cache de diretório e inode por mais tempo do que você espera. Isso pode ajudar cargas de trabalho com muitos metadados, mas também pode piorar a pressão de memória para as aplicações. Evite valores extremos, a menos que você tenha medido o efeito.

Cenários Abrangentes de Ajuste

Escolher a combinação certa desses parâmetros otimiza o trade-off entre a estabilidade da aplicação e o cache do sistema de arquivos.

Cenário 1: Servidor de Banco de Dados (Prioridade de Memória)

Objetivo: Maximizar a residência de memória da aplicação; minimizar o swap a todo custo.

vm.swappiness = 5
vfs_cache_pressure = 50 (Manter dados de diretório em cache de alguma forma, mas priorizar a memória da aplicação sobre os metadados VFS se a RAM ficar escassa).

Antes de mudar qualquer coisa, verifique se o banco de dados está realmente fazendo swap:

free -h
vmstat 1
grep -E 'pswpin|pswpout' /proc/vmstat

Se os contadores de swap-in e swap-out estiverem aumentando durante picos de latência de consulta, diminuir o swappiness pode ajudar. Se o swap não estiver sendo usado e o banco de dados estiver lento, o swappiness não é o seu problema. Analise os planos de consulta, a taxa de acerto do buffer, os checkpoints, a latência do disco e a pressão de conexão.

Cenário 2: Servidor com Alta E/S de Disco (Prioridade de Cache)

Objetivo: Maximizar o desempenho do disco mantendo os dados de arquivos acessados com frequência no cache de página.

vm.swappiness = 80 (Permite que o swap ocorra mais cedo para liberar RAM para expansão do cache de disco).
vfs_cache_pressure = 100 (Equilíbrio padrão entre cache de inode e página).

Este é o cenário onde as pessoas mais frequentemente ajustam em excesso. Se o servidor lê principalmente os mesmos arquivos repetidamente, o cache de página importa. Mas se o sistema começar a trocar processos de trabalho ativos para preservar o cache, os usuários podem ver pior latência, mesmo que o cache do sistema de arquivos pareça saudável. Observe o tempo de resposta da aplicação, não apenas o tamanho do cache.

Cenário 3: Host de Virtualização ou Sistema de Uso Geral

Objetivo: Desempenho estável em múltiplas cargas de trabalho.

vm.swappiness = 30 (Uma configuração moderada que favorece manter VMs/processos ativos na RAM um pouco mais do que o padrão 60, mas ainda permite swap controlado).
vfs_cache_pressure = 100 (O padrão geralmente é suficiente).

Hosts de virtualização precisam de cuidado extra porque o comportamento da memória do convidado pode enganar o ajuste no nível do host. Ballooning, overcommit e swap do convidado podem interagir. Um host que troca pesadamente a memória do convidado pode criar latência dolorosa dentro das VMs, mesmo quando cada convidado pensa que sua própria carga de trabalho está normal.

Um Fluxo de Trabalho de Ajuste Mais Seguro

Não comece editando /etc/sysctl.conf. Comece provando que a configuração é relevante.

Capture uma linha de base durante a carga normal:

free -h
vmstat 1 10
cat /proc/sys/vm/swappiness
cat /proc/sys/vm/vfs_cache_pressure

Capture os mesmos dados durante o período lento. Adicione memória no nível do processo:
```
ps -eo pid,comm,rss,vsz,%mem --sort=-rss | head -20
```
Altere um valor temporariamente:
```
sudo sysctl vm.swappiness=10
```
Execute a carga de trabalho por tempo suficiente para observar o comportamento. Procure por menor atividade de swap, melhor latência da aplicação e nenhuma nova lentidão do sistema de arquivos.
Torne o valor persistente somente depois que ele sobreviver a uma janela de teste realista.

Em sistemas que usam /etc/sysctl.d/, um pequeno arquivo dedicado geralmente é mais limpo do que anexar ao /etc/sysctl.conf:

sudo tee /etc/sysctl.d/90-memory-tuning.conf >/dev/null <<'EOF'
vm.swappiness = 10
vm.vfs_cache_pressure = 100
EOF

sudo sysctl --system

Se o seu sistema de gerenciamento de configuração possui as configurações do sysctl, coloque a alteração lá. Edições manuais do sysctl em um servidor são fáceis de esquecer e difíceis de reproduzir.

Lendo `free -h` Sem Entrar em Pânico

Uma saída típica de free -h pode mostrar um número pequeno em free e um número grande em buff/cache. Isso é normal. O Linux mantém dados de arquivos usados recentemente na memória porque RAM não utilizada não ajuda ninguém.

Concentre-se em available, uso de swap e se a atividade de swap está ocorrendo agora. Um servidor pode ter swap alocado de um pico de memória passado, mas sem agitação de swap atual. Isso é menos urgente do que um servidor constantemente trocando para dentro e para fora.

Use:

vmstat 1

Se si e so permanecerem próximos de zero sob carga normal, o swap não está ativamente gerando latência naquele momento. Se eles permanecerem diferentes de zero enquanto as aplicações param, a pressão de memória é um suspeito sério.

Quando Não Ajustar Essas Configurações

Existem vários casos onde alterar o swappiness ou a pressão de cache é a primeira correção errada.

Se o servidor não tem swap configurado, vm.swappiness tem pouco efeito prático. Você ainda pode ajustá-lo para consistência de política, mas isso não resolverá a pressão de memória por si só.

Se o swap existe apenas como uma pequena partição de emergência, a configuração também tem espaço limitado para ajudar. O kernel pode escolher quando usar swap, mas não pode transformar algumas centenas de megabytes de espaço de emergência em um nível de memória real. Nessa configuração, concentre-se no risco de OOM e nos limites de serviço.

Se um processo tem um vazamento de memória real, diminuir o swappiness atrasa a dor. O vazamento continuará crescendo. Reiniciar o serviço pode restaurar a capacidade temporariamente, mas a correção duradoura é no nível da aplicação: corrigir o vazamento, limitar a memória, reduzir a concorrência ou alterar a carga de trabalho.

Se o disco está lento devido a uma unidade com falha, limitação de armazenamento ou um volume de nuvem saturado, o ajuste de memória pode reduzir algumas leituras, mas não corrigirá a falha de armazenamento. Verifique iostat, logs do kernel, métricas de volume de nuvem e saúde SMART/NVMe.

Se o conjunto de trabalho for maior que a RAM, não há valor de sysctl perfeito. Você precisa de mais memória, menos concorrência, caches menores, um layout de dados diferente ou uma divisão de carga de trabalho.

Notas sobre Contêineres e Kubernetes

O ajuste de memória fica mais complicado em contêineres. Um contêiner pode atingir seu limite de memória do cgroup mesmo enquanto o host tem RAM livre. A configuração de swappiness do host ainda importa, mas o sintoma imediato pode ser uma morte por OOM dentro de um pod ou contêiner.

Verifique os sinais do cgroup e do orquestrador:

dmesg -T | grep -i 'killed process'
docker stats
kubectl describe pod <nome-do-pod>

Para Kubernetes, alterar sysctls no nível do nó deve fazer parte da configuração do pool de nós, não de uma sessão de shell única. Lembre-se também de que alguns sysctls têm namespace e outros são no nível do nó. vm.swappiness e vm.vfs_cache_pressure são configurações no nível do host em sistemas Linux típicos, portanto, alterá-los afeta todas as cargas de trabalho nesse nó.

Monitoramento e Validação

Após aplicar as alterações, o monitoramento contínuo é crucial para validar o impacto. Use ferramentas como free, vmstat e painéis de monitoramento de desempenho do sistema.

Usando vmstat:

Monitore as colunas si (swap in) e so (swap out). Um sistema saudável com baixo swappiness deve mostrar valores baixos ou zero para si e so sob carga normal.

vmstat 5 10

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\ r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 123456 102400 5123456    0    0     0     5   40   70  1  1 98  0  0

Se os valores de so permanecerem altos após reduzir o swappiness, a carga de trabalho provavelmente precisa de mais memória utilizável ou menor demanda de memória. Mais RAM é uma resposta, mas não a única. Você também pode reduzir as contagens de trabalhadores, diminuir os caches da aplicação, ajustar a memória do banco de dados, corrigir vazamentos ou dividir serviços entre hosts.

Trate vm.swappiness e vm.vfs_cache_pressure como preferências de carga de trabalho, não atualizações universais. O caminho prático é chato, mas confiável: meça o comportamento atual de swap e recuperação, altere uma configuração, teste sob carga real e mantenha a alteração somente se o comportamento da aplicação melhorar.