{"id":20874,"date":"2026-08-21T18:22:37","date_gmt":"2026-08-21T16:22:37","guid":{"rendered":"https:\/\/webhosting.de\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/"},"modified":"2026-08-21T18:22:37","modified_gmt":"2026-08-21T16:22:37","slug":"vm-vfs-pressao-do-cache-linux-ajuste-do-cache-do-sistema-de-ficheiros-otimizacao","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/vm-vfs-cache-pressure-linux-filesystem-cache-tuning-optimierung\/","title":{"rendered":"Explica\u00e7\u00e3o sobre o vm.vfs_cache_pressure \u2013 Como tirar o m\u00e1ximo partido da cache do sistema de ficheiros do Linux"},"content":{"rendered":"<p>Vou mostrar como o par\u00e2metro do kernel <strong>vm.vfs_cache_pressure<\/strong> a pondera\u00e7\u00e3o do cache VFS em rela\u00e7\u00e3o ao cache de p\u00e1ginas e quais os valores que proporcionam maior velocidade num perfil de carga real. Atrav\u00e9s de passos claros, ajusto esta configura\u00e7\u00e3o, avalio os efeitos e, assim, aproveito o <strong>Cache do sistema de ficheiros<\/strong> ideal.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>Para um in\u00edcio r\u00e1pido, vou resumir os aspetos mais importantes relativos ao ajuste do <strong>Caches VFS<\/strong> em conjunto. Assim, ao escolher o valor, tenho em conta o impacto nas consultas de metadados, na carga de E\/S e na press\u00e3o sobre a RAM. Estes pontos ajudam-me a otimizar fun\u00e7\u00f5es t\u00edpicas de servidor de forma segura e repet\u00edvel.<\/p>\n\n<ul>\n  <li><strong>Princ\u00edpio de funcionamento<\/strong>: Controla o grau de rigor com que o kernel liberta Dentries\/Inodes em compara\u00e7\u00e3o com a cache de p\u00e1ginas.<\/li>\n  <li><strong>Configura\u00e7\u00e3o padr\u00e3o<\/strong>: 100 significa um ajuste equilibrado, sem prefer\u00eancias.<\/li>\n  <li><strong>Valores baixos<\/strong>: Os valores 50\u201380 mant\u00eam os metadados na RAM por mais tempo e aceleram a pesquisa de ficheiros.<\/li>\n  <li><strong>Valores elevados<\/strong>: Os caches VFS com valores entre 120 e 200 s\u00e3o libertados mais rapidamente, criando espa\u00e7o para os processos.<\/li>\n  <li><strong>Pr\u00e1tica<\/strong>: Alterar, medir e documentar passo a passo \u2013 s\u00f3 depois continuar a ajustar.<\/li>\n<\/ul>\n\n<p>Aplico estes princ\u00edpios de forma coerente, a fim de encontrar o equil\u00edbrio certo entre <strong>Taxa de acerto da cache<\/strong> e de RAM dispon\u00edvel. Depois, ajusto o vm.vfs_cache_pressure em pequenos incrementos, observo os picos de carga e corrijo, se necess\u00e1rio. \u00c9 assim que consigo tempos de resposta est\u00e1veis sem estrangulamentos inesperados de mem\u00f3ria.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cache-optimierung-4756.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que \u00e9 o vm.vfs_cache_pressure?<\/h2>\n\n<p>Este par\u00e2metro controla o rigor com que o kernel trata o <strong>Cache VFS<\/strong> em compara\u00e7\u00e3o com outras mem\u00f3rias, liberta espa\u00e7o assim que a RAM come\u00e7a a ficar escassa. No cache do VFS ficam as dentries e os inodes, ou seja, as entradas de diret\u00f3rio 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\u00e1ginas da mesma forma, enquanto valores mais baixos d\u00e3o prioridade \u00e0 manuten\u00e7\u00e3o dos metadados na RAM. Valores mais elevados levam o kernel a descartar as entradas do VFS mais cedo e a libertar mem\u00f3ria mais rapidamente. Utilizo esta op\u00e7\u00e3o de forma espec\u00edfica para manter elevadas as correspond\u00eancias de metadados em cargas de trabalho da Web, de ficheiros e de CMS, sem deslocar processos. \u00c9 assim que controlo o equil\u00edbrio entre <strong>Velocidade de pesquisa<\/strong> e \u00e0 mem\u00f3ria livre de forma muito direta.<\/p>\n\n<h2>Como funciona o cache VFS em pormenor?<\/h2>\n\n<p>O Sistema de Ficheiros Virtual constitui uma camada comum para os sistemas de ficheiros ext4, XFS, Btrfs e outros, e armazena <strong>Dentries<\/strong> e inodes na RAM, para que as an\u00e1lises de diret\u00f3rios e os acessos recorrentes se mantenham r\u00e1pidos. Por outro lado, a cache de p\u00e1ginas armazena os blocos de ficheiros propriamente ditos; ambas as caches complementam-se, mas competem pela mem\u00f3ria quando sob press\u00e3o. Quanto mais ficheiros pequenos e acessos repetidos frequentes houver, mais a aplica\u00e7\u00e3o beneficia de uma elevada taxa de acertos nos metadados. \u00c9 precisamente aqui que o vm.vfs_cache_pressure entra em a\u00e7\u00e3o: posso determinar se o Linux mant\u00e9m esses metadados ou os liberta rapidamente. Para aspetos mais aprofundados do cache de p\u00e1ginas, utilizo adicionalmente o compacto <a href=\"https:\/\/webhosting.de\/pt\/otimizador-de-desempenho-do-cache-de-paginas-do-linux\/\">Otimizador de desempenho do cache de p\u00e1ginas<\/a> como conhecimento de base, para que eu possa avaliar o VFS e a cache de p\u00e1ginas no contexto.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxcachemeeting1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Valor padr\u00e3o e intervalos de valores t\u00edpicos<\/h2>\n\n<p>Na maioria dos sistemas, o valor est\u00e1 definido em <strong>100<\/strong> e constitui, assim, uma base equilibrada para os primeiros testes. Se reduzir o valor, dou prioridade aos metadados e estabilizo as pesquisas r\u00e1pidas, o que \u00e9 especialmente eficaz quando h\u00e1 muitos ficheiros pequenos. Se aumentar o valor, o Linux elimina as entradas do VFS mais rapidamente e cria mais buffer para as aplica\u00e7\u00f5es ou para a cache de p\u00e1ginas. Lido com valores extremos, como 0 ou valores superiores a 500, com muita cautela, uma vez que podem desencadear comportamentos dr\u00e1sticos e provocar efeitos secund\u00e1rios. No dia a dia, come\u00e7o com 100, vou avan\u00e7ando em incrementos de 20 a 40 pontos e avalio o impacto sobre <strong>Lat\u00eancia de E\/S<\/strong> e tempos de resposta.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Valor<\/th>\n      <th>Significado<\/th>\n      <th>Quando utilizar<\/th>\n      <th>Risco\/Aviso<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>&lt; 100 (por exemplo, 50\u201380)<\/td>\n      <td>A cache VFS permanece mais tempo na RAM<\/td>\n      <td>Muitos ficheiros pequenos, consultas frequentes<\/td>\n      <td>Maior utiliza\u00e7\u00e3o da RAM em <strong>Metadados<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>100<\/td>\n      <td>Ajustamento equilibrado<\/td>\n      <td>Valor inicial fi\u00e1vel para as medi\u00e7\u00f5es<\/td>\n      <td>Bom <strong>Linha de base<\/strong>valor \u2011<\/td>\n    <\/tr>\n    <tr>\n      <td>&gt; 100 (por exemplo, 120\u2013200)<\/td>\n      <td>O VFS-Cache \u00e9 libertado de forma mais agressiva<\/td>\n      <td>Mem\u00f3ria RAM escassa, bases de dados com cache pr\u00f3prio<\/td>\n      <td>Poss\u00edvel lat\u00eancia de pesquisa<\/td>\n    <\/tr>\n    <tr>\n      <td>Extremo (0, &gt; 500)<\/td>\n      <td>Mudan\u00e7as significativas<\/td>\n      <td>Casos especiais: teste r\u00e1pido<\/td>\n      <td>Risco para a estabilidade e <strong>Desempenho<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Com este esquema, consigo perceber rapidamente qual \u00e9 a dire\u00e7\u00e3o certa, sem me deixar levar pelo entusiasmo. Evito saltos muito grandes e registo cada altera\u00e7\u00e3o em pormenor. Assim, o percurso percorrido permanece sempre claro e consigo manter uma compara\u00e7\u00e3o precisa com os pontos de medi\u00e7\u00e3o anteriores.<\/p>\n\n<h2>Papel na limpeza da mem\u00f3ria<\/h2>\n\n<p>Quando est\u00e1 sob press\u00e3o, o kernel tem de libertar mem\u00f3ria RAM, e \u00e9 precisamente aqui que vm.vfs_cache_pressure define a pondera\u00e7\u00e3o entre <strong>Cache VFS<\/strong>, cache de p\u00e1ginas e mem\u00f3ria de processos. Valores baixos mant\u00eam as entradas de diret\u00f3rio e inodes na mem\u00f3ria por mais tempo, o que agiliza as chamadas aos diret\u00f3rios e as aberturas repetidas de ficheiros. Valores elevados libertam a mem\u00f3ria mais cedo e disponibilizam mais espa\u00e7o para processos ou para o cache de p\u00e1ginas, o que pode ser \u00fatil quando a RAM \u00e9 escassa. Nesse contexto, observo especificamente as lat\u00eancias de E\/S, uma vez que um cache de metadados demasiado vazio atrasa a pesquisa de ficheiros. No que diz respeito \u00e0 intera\u00e7\u00e3o com estrat\u00e9gias de liberta\u00e7\u00e3o do cache de p\u00e1ginas, esta informa\u00e7\u00e3o d\u00e1-me uma vis\u00e3o sobre <a href=\"https:\/\/webhosting.de\/pt\/servidor-despejo-de-cache-de-pagina-linux-memoria-impressao-otimizacao-insight\/\">Expuls\u00e3o da cache de p\u00e1ginas<\/a> refer\u00eancias pr\u00e1ticas valiosas, para que eu possa tomar decis\u00f5es com base em factos.<\/p>\n\n<h2>Metodologia de medi\u00e7\u00e3o: tornar a cache VFS transparente<\/h2>\n\n<p>Antes de alterar, vou tornar vis\u00edvel, <strong>onde<\/strong> est\u00e1 no armazenamento e <strong>o que<\/strong> \u00e9 suplantado. \u00c9 assim que consigo perceber se os metadados s\u00e3o realmente o gargalo \u2013 ou se o cache de p\u00e1ginas, os processos ou as p\u00e1ginas sujas s\u00e3o os principais fatores.<\/p>\n\n<ul>\n  <li><strong>\/proc\/meminfo<\/strong>: Analiso os par\u00e2metros InodeCache, Cached, Buffers, SReclaimable e SUnreclaim para avaliar a propor\u00e7\u00e3o e a recuperabilidade.<\/li>\n  <li><strong>tampo da laje<\/strong>: Visualiza\u00e7\u00e3o em tempo real dos \u00abslabs\u00bb, nomeadamente \u00abdentry\u00bb, \u00abinode_cache\u00bb, \u00abext4_inode_cache\u00bb e \u00abxfs_inode\u00bb. Assim, consigo ver se os \u00abdentries\u00bb\/\u00abinodes\u00bb est\u00e3o a aumentar ou a diminuir.<\/li>\n  <li><strong>Caminho IO<\/strong>: Com o vmstat\/iostat, observo as lat\u00eancias de leitura e se os acessos ao disco aumentam durante as pesquisas.<\/li>\n<\/ul>\n\n<pre><code># Vis\u00e3o geral r\u00e1pida\ngrep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' \/proc\/meminfo\n\n# Distribui\u00e7\u00e3o dos slabs (ordenada por tamanho)\nsudo slabtop -s c\n\n# Filtrar apenas slabs do tipo dentry\/inode\ngrep -Ei 'dentry|inode' \/proc\/slabinfo | sort -k3 -nr | head\n\n# Tend\u00eancias de E\/S e mem\u00f3ria a cada segundo\nvmstat 1\niostat -x 1\n<\/code><\/pre>\n\n<p>Considero que a interpreta\u00e7\u00e3o \u00e9 clara: se o SReclaimable crescer juntamente com os blocos de dentry\/inode e, ao mesmo tempo, as lat\u00eancias de E\/S aumentarem <em>n\u00e3o<\/em>, o que confirma a exist\u00eancia de uma cache de metadados eficaz. Se estes valores descerem frequentemente para zero e subirem rapidamente devido a lat\u00eancias elevadas nos acessos ao diret\u00f3rio, \u00e9 prov\u00e1vel que o vm.vfs_cache_pressure esteja definido de forma demasiado agressiva.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cache-optimization-tips-5467.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Exemplo pr\u00e1tico: Ler e alterar o valor atual<\/h2>\n\n<p>A verifica\u00e7\u00e3o \u00e9 feita na linha de comandos em segundos e sem <strong>Reiniciar<\/strong>. Leio o valor real e, inicialmente, registo os valores de teste de forma tempor\u00e1ria, para poder implementar imediatamente os retrocessos na janela de teste. Para ajustes em ambiente de produ\u00e7\u00e3o, defino entradas no ficheiro \/etc\/sysctl.conf ou num ficheiro na pasta \/etc\/sysctl.d\/, recarrego o sistema e registo a altera\u00e7\u00e3o na minha documenta\u00e7\u00e3o. Testo cada n\u00edvel sob carga realista, e n\u00e3o apenas em modo inativo, para que os efeitos se tornem vis\u00edveis. Desta forma, garanto compara\u00e7\u00f5es \u00abantes e depois\u00bb precisas e avalio a altera\u00e7\u00e3o com base em indicadores mensur\u00e1veis.<\/p>\n\n<pre><code># Verificar o valor atual\ncat \/proc\/sys\/vm\/vfs_cache_pressure\n# ou\nsysctl vm.vfs_cache_pressure\n\n# Testar temporariamente (at\u00e9 ao rein\u00edcio)\nsudo sysctl -w vm.vfs_cache_pressure=60\n# Alternativamente\necho 60 | sudo tee \/proc\/sys\/vm\/vfs_cache_pressure\n\n# Definir de forma permanente\necho \"vm.vfs_cache_pressure = 60\" | sudo tee -a \/etc\/sysctl.conf\nsudo sysctl -p\n<\/code><\/pre>\n\n<h2>Otimiza\u00e7\u00e3o da cache no Linux: cen\u00e1rios relevantes<\/h2>\n\n<p>Em plataformas de alojamento com muitos recursos est\u00e1ticos, reposit\u00f3rios de ficheiros ou aplica\u00e7\u00f5es com mem\u00f3ria tamp\u00e3o pr\u00f3pria, vale a pena uma abordagem espec\u00edfica <strong>pondera\u00e7\u00e3o<\/strong> 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\u00e3o sobre a RAM e um grande cache de base de dados preferem valores mais elevados, para que os processos tenham espa\u00e7o. Avalio estes padr\u00f5es com base em dados de monitoriza\u00e7\u00e3o, para que as defini\u00e7\u00f5es se adaptem \u00e0 combina\u00e7\u00e3o real de acessos.<\/p>\n\n<h3>Servidor web com muitos ficheiros est\u00e1ticos<\/h3>\n<p>No que diz respeito a CSS, JS e imagens, prefiro manter os metadados por mais tempo no <strong>Cache<\/strong>. Valores entre 50 e 80 t\u00eam-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\u00e1fego e comparo os tempos de resposta antes e depois da altera\u00e7\u00e3o. Se as lat\u00eancias se mantiverem est\u00e1veis e os custos de pesquisa 404 diminu\u00edrem, estamos no caminho certo. Fico atento \u00e0 utiliza\u00e7\u00e3o da RAM para garantir que os processos tenham espa\u00e7o suficiente, apesar de um cache de metadados mais robusto.<\/p>\n\n<h3>Servidores de ficheiros ou sistemas NAS<\/h3>\n<p>Os acessos frequentes dos utilizadores e as mudan\u00e7as de diret\u00f3rio beneficiam de <strong>mais baixo<\/strong> at\u00e9 valores equilibrados. Se houver RAM suficiente, opto por valores entre 50 e 80; se a mem\u00f3ria for mais escassa, mantenho-me mais pr\u00f3ximo dos 100. Verifico se as listagens de diret\u00f3rios continuam fluidas e se os instant\u00e2neos\/c\u00f3pias de seguran\u00e7a n\u00e3o ocupam demasiado espa\u00e7o nas caches. Se a lat\u00eancia de E\/S aumentar nos picos, ajusto cuidadosamente para um valor mais elevado. Desta forma, mantenho o equil\u00edbrio entre conforto e mem\u00f3ria livre.<\/p>\n\n<h3>Servidores de bases de dados e sistemas com pouca mem\u00f3ria<\/h3>\n<p>As bases de dados mant\u00eam o seu pr\u00f3prio buffer-cache, por isso atribuo ao <strong>Mem\u00f3ria de processo<\/strong> na maioria das vezes, tem prioridade. Valores entre 120 e 200 indicam que se deve esvaziar as caches VFS para libertar mem\u00f3ria RAM. Nesse contexto, presto aten\u00e7\u00e3o \u00e0s lat\u00eancias das consultas e aos padr\u00f5es de falhas de p\u00e1gina da aplica\u00e7\u00e3o. Se a base de dados ficar mais lenta porque o sistema come\u00e7a a utilizar a mem\u00f3ria de troca, aumentei ligeiramente o valor e, ao mesmo tempo, reduzi o vm.swappiness. Esta abordagem evita que os metadados ocupem espa\u00e7o desnecessariamente, espa\u00e7o esse que a base de dados pode utilizar de forma mais eficiente.<\/p>\n\n<h2>Exemplos de carga de trabalho e valores de refer\u00eancia<\/h2>\n\n<p>Come\u00e7o com 100 e vou reduzindo em incrementos de 20 para valores pr\u00f3ximos da web <strong>Cargas de trabalho<\/strong> e aumento em incrementos de 20 para processos que exigem muita mem\u00f3ria. Testo cada n\u00edvel, pelo menos, durante uma fase de pico, para poder identificar os efeitos nas lat\u00eancias, nos acertos de cache e na atividade de swap. Quem quiser aprofundar o assunto, encontrar\u00e1 no compacto <a href=\"https:\/\/webhosting.de\/pt\/otimizador-de-desempenho-do-cache-de-paginas-do-linux\/\">Otimizador de desempenho do cache de p\u00e1ginas<\/a> informa\u00e7\u00f5es complementares sobre estrat\u00e9gias de cache de ficheiros, que tenho em conta em paralelo. Se os valores medidos corresponderem aos valores-alvo, fixo a configura\u00e7\u00e3o e documento os indicadores. Desta forma, a otimiza\u00e7\u00e3o permanece reproduz\u00edvel e posso fazer reajustes rapidamente mais tarde.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux_cache_nutzung_4387.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riscos e armadilhas<\/h2>\n\n<p>Se definir um valor demasiado baixo, o kernel ter\u00e1 dificuldade em libertar entradas do VFS, o que, em picos de <strong>OOM<\/strong>\u2011riscos. Se o aumentar demasiado, a lat\u00eancia nas pesquisas de ficheiros e nas mudan\u00e7as de diret\u00f3rio aumenta, porque os metadados t\u00eam de ser recarregados. Sem testes sob carga real, corre-se o risco de tirar conclus\u00f5es erradas a partir de intervalos de tempo com pouca atividade. Os saltos abruptos dificultam a avalia\u00e7\u00e3o, pelo que procedo de forma gradual. Registo cada altera\u00e7\u00e3o com a data e hora, o perfil de carga e os valores medidos, para que as causas fiquem claras.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e indicadores<\/h2>\n\n<p>S\u00e3o os dados concretos que mostram se vale a pena fazer um ajuste <strong>M\u00e9tricas<\/strong>. Observo a utiliza\u00e7\u00e3o da RAM, a distribui\u00e7\u00e3o entre caches e processos, as lat\u00eancias de E\/S e a atividade de swap. Al\u00e9m disso, analiso as taxas de acerto do cache e as tend\u00eancias de falhas de p\u00e1gina para detetar rapidamente efeitos colaterais. Especialmente no caso de muitos ficheiros pequenos, as melhorias no \u00abTime-to-First-Byte\u00bb tornam-se evidentes. Se a lat\u00eancia de E\/S se mantiver baixa e o swap diminuir, isso confirma que estamos no caminho certo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxcache_4242.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Manual de afina\u00e7\u00e3o: Da hip\u00f3tese \u00e0 configura\u00e7\u00e3o fi\u00e1vel<\/h2>\n\n<p>A estrutura evita que se avance \u00e0s cegas. Sigo um procedimento definido para que os resultados sejam fi\u00e1veis e para que os colegas de equipa possam compreender os passos a seguir.<\/p>\n\n<ol>\n  <li><strong>Registar o valor de refer\u00eancia<\/strong>: vm.vfs_cache_pressure=100, carga realista de 24 a 72 horas. Guardar os indicadores-chave (lat\u00eancias: mediana\/95.\u00ba\/99.\u00ba percentil, tempo de espera de E\/S, \u00abCPU-Steal\u00bb, atividade de swap, tamanho de inode\/dentry).<\/li>\n  <li><strong>Formular uma hip\u00f3tese<\/strong>: \u201eMuitos ficheiros pequenos, as consultas s\u00e3o dispendiosas \u2013 valores mais baixos aceleram\u201c ou \u201eMem\u00f3ria RAM escassa \u2013 valores mais altos mant\u00eam os processos livres\u201c.<\/li>\n  <li><strong>Alterar passo a passo<\/strong>: \u00b120 a \u00b140 pontos. Medir, pelo menos, uma fase de pico por n\u00edvel.<\/li>\n  <li><strong>Comparar<\/strong>: Verifico se os SLOs (por exemplo, o percentil 95) melhoram de forma fi\u00e1vel, <em>sem<\/em> Mais eventos de swap ou OOM.<\/li>\n  <li><strong>Crit\u00e9rio de revers\u00e3o<\/strong>: Se as lat\u00eancias 95.\/99. aumentarem, os tempos de espera da E\/S se prolongarem ou as falhas de cache se multiplicarem, dou um passo atr\u00e1s.<\/li>\n  <li><strong>Freeze e documenta\u00e7\u00e3o<\/strong>: Registar o valor final, a data, a janela de carga e os indicadores.<\/li>\n<\/ol>\n\n<pre><code># Teste r\u00e1pido para janelas de medi\u00e7\u00e3o controladas (apenas para manuten\u00e7\u00e3o!)\n# Antes: Capturar instant\u00e2neos dos indicadores\ndate; free -h; grep -E 'InodeCache|Cached' \/proc\/meminfo; vmstat 1 5\n\nsudo sysctl -w vm.vfs_cache_pressure=80\n# Teste de carga\/aguardar o pico, depois voltar a registar as m\u00e9tricas e comparar\n<\/code><\/pre>\n\n<h2>Sistemas de ficheiros e op\u00e7\u00f5es de montagem: o contexto \u00e9 importante<\/h2>\n\n<p>O efeito do vm.vfs_cache_pressure depende tamb\u00e9m do sistema de ficheiros e das op\u00e7\u00f5es de montagem. Avalio estes fatores da seguinte forma:<\/p>\n\n<ul>\n  <li><strong>tempo de rela\u00e7\u00e3o\/tempo de inatividade<\/strong>: Evita grava\u00e7\u00f5es 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.<\/li>\n  <li><strong>hora da pregui\u00e7a<\/strong>: Atrasa as atualiza\u00e7\u00f5es de metadados na RAM; isto suaviza os picos, mas interage com os momentos de limpeza.<\/li>\n  <li><strong>ext4 vs. XFS vs. Btrfs<\/strong>: Diferentes estruturas de inodes e comportamentos do Shrinker. Eu medo sempre <em>no FS de destino<\/em>, em vez de transmitir suposi\u00e7\u00f5es.<\/li>\n  <li><strong>NFS\/Sistema de Ficheiros em Rede<\/strong>: O armazenamento em cache e a invalida\u00e7\u00e3o de atributos podem limitar os benef\u00edcios do VFS. A liberta\u00e7\u00e3o agressiva (valores elevados) faz com que as consultas remotas aumentem.<\/li>\n  <li><strong>OverlayFS\/FUSE<\/strong>: Muitas pequenas opera\u00e7\u00f5es de metadados beneficiam bastante da cache VFS; considero que os valores devem ser moderados a baixos, desde que haja RAM dispon\u00edvel.<\/li>\n<\/ul>\n\n<h2>Aspectos relacionados com os contentores e os cgroups<\/h2>\n\n<p>Em ambientes de contentores, tenho sempre em mente que: vm.vfs_cache_pressure \u00e9 um <strong>em todo o servidor<\/strong> Bot\u00e3o. As altera\u00e7\u00f5es dizem respeito a <em>todos<\/em> Pods\/contentores no n\u00f3. Por isso, opto por uma abordagem conservadora e coordeno o ajuste ao n\u00edvel do n\u00f3.<\/p>\n\n<ul>\n  <li><strong>Limites de armazenamento<\/strong>: Os Memory-Cgroups limitam a mem\u00f3ria do processo e a cache de p\u00e1ginas; a mem\u00f3ria Slab pode ser contabilizada proporcionalmente. Tenho observado eventos Pod-OOM e Node-Pressure relacionados com isto.<\/li>\n  <li><strong>Combina\u00e7\u00e3o de cargas de trabalho<\/strong>: Os n\u00f3s que t\u00eam simultaneamente DB-Pods e front-ends web n\u00e3o atingem valores extremos. Se for necess\u00e1rio, distribuo as fun\u00e7\u00f5es por diferentes n\u00f3s.<\/li>\n  <li><strong>Lan\u00e7amento<\/strong>: Primeiro nas Canaries (um n\u00f3) e, depois, implementa\u00e7\u00e3o gradual. Documento as altera\u00e7\u00f5es na linha de base do n\u00f3 (sysctl.d) e indico as implementa\u00e7\u00f5es afetadas.<\/li>\n<\/ul>\n\n<h2>Casos especiais da pr\u00e1tica<\/h2>\n\n<p>\u00c9 poss\u00edvel abordar alguns padr\u00f5es de forma espec\u00edfica, se eu conhecer as causas:<\/p>\n\n<ul>\n  <li><strong>Tarefas de CI\/Build<\/strong>: Muitos acessos curtos a ficheiros e an\u00e1lises de diret\u00f3rios beneficiam de valores mais baixos. Volto a aument\u00e1-los ap\u00f3s a conclus\u00e3o da tarefa, caso os n\u00f3s sejam utilizados de forma mista.<\/li>\n  <li><strong>Janela de c\u00f3pia de seguran\u00e7a\/an\u00e1lise<\/strong>: As pesquisas prolongadas em diret\u00f3rios esvaziam as caches. Temporariamente, um <em>mais elevado<\/em> Valor (por exemplo, 180) para impedir que os dentries\/inodes encham a RAM durante a c\u00f3pia de seguran\u00e7a \u2013 depois, volto a definir o valor inicial.<\/li>\n  <li><strong>Entradas negativas<\/strong>: Os ficheiros inexistentes (404) tamb\u00e9m s\u00e3o armazenados em cache. As cargas de trabalho Web com acessos falhados frequentes beneficiam de forma mensur\u00e1vel quando o cache VFS n\u00e3o \u00e9 esvaziado de forma demasiado agressiva.<\/li>\n  <li><strong>Streaming\/E\/S sequencial<\/strong>: Aqui, o Page Cache \u00e9 o fator dominante; valores demasiado baixos t\u00eam pouco efeito e ocupam RAM desnecessariamente. Eu mantenho-o perto de 100 ou um pouco acima.<\/li>\n<\/ul>\n\n<pre><code># Exemplo: tornar-se um pouco mais agressivo durante um backup completo\nsudo sysctl -w vm.vfs_cache_pressure=180\n# Ap\u00f3s o backup, voltar ao valor \u00f3timo determinado anteriormente\nsudo sysctl -w vm.vfs_cache_pressure=60\n<\/code><\/pre>\n\n<h2>Automatiza\u00e7\u00e3o e governa\u00e7\u00e3o<\/h2>\n\n<p>Ap\u00f3s testes bem-sucedidos, incorporo essa configura\u00e7\u00e3o nas minhas compila\u00e7\u00f5es padr\u00e3o. \u00c9 importante que as equipas saibam que, <em>por que<\/em> foi selecionado um valor e <em>quando<\/em> que deve ser verificado (por exemplo, ap\u00f3s mudan\u00e7as de vers\u00e3o ou de carga de trabalho).<\/p>\n\n<ul>\n  <li><strong>Gest\u00e3o da configura\u00e7\u00e3o<\/strong>: Costumo definir valores predefinidos por fun\u00e7\u00e3o (Web, base de dados, servidor de ficheiros) em \/etc\/sysctl.d\/ e distribu\u00ed-los de forma centralizada.<\/li>\n  <li><strong>Controlo de derrapagem<\/strong>: As auditorias regulares verificam se os valores em tempo real e o reposit\u00f3rio est\u00e3o em conformidade.<\/li>\n  <li><strong>Livros de execu\u00e7\u00e3o<\/strong>: Documento os passos de medi\u00e7\u00e3o, os valores-limite para o rollback e os procedimentos de emerg\u00eancia (por exemplo, repor para 100).<\/li>\n<\/ul>\n\n<pre><code># Fun\u00e7\u00e3o: Servidor Web (exemplo)\ncat &lt;&lt;&#039;EOF&#039; | sudo tee \/etc\/sysctl.d\/50-web-vfs.conf\nvm.vfs_cache_pressure = 60\nEOF\nsudo sysctl --system\n<\/code><\/pre>\n\n<h2>vm.vfs_cache_pressure e outros par\u00e2metros do kernel<\/h2>\n\n<p>Um bom resultado s\u00f3 surge quando se combina com <strong>vm.swappiness<\/strong> e os valores-limite das p\u00e1ginas sujas. Um valor mais baixo de swappiness (por exemplo, 10\u201320) mant\u00e9m os processos na RAM e evita a transfer\u00eancia desnecess\u00e1ria para a mem\u00f3ria externa. Com vm.dirty_background_ratio e vm.dirty_ratio, regulo a rapidez com que o sistema grava as p\u00e1ginas alteradas, para que os picos de escrita n\u00e3o bloqueiem tudo. Ajusto estes valores de forma a que as pesquisas de metadados se mantenham r\u00e1pidas e as opera\u00e7\u00f5es de grava\u00e7\u00e3o decorram de forma planeada. Utilizo aqui uma vis\u00e3o geral concisa sobre a intera\u00e7\u00e3o entre as caches de ficheiros: <a href=\"https:\/\/webhosting.de\/pt\/sistema-de-ficheiros-cache-linux-cache-de-pagina-cacheboost\/\">Vis\u00e3o geral do armazenamento em cache do sistema de ficheiros<\/a>.<\/p>\n\n<h2>Recomenda\u00e7\u00f5es para ambientes de alojamento e o WordPress<\/h2>\n\n<p>Muitos temas, plugins e ficheiros multim\u00e9dia geram in\u00fameros ficheiros pequenos, raz\u00e3o pela qual \u00e9 necess\u00e1rio um <strong>Cache VFS<\/strong> ajuda significativamente. Come\u00e7o com 100, reduzo para 80 quando a RAM for suficiente, depois para 60, e verifico os tempos de resposta, o percentil 95 das lat\u00eancias e o \u00abCPU-Steal\u00bb. Se a mem\u00f3ria continuar a ser suficiente, testo o valor 50 e volto a validar durante o pico da noite ou durante as campanhas. Se as lat\u00eancias diminu\u00edrem sem que o swap ou o OOM Killer sejam acionados, fixo essa configura\u00e7\u00e3o de forma permanente. Paralelamente, mantenho o cacho de p\u00e1ginas sob vigil\u00e2ncia, para que ambos os caches se complementem de forma eficaz.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cache-optimierung-7834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumo<\/h2>\n\n<p>Com o vm.vfs_cache_pressure, controlo o <strong>Equil\u00edbrio<\/strong> de forma muito espec\u00edfica, entre pesquisas r\u00e1pidas de metadados e mem\u00f3ria RAM livre. Para cargas de trabalho relacionadas com a Web, reduzo o valor moderadamente; para aplica\u00e7\u00f5es que consomem muita mem\u00f3ria, aumentei-o. Justifico cada altera\u00e7\u00e3o com valores de medi\u00e7\u00e3o relativos a lat\u00eancias de E\/S, acertos de cache e atividade de swap. Em combina\u00e7\u00e3o com o vm.swappiness e os par\u00e2metros \u00abdirty\u00bb, consigo uma gest\u00e3o de mem\u00f3ria est\u00e1vel. Assim, utilizo o cache do sistema de ficheiros do Linux de forma eficiente e mantenho os tempos de resposta baixos de forma fi\u00e1vel, mesmo sob carga.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como, utilizando \u00abvm.vfs_cache_pressure\u00bb como palavra-chave principal, pode tirar o m\u00e1ximo partido da cache do sistema de ficheiros do Linux, gerir as caches de forma espec\u00edfica e melhorar o desempenho das cargas de trabalho dos seus servidores.<\/p>","protected":false},"author":1,"featured_media":20867,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20874","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"134","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"vm.vfs_cache_pressure","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20867","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20874","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20874"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20874\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20867"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20874"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20874"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20874"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}