Explicação sobre o vm.vfs_cache_pressure – Como tirar o máximo partido da cache do sistema de ficheiros do Linux

Vou mostrar como o parâmetro do kernel vm.vfs_cache_pressure a ponderação do cache VFS em relação ao cache de páginas e quais os valores que proporcionam maior velocidade num perfil de carga real. Através de passos claros, ajusto esta configuração, avalio os efeitos e, assim, aproveito o Cache do sistema de ficheiros ideal.

Pontos centrais

Para um início rápido, vou resumir os aspetos mais importantes relativos ao ajuste do Caches VFS em conjunto. Assim, ao escolher o valor, tenho em conta o impacto nas consultas de metadados, na carga de E/S e na pressão sobre a RAM. Estes pontos ajudam-me a otimizar funções típicas de servidor de forma segura e repetível.

• Princípio de funcionamento: Controla o grau de rigor com que o kernel liberta Dentries/Inodes em comparação com a cache de páginas.
• Configuração padrão: 100 significa um ajuste equilibrado, sem preferências.
• Valores baixos: Os valores 50–80 mantêm os metadados na RAM por mais tempo e aceleram a pesquisa de ficheiros.
• Valores elevados: Os caches VFS com valores entre 120 e 200 são libertados mais rapidamente, criando espaço para os processos.
• Prática: Alterar, medir e documentar passo a passo – só depois continuar a ajustar.

Aplico estes princípios de forma coerente, a fim de encontrar o equilíbrio certo entre Taxa de acerto da cache e de RAM disponível. Depois, ajusto o vm.vfs_cache_pressure em pequenos incrementos, observo os picos de carga e corrijo, se necessário. É assim que consigo tempos de resposta estáveis sem estrangulamentos inesperados de memória.

O que é o vm.vfs_cache_pressure?

Este parâmetro controla o rigor com que o kernel trata o Cache VFS em comparação com outras memórias, liberta espaço assim que a RAM começa a ficar escassa. No cache do VFS ficam as dentries e os inodes, ou seja, as entradas de diretório e os metadados dos ficheiros, o que acelera significativamente as pesquisas de ficheiros. Um valor de 100 trata a cache VFS e a cache de páginas da mesma forma, enquanto valores mais baixos dão prioridade à manutenção dos metadados na RAM. Valores mais elevados levam o kernel a descartar as entradas do VFS mais cedo e a libertar memória mais rapidamente. Utilizo esta opção de forma específica para manter elevadas as correspondências de metadados em cargas de trabalho da Web, de ficheiros e de CMS, sem deslocar processos. É assim que controlo o equilíbrio entre Velocidade de pesquisa e à memória livre de forma muito direta.

Como funciona o cache VFS em pormenor?

O Sistema de Ficheiros Virtual constitui uma camada comum para os sistemas de ficheiros ext4, XFS, Btrfs e outros, e armazena Dentries e inodes na RAM, para que as análises de diretórios e os acessos recorrentes se mantenham rápidos. Por outro lado, a cache de páginas armazena os blocos de ficheiros propriamente ditos; ambas as caches complementam-se, mas competem pela memória quando sob pressão. Quanto mais ficheiros pequenos e acessos repetidos frequentes houver, mais a aplicação beneficia de uma elevada taxa de acertos nos metadados. É precisamente aqui que o vm.vfs_cache_pressure entra em ação: posso determinar se o Linux mantém esses metadados ou os liberta rapidamente. Para aspetos mais aprofundados do cache de páginas, utilizo adicionalmente o compacto Otimizador de desempenho do cache de páginas como conhecimento de base, para que eu possa avaliar o VFS e a cache de páginas no contexto.

Valor padrão e intervalos de valores típicos

Na maioria dos sistemas, o valor está definido em 100 e constitui, assim, uma base equilibrada para os primeiros testes. Se reduzir o valor, dou prioridade aos metadados e estabilizo as pesquisas rápidas, o que é especialmente eficaz quando há muitos ficheiros pequenos. Se aumentar o valor, o Linux elimina as entradas do VFS mais rapidamente e cria mais buffer para as aplicações ou para a cache de páginas. Lido com valores extremos, como 0 ou valores superiores a 500, com muita cautela, uma vez que podem desencadear comportamentos drásticos e provocar efeitos secundários. No dia a dia, começo com 100, vou avançando em incrementos de 20 a 40 pontos e avalio o impacto sobre Latência de E/S e tempos de resposta.

Valor	Significado	Quando utilizar	Risco/Aviso
< 100 (por exemplo, 50–80)	A cache VFS permanece mais tempo na RAM	Muitos ficheiros pequenos, consultas frequentes	Maior utilização da RAM em Metadados
100	Ajustamento equilibrado	Valor inicial fiável para as medições	Bom Linha de basevalor ‑
> 100 (por exemplo, 120–200)	O VFS-Cache é libertado de forma mais agressiva	Memória RAM escassa, bases de dados com cache próprio	Possível latência de pesquisa
Extremo (0, > 500)	Mudanças significativas	Casos especiais: teste rápido	Risco para a estabilidade e Desempenho

Com este esquema, consigo perceber rapidamente qual é a direção certa, sem me deixar levar pelo entusiasmo. Evito saltos muito grandes e registo cada alteração em pormenor. Assim, o percurso percorrido permanece sempre claro e consigo manter uma comparação precisa com os pontos de medição anteriores.

Papel na limpeza da memória

Quando está sob pressão, o kernel tem de libertar memória RAM, e é precisamente aqui que vm.vfs_cache_pressure define a ponderação entre Cache VFS, cache de páginas e memória de processos. Valores baixos mantêm as entradas de diretório e inodes na memória por mais tempo, o que agiliza as chamadas aos diretórios e as aberturas repetidas de ficheiros. Valores elevados libertam a memória mais cedo e disponibilizam mais espaço para processos ou para o cache de páginas, o que pode ser útil quando a RAM é escassa. Nesse contexto, observo especificamente as latências de E/S, uma vez que um cache de metadados demasiado vazio atrasa a pesquisa de ficheiros. No que diz respeito à interação com estratégias de libertação do cache de páginas, esta informação dá-me uma visão sobre Expulsão da cache de páginas referências práticas valiosas, para que eu possa tomar decisões com base em factos.

Metodologia de medição: tornar a cache VFS transparente

Antes de alterar, vou tornar visível, onde está no armazenamento e o que é suplantado. É assim que consigo perceber se os metadados são realmente o gargalo – ou se o cache de páginas, os processos ou as páginas sujas são os principais fatores.

• /proc/meminfo: Analiso os parâmetros InodeCache, Cached, Buffers, SReclaimable e SUnreclaim para avaliar a proporção e a recuperabilidade.
• tampo da laje: Visualização em tempo real dos «slabs», nomeadamente «dentry», «inode_cache», «ext4_inode_cache» e «xfs_inode». Assim, consigo ver se os «dentries»/«inodes» estão a aumentar ou a diminuir.
• Caminho IO: Com o vmstat/iostat, observo as latências de leitura e se os acessos ao disco aumentam durante as pesquisas.

# Visão geral rápida
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo

# Distribuição dos slabs (ordenada por tamanho)
sudo slabtop -s c

# Filtrar apenas slabs do tipo dentry/inode
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head

# Tendências de E/S e memória a cada segundo
vmstat 1
iostat -x 1

Considero que a interpretação é clara: se o SReclaimable crescer juntamente com os blocos de dentry/inode e, ao mesmo tempo, as latências de E/S aumentarem não, o que confirma a existência de uma cache de metadados eficaz. Se estes valores descerem frequentemente para zero e subirem rapidamente devido a latências elevadas nos acessos ao diretório, é provável que o vm.vfs_cache_pressure esteja definido de forma demasiado agressiva.

Exemplo prático: Ler e alterar o valor atual

A verificação é feita na linha de comandos em segundos e sem Reiniciar. Leio o valor real e, inicialmente, registo os valores de teste de forma temporária, para poder implementar imediatamente os retrocessos na janela de teste. Para ajustes em ambiente de produção, defino entradas no ficheiro /etc/sysctl.conf ou num ficheiro na pasta /etc/sysctl.d/, recarrego o sistema e registo a alteração na minha documentação. Testo cada nível sob carga realista, e não apenas em modo inativo, para que os efeitos se tornem visíveis. Desta forma, garanto comparações «antes e depois» precisas e avalio a alteração com base em indicadores mensuráveis.

# Verificar o valor atual
cat /proc/sys/vm/vfs_cache_pressure
# ou
sysctl vm.vfs_cache_pressure

# Testar temporariamente (até ao reinício)
sudo sysctl -w vm.vfs_cache_pressure=60
# Alternativamente
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure

# Definir de forma permanente
echo "vm.vfs_cache_pressure = 60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Otimização da cache no Linux: cenários relevantes

Em plataformas de alojamento com muitos recursos estáticos, repositórios de ficheiros ou aplicações com memória tampão própria, vale a pena uma abordagem específica ponderação da cache VFS. Os servidores Web com numerosos ficheiros pequenos beneficiam significativamente de valores mais baixos, uma vez que as pesquisas raramente atingem o SSD/HDD. Os servidores de ficheiros com tamanhos de ficheiros variados podem utilizar valores moderadamente reduzidos, desde que haja RAM suficiente. Os servidores de bases de dados com elevada pressão sobre a RAM e um grande cache de base de dados preferem valores mais elevados, para que os processos tenham espaço. Avalio estes padrões com base em dados de monitorização, para que as definições se adaptem à combinação real de acessos.

Servidor web com muitos ficheiros estáticos

No que diz respeito a CSS, JS e imagens, prefiro manter os metadados por mais tempo no Cache. Valores entre 50 e 80 têm-se revelado frequentemente eficazes, uma vez que a reabertura de ficheiros ocorre mais rapidamente. Analiso cuidadosamente os picos de E/S durante os picos de tráfego e comparo os tempos de resposta antes e depois da alteração. Se as latências se mantiverem estáveis e os custos de pesquisa 404 diminuírem, estamos no caminho certo. Fico atento à utilização da RAM para garantir que os processos tenham espaço suficiente, apesar de um cache de metadados mais robusto.

Servidores de ficheiros ou sistemas NAS

Os acessos frequentes dos utilizadores e as mudanças de diretório beneficiam de mais baixo até valores equilibrados. Se houver RAM suficiente, opto por valores entre 50 e 80; se a memória for mais escassa, mantenho-me mais próximo dos 100. Verifico se as listagens de diretórios continuam fluidas e se os instantâneos/cópias de segurança não ocupam demasiado espaço nas caches. Se a latência de E/S aumentar nos picos, ajusto cuidadosamente para um valor mais elevado. Desta forma, mantenho o equilíbrio entre conforto e memória livre.

Servidores de bases de dados e sistemas com pouca memória

As bases de dados mantêm o seu próprio buffer-cache, por isso atribuo ao Memória de processo na maioria das vezes, tem prioridade. Valores entre 120 e 200 indicam que se deve esvaziar as caches VFS para libertar memória RAM. Nesse contexto, presto atenção às latências das consultas e aos padrões de falhas de página da aplicação. Se a base de dados ficar mais lenta porque o sistema começa a utilizar a memória de troca, aumentei ligeiramente o valor e, ao mesmo tempo, reduzi o vm.swappiness. Esta abordagem evita que os metadados ocupem espaço desnecessariamente, espaço esse que a base de dados pode utilizar de forma mais eficiente.

Exemplos de carga de trabalho e valores de referência

Começo com 100 e vou reduzindo em incrementos de 20 para valores próximos da web Cargas de trabalho e aumento em incrementos de 20 para processos que exigem muita memória. Testo cada nível, pelo menos, durante uma fase de pico, para poder identificar os efeitos nas latências, nos acertos de cache e na atividade de swap. Quem quiser aprofundar o assunto, encontrará no compacto Otimizador de desempenho do cache de páginas informações complementares sobre estratégias de cache de ficheiros, que tenho em conta em paralelo. Se os valores medidos corresponderem aos valores-alvo, fixo a configuração e documento os indicadores. Desta forma, a otimização permanece reproduzível e posso fazer reajustes rapidamente mais tarde.

Riscos e armadilhas

Se definir um valor demasiado baixo, o kernel terá dificuldade em libertar entradas do VFS, o que, em picos de OOM‑riscos. Se o aumentar demasiado, a latência nas pesquisas de ficheiros e nas mudanças de diretório aumenta, porque os metadados têm de ser recarregados. Sem testes sob carga real, corre-se o risco de tirar conclusões erradas a partir de intervalos de tempo com pouca atividade. Os saltos abruptos dificultam a avaliação, pelo que procedo de forma gradual. Registo cada alteração com a data e hora, o perfil de carga e os valores medidos, para que as causas fiquem claras.

Monitorização e indicadores

São os dados concretos que mostram se vale a pena fazer um ajuste Métricas. Observo a utilização da RAM, a distribuição entre caches e processos, as latências de E/S e a atividade de swap. Além disso, analiso as taxas de acerto do cache e as tendências de falhas de página para detetar rapidamente efeitos colaterais. Especialmente no caso de muitos ficheiros pequenos, as melhorias no «Time-to-First-Byte» tornam-se evidentes. Se a latência de E/S se mantiver baixa e o swap diminuir, isso confirma que estamos no caminho certo.

Manual de afinação: Da hipótese à configuração fiável

A estrutura evita que se avance às cegas. Sigo um procedimento definido para que os resultados sejam fiáveis e para que os colegas de equipa possam compreender os passos a seguir.

1. Registar o valor de referência: vm.vfs_cache_pressure=100, carga realista de 24 a 72 horas. Guardar os indicadores-chave (latências: mediana/95.º/99.º percentil, tempo de espera de E/S, «CPU-Steal», atividade de swap, tamanho de inode/dentry).
2. Formular uma hipótese: „Muitos ficheiros pequenos, as consultas são dispendiosas – valores mais baixos aceleram“ ou „Memória RAM escassa – valores mais altos mantêm os processos livres“.
3. Alterar passo a passo: ±20 a ±40 pontos. Medir, pelo menos, uma fase de pico por nível.
4. Comparar: Verifico se os SLOs (por exemplo, o percentil 95) melhoram de forma fiável, sem Mais eventos de swap ou OOM.
5. Critério de reversão: Se as latências 95./99. aumentarem, os tempos de espera da E/S se prolongarem ou as falhas de cache se multiplicarem, dou um passo atrás.
6. Freeze e documentação: Registar o valor final, a data, a janela de carga e os indicadores.

# Teste rápido para janelas de medição controladas (apenas para manutenção!)
# Antes: Capturar instantâneos dos indicadores
date; free -h; grep -E 'InodeCache|Cached' /proc/meminfo; vmstat 1 5

sudo sysctl -w vm.vfs_cache_pressure=80
# Teste de carga/aguardar o pico, depois voltar a registar as métricas e comparar

Sistemas de ficheiros e opções de montagem: o contexto é importante

O efeito do vm.vfs_cache_pressure depende também do sistema de ficheiros e das opções de montagem. Avalio estes fatores da seguinte forma:

• tempo de relação/tempo de inatividade: Evita gravações frequentes com o comando `atime`. O `noatime` reduz a carga de E/S em caso de muitas leituras, o que torna mais evidentes as vantagens dos metadados.
• hora da preguiça: Atrasa as atualizações de metadados na RAM; isto suaviza os picos, mas interage com os momentos de limpeza.
• ext4 vs. XFS vs. Btrfs: Diferentes estruturas de inodes e comportamentos do Shrinker. Eu medo sempre no FS de destino, em vez de transmitir suposições.
• NFS/Sistema de Ficheiros em Rede: O armazenamento em cache e a invalidação de atributos podem limitar os benefícios do VFS. A libertação agressiva (valores elevados) faz com que as consultas remotas aumentem.
• OverlayFS/FUSE: Muitas pequenas operações de metadados beneficiam bastante da cache VFS; considero que os valores devem ser moderados a baixos, desde que haja RAM disponível.

Aspectos relacionados com os contentores e os cgroups

Em ambientes de contentores, tenho sempre em mente que: vm.vfs_cache_pressure é um em todo o servidor Botão. As alterações dizem respeito a todos Pods/contentores no nó. Por isso, opto por uma abordagem conservadora e coordeno o ajuste ao nível do nó.

• Limites de armazenamento: Os Memory-Cgroups limitam a memória do processo e a cache de páginas; a memória Slab pode ser contabilizada proporcionalmente. Tenho observado eventos Pod-OOM e Node-Pressure relacionados com isto.
• Combinação de cargas de trabalho: Os nós que têm simultaneamente DB-Pods e front-ends web não atingem valores extremos. Se for necessário, distribuo as funções por diferentes nós.
• Lançamento: Primeiro nas Canaries (um nó) e, depois, implementação gradual. Documento as alterações na linha de base do nó (sysctl.d) e indico as implementações afetadas.

Casos especiais da prática

É possível abordar alguns padrões de forma específica, se eu conhecer as causas:

• Tarefas de CI/Build: Muitos acessos curtos a ficheiros e análises de diretórios beneficiam de valores mais baixos. Volto a aumentá-los após a conclusão da tarefa, caso os nós sejam utilizados de forma mista.
• Janela de cópia de segurança/análise: As pesquisas prolongadas em diretórios esvaziam as caches. Temporariamente, um mais elevado Valor (por exemplo, 180) para impedir que os dentries/inodes encham a RAM durante a cópia de segurança – depois, volto a definir o valor inicial.
• Entradas negativas: Os ficheiros inexistentes (404) também são armazenados em cache. As cargas de trabalho Web com acessos falhados frequentes beneficiam de forma mensurável quando o cache VFS não é esvaziado de forma demasiado agressiva.
• Streaming/E/S sequencial: Aqui, o Page Cache é o fator dominante; valores demasiado baixos têm pouco efeito e ocupam RAM desnecessariamente. Eu mantenho-o perto de 100 ou um pouco acima.

# Exemplo: tornar-se um pouco mais agressivo durante um backup completo
sudo sysctl -w vm.vfs_cache_pressure=180
# Após o backup, voltar ao valor ótimo determinado anteriormente
sudo sysctl -w vm.vfs_cache_pressure=60

Automatização e governação

Após testes bem-sucedidos, incorporo essa configuração nas minhas compilações padrão. É importante que as equipas saibam que, por que foi selecionado um valor e quando que deve ser verificado (por exemplo, após mudanças de versão ou de carga de trabalho).

• Gestão da configuração: Costumo definir valores predefinidos por função (Web, base de dados, servidor de ficheiros) em /etc/sysctl.d/ e distribuí-los de forma centralizada.
• Controlo de derrapagem: As auditorias regulares verificam se os valores em tempo real e o repositório estão em conformidade.
• Livros de execução: Documento os passos de medição, os valores-limite para o rollback e os procedimentos de emergência (por exemplo, repor para 100).

# Função: Servidor Web (exemplo)
cat <<'EOF' | sudo tee /etc/sysctl.d/50-web-vfs.conf
vm.vfs_cache_pressure = 60
EOF
sudo sysctl --system

vm.vfs_cache_pressure e outros parâmetros do kernel

Um bom resultado só surge quando se combina com vm.swappiness e os valores-limite das páginas sujas. Um valor mais baixo de swappiness (por exemplo, 10–20) mantém os processos na RAM e evita a transferência desnecessária para a memória externa. Com vm.dirty_background_ratio e vm.dirty_ratio, regulo a rapidez com que o sistema grava as páginas alteradas, para que os picos de escrita não bloqueiem tudo. Ajusto estes valores de forma a que as pesquisas de metadados se mantenham rápidas e as operações de gravação decorram de forma planeada. Utilizo aqui uma visão geral concisa sobre a interação entre as caches de ficheiros: Visão geral do armazenamento em cache do sistema de ficheiros.

Recomendações para ambientes de alojamento e o WordPress

Muitos temas, plugins e ficheiros multimédia geram inúmeros ficheiros pequenos, razão pela qual é necessário um Cache VFS ajuda significativamente. Começo com 100, reduzo para 80 quando a RAM for suficiente, depois para 60, e verifico os tempos de resposta, o percentil 95 das latências e o «CPU-Steal». Se a memória continuar a ser suficiente, testo o valor 50 e volto a validar durante o pico da noite ou durante as campanhas. Se as latências diminuírem sem que o swap ou o OOM Killer sejam acionados, fixo essa configuração de forma permanente. Paralelamente, mantenho o cacho de páginas sob vigilância, para que ambos os caches se complementem de forma eficaz.

Resumo

Com o vm.vfs_cache_pressure, controlo o Equilíbrio de forma muito específica, entre pesquisas rápidas de metadados e memória RAM livre. Para cargas de trabalho relacionadas com a Web, reduzo o valor moderadamente; para aplicações que consomem muita memória, aumentei-o. Justifico cada alteração com valores de medição relativos a latências de E/S, acertos de cache e atividade de swap. Em combinação com o vm.swappiness e os parâmetros «dirty», consigo uma gestão de memória estável. Assim, utilizo o cache do sistema de ficheiros do Linux de forma eficiente e mantenho os tempos de resposta baixos de forma fiável, mesmo sob carga.