{"id":20540,"date":"2026-08-11T11:56:13","date_gmt":"2026-08-11T09:56:13","guid":{"rendered":"https:\/\/webhosting.de\/linux-page-cache-performance-booster\/"},"modified":"2026-08-11T11:56:13","modified_gmt":"2026-08-11T09:56:13","slug":"otimizador-de-desempenho-do-cache-de-paginas-do-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-page-cache-performance-booster\/","title":{"rendered":"Compreender a cache de p\u00e1ginas do Linux: maior desempenho gra\u00e7as \u00e0 cache"},"content":{"rendered":"<p><strong>P\u00e1gina do Linux<\/strong> Entendo a cache como um mecanismo direto para um acesso mais r\u00e1pido aos ficheiros, uma vez que permite que as leituras repetidas sejam feitas a partir da RAM, em vez de a partir de um armazenamento mais lento. Vou mostrar, concretamente, como o kernel reduz assim as lat\u00eancias, acelera cargas de trabalho como servidores web, bases de dados e o WordPress, e como aproveito esse efeito com meios simples.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<p>As seguintes ideias-chave ajudam-me a compreender o <strong>Cache de p\u00e1gina<\/strong> avaliar e utilizar de forma espec\u00edfica.<\/p>\n<ul>\n  <li><strong>Cache de RAM<\/strong>: Os dados dos ficheiros s\u00e3o armazenados na mem\u00f3ria, o que reduz o tempo de acesso.<\/li>\n  <li><strong>Revers\u00e3o<\/strong>: As opera\u00e7\u00f5es de escrita agrupam-se de forma mais eficiente como \u201ep\u00e1ginas sujas\u201c.<\/li>\n  <li><strong>Transpar\u00eancia<\/strong>: As aplica\u00e7\u00f5es beneficiam sem necessidade de altera\u00e7\u00f5es no c\u00f3digo.<\/li>\n  <li><strong>Din\u00e2mica<\/strong>: A cache liberta mem\u00f3ria quando necess\u00e1rio.<\/li>\n  <li><strong>Cargas de trabalho<\/strong>: A Web, as bases de dados, a CI\/CD e os registos registam ganhos significativos.<\/li>\n<\/ul>\n\n<h2>O que \u00e9 o cache de p\u00e1ginas do Linux?<\/h2>\n\n<p>Eu compreendo o <strong>Cache de p\u00e1gina<\/strong> como uma \u00e1rea de mem\u00f3ria na RAM, na qual o kernel armazena blocos de ficheiros assim que os processos, atrav\u00e9s de <code>read()<\/code>, <code>write()<\/code> ou <code>mmap()<\/code> aceder a ficheiros. Sempre que ocorre um acesso, o kernel verifica primeiro a cache e fornece imediatamente os dados a partir da mem\u00f3ria, caso j\u00e1 se encontrem l\u00e1, o que reduz significativamente o tempo de resposta. Se os dados n\u00e3o estiverem na cache, o kernel carrega-os do suporte de dados, armazena-os na cache e disponibiliza-os ao processo, o que permite um acesso mais r\u00e1pido na pr\u00f3xima vez que forem solicitados. Este mecanismo est\u00e1 intimamente ligado ao Sistema de Ficheiros Virtual e funciona de forma transparente para as aplica\u00e7\u00f5es, o que torna a sua utiliza\u00e7\u00e3o universal. Desta forma de funcionamento decorre um princ\u00edpio simples: utilizo a RAM livre como <strong>\u00c1rea de cache<\/strong> em vez de o deixar sem uso.<\/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-page-cache-performance-5830.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Por que \u00e9 que a cache de p\u00e1ginas acelera visivelmente o desempenho<\/h2>\n\n<p>O maior efeito deve-se ao facto de eu <strong>E\/S de disco<\/strong> reduzo drasticamente, assim que os dados recorrentes se encontram na cache e n\u00e3o precisam de ser lidos novamente a partir do suporte de dados. Os acessos de leitura s\u00e3o ent\u00e3o realizados a partir da RAM, o que reduz significativamente as lat\u00eancias e as filas nos controladores. Os percursos de grava\u00e7\u00e3o tamb\u00e9m beneficiam, porque o kernel marca as altera\u00e7\u00f5es como \u201ep\u00e1ginas sujas\u201c, agrupa-as temporariamente e, posteriormente, grava-as de forma eficiente no suporte. Assim, desaparecem muitos pequenos acessos individuais, que sobrecarregariam o armazenamento, em favor de um n\u00famero menor de opera\u00e7\u00f5es de maior dimens\u00e3o. Em suma, ap\u00f3s uma breve fase de aquecimento, o sistema parece mais r\u00e1pido, porque h\u00e1 mais dados de trabalho na <strong>Mem\u00f3ria<\/strong> permanecer.<\/p>\n\n<h2>Ler, escrever, \u00abDirty Pages\u00bb: \u00e9 assim que funciona<\/h2>\n\n<p>Um acesso de leitura come\u00e7a sempre com uma verifica\u00e7\u00e3o da cache, o que me permite obter acertos sem tempo de espera e em que os erros t\u00eam um custo \u00fanico. Na grava\u00e7\u00e3o, o conte\u00fado alterado vai primeiro para a RAM e fica em espera como \u201edirty\u201c at\u00e9 que o kernel o transfira, de forma agrupada, para o suporte de dados. Se desejar, posso for\u00e7ar o armazenamento permanente com <code>fsync()<\/code>, o que continua a ser importante quando se trata de dados <strong>Consist\u00eancia<\/strong> precisam imediatamente. Este percurso de \u00abwrite-back\u00bb aumenta a efici\u00eancia das aplica\u00e7\u00f5es que lidam com muitos ficheiros pequenos, como c\u00f3digo PHP, ficheiros de configura\u00e7\u00e3o ou recursos. Ao mesmo tempo, tenho em conta que o \u00abwrite-back\u00bb melhora o desempenho, mas que existe um curto per\u00edodo de tempo durante o qual nem tudo est\u00e1 ainda fisicamente guardado.<\/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_Page_Cache_3892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>A RAM livre \u00e9 cache \u2013 n\u00e3o h\u00e1 perda<\/h2>\n\n<p>Muitos encaram a mem\u00f3ria \u201eocupada\u201c com ceticismo, mas eu interpreto o valor corretamente, considerando a percentagem \u201ebuff\/cache\u201c como um indicador significativo <strong>mem\u00f3ria tempor\u00e1ria<\/strong> valores. O kernel utiliza ativamente a RAM n\u00e3o utilizada, devolve-a aos processos num piscar de olhos quando necess\u00e1rio e controla o equil\u00edbrio atrav\u00e9s de mecanismos de recupera\u00e7\u00e3o. Esta din\u00e2mica garante que o meu sistema reaja rapidamente, desde que haja um conjunto de trabalho suficiente na cache. Se a necessidade de uma aplica\u00e7\u00e3o aumentar, o kernel substitui as p\u00e1ginas antigas da cache e cria espa\u00e7o, sem que eu tenha de intervir manualmente. Quando entro em fases de elevada carga, observo isso com foco em <a href=\"https:\/\/webhosting.de\/pt\/pressao-de-memoria-kernel-do-linux-sistemas-de-alojamento-otimizacao-ram\/\">Press\u00e3o do reservat\u00f3rio<\/a>, para avaliar corretamente a situa\u00e7\u00e3o e classificar os pontos de estrangulamento.<\/p>\n\n<h2>Cargas de trabalho que beneficiam significativamente<\/h2>\n\n<p>Vejo as maiores vantagens em todos os casos em que os dados se repetem frequentemente e se verificam muitos pequenos acessos, o que faz com que o <strong>Cache<\/strong> simplificado. Exemplos cl\u00e1ssicos s\u00e3o servidores Web com ficheiros PHP e HTML frequentemente utilizados, bem como instala\u00e7\u00f5es do WordPress com temas, plugins, ficheiros multim\u00e9dia e configura\u00e7\u00f5es recorrentes. As bases de dados beneficiam de consultas repetidas ao n\u00edvel do sistema de ficheiros, desde que n\u00e3o contornem deliberadamente o cache de p\u00e1ginas. Os sistemas CI\/CD com artefactos de compila\u00e7\u00e3o, bem como as ferramentas que lidam com muitos ficheiros pequenos, tamb\u00e9m ficam visivelmente mais r\u00e1pidos. At\u00e9 mesmo as an\u00e1lises de registos, que s\u00e3o lidas sequencialmente, ganham vantagem gra\u00e7as aos buffers de RAM, uma vez que o kernel antecipa os padr\u00f5es de acesso e os disponibiliza mais rapidamente.<\/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-page-cache-performance-3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e medi\u00e7\u00e3o: \u00e9 assim que avalio os efeitos da cache<\/h2>\n\n<p>Come\u00e7o por verificar com <code>livre -h<\/code>, qual \u00e9 o tamanho do \u201ebuff\/cache\u201c e como \u00e9 que <strong>ocupado<\/strong> A mem\u00f3ria evoluiu ao longo do tempo. Um olhar sobre <code>\/proc\/meminfo<\/code> mostra-me indicadores como <code>Em cache<\/code>, <code>Sujo<\/code> e <code>Writeback<\/code>, que fornecem informa\u00e7\u00f5es sobre acessos de leitura e opera\u00e7\u00f5es de grava\u00e7\u00e3o pendentes. Com <code>iostat -x 1<\/code> ou <code>pidstat -d 1<\/code> percebo se a carga de E\/S f\u00edsica diminui assim que a minha cache estiver aquecida. Ferramentas como <code>perfeito<\/code> ou <code>cco<\/code>Os scripts baseados em - ajudam a aprofundar a an\u00e1lise, mas raramente s\u00e3o necess\u00e1rios no dia a dia, quando se observam padr\u00f5es claros. Al\u00e9m disso, testo, atrav\u00e9s de acessos repetidos aos ficheiros, se a segunda execu\u00e7\u00e3o \u00e9 significativamente mais r\u00e1pida, o que demonstra o efeito do <strong>Caches<\/strong> confirmado.<\/p>\n\n<h2>Ajuste: par\u00e2metros e valores predefinidos recomendados<\/h2>\n\n<p>Apenas ajusto o que compreendo e, no que diz respeito ao ajuste da cache, come\u00e7o com algumas op\u00e7\u00f5es simples e f\u00e1ceis de compreender <strong>Parafusos de regula\u00e7\u00e3o<\/strong>. Os par\u00e2metros vm.dirty controlam a partir de quando as opera\u00e7\u00f5es de grava\u00e7\u00e3o passam da RAM para o suporte de armazenamento e com que intensidade esse processo decorre. <code>vm.vfs_cache_pressure<\/code> Determina o grau em que o kernel substitui as caches de Dentry e Inode, o que influencia diretamente as opera\u00e7\u00f5es do sistema de ficheiros. Os valores de readahead ao n\u00edvel dos dispositivos de bloco podem aumentar o desempenho de leitura sequencial, caso as cargas de trabalho beneficiem disso. Documento cada passo, testo sob carga e, se necess\u00e1rio, volto aos valores iniciais caso n\u00e3o se verifique qualquer melhoria.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Par\u00e2metros<\/strong><\/th>\n      <th><strong>Padr\u00e3o<\/strong><\/th>\n      <th><strong>Efeito<\/strong><\/th>\n      <th><strong>Quando alterar<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>10%<\/td>\n      <td>In\u00edcio da fase de grava\u00e7\u00e3o as\u00edncrona<\/td>\n      <td>Em caso de muitas grava\u00e7\u00f5es pequenas, permitir que se acumulem mais cedo<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>20%<\/td>\n      <td>Percentagem m\u00e1xima de \u201edirty\u201c na RAM<\/td>\n      <td>Permitir mais margem de seguran\u00e7a em caso de picos de carga<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>3000<\/td>\n      <td>Tempo de \u201edirty\u201c at\u00e9 ao flush (em 1\/100 s)<\/td>\n      <td>No caso de objetivos de lat\u00eancia, definir um valor mais baixo<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisegundos<\/td>\n      <td>500<\/td>\n      <td>Intervalo para o write-back em segundo plano<\/td>\n      <td>Se o armazenamento estiver lento, aumente um pouco a velocidade<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.vfs_cache_pressure<\/td>\n      <td>100<\/td>\n      <td>Necessidade de limpar os dentries\/inodes<\/td>\n      <td>Em muitas opera\u00e7\u00f5es com ficheiros, reduzir<\/td>\n    <\/tr>\n    <tr>\n      <td>Leitura antecipada em blocos<\/td>\n      <td>dependendo do dispositivo<\/td>\n      <td>Pr\u00e9-visualiza\u00e7\u00e3o sequencial de leitura<\/td>\n      <td>Aumentar nas leituras em streaming<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Para uma compreens\u00e3o mais aprofundada dos processos de recupera\u00e7\u00e3o e armazenamento, vale a pena dar uma vista de olhos em <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>, para avaliar de forma fundamentada a minha pr\u00f3pria configura\u00e7\u00e3o. Aplico sempre as altera\u00e7\u00f5es de forma gradual, acompanho-as atrav\u00e9s de pontos de medi\u00e7\u00e3o e documento claramente os efeitos, para que cada <strong>Personaliza\u00e7\u00e3o<\/strong> continue a ser compreens\u00edvel.<\/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\/LinuxCachePerformance5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cache de p\u00e1ginas e bases de dados: quando faz sentido contorn\u00e1-los<\/h2>\n\n<p>Algumas bases de dados recorrem deliberadamente a <strong>E\/S direta<\/strong> para evitar o armazenamento em buffer duplicado e utilizar os seus pr\u00f3prios caches. Nesses cen\u00e1rios, trabalho com os par\u00e2metros internos da base de dados e confio menos no cache de p\u00e1ginas do Linux. Se um motor aceder frequentemente a novos dados ou a volumes de trabalho muito grandes, vale a pena utilizar o modelo de bypass para manter o consumo de mem\u00f3ria mais previs\u00edvel. Por outro lado, se o foco estiver em leituras repetidas de ficheiros a partir das mesmas tabelas ou \u00edndices, o cache do sistema de ficheiros continua a ser \u00fatil. Tomo a decis\u00e3o com base no padr\u00e3o de acesso real, e n\u00e3o numa regra gen\u00e9rica, para que a <strong>Desempenho<\/strong> aumenta mesmo.<\/p>\n\n<h2>Desloca\u00e7\u00e3o, recupera\u00e7\u00e3o e press\u00e3o de mem\u00f3ria<\/h2>\n\n<p>Em condi\u00e7\u00f5es de elevada carga, o kernel classifica as p\u00e1ginas em ativas e inativas <strong>Listas LRU<\/strong> e retira gradualmente os candidatos da cache. Este processo de recupera\u00e7\u00e3o reage \u00e0 press\u00e3o resultante do aumento da procura por parte dos processos, dos limites do cgroup ou dos tempos de espera de E\/S. Se o meu sistema de monitoriza\u00e7\u00e3o detetar um aumento das evic\u00e7\u00f5es e, simultaneamente, um aumento da carga de E\/S, percebo que o conjunto de dados de trabalho \u00e9 maior do que a RAM dispon\u00edvel. Nessas fases, avalio se devo isolar cargas de trabalho, alterar estrat\u00e9gias de cache ou expandir a mem\u00f3ria. Para compreender as regras de liberta\u00e7\u00e3o de mem\u00f3ria, recorro a um guia estruturado sobre <a href=\"https:\/\/webhosting.de\/pt\/pressao-de-memoria-kernel-do-linux-sistemas-de-alojamento-otimizacao-ram\/\">Press\u00e3o do reservat\u00f3rio<\/a>, para interpretar corretamente os sintomas e planear medidas de resposta.<\/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_performance_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Na pr\u00e1tica: verifica\u00e7\u00f5es r\u00e1pidas e comandos<\/h2>\n\n<p>Para dar uma primeira impress\u00e3o, come\u00e7o por <code>livre -h<\/code> e ler a parte <strong>buff\/cache<\/strong>, antes de aprofundar o assunto. Depois, vou comparar duas execu\u00e7\u00f5es de uma an\u00e1lise de ficheiros, por exemplo, com <code>encontrar<\/code> ou um teste de desempenho, e observa a diferen\u00e7a de tempo entre o arranque a frio e o arranque a quente. <code>grep -E \"Cached|Dirty|Writeback\" \/proc\/meminfo<\/code> mostra-me quanto est\u00e1 no cache e o que ainda tem de ser gravado. <code>iostat -xz 1<\/code> revela o n\u00edvel de utiliza\u00e7\u00e3o dos dispositivos e se a fila diminui assim que a cache entra em a\u00e7\u00e3o. Quem quiser aprofundar os conceitos b\u00e1sicos do cache pode consultar a vis\u00e3o geral sobre <a href=\"https:\/\/webhosting.de\/pt\/sistema-de-ficheiros-cache-linux-cache-de-pagina-cacheboost\/\">Cache do sistema de ficheiros<\/a> um guia introdut\u00f3rio acess\u00edvel que explica a intera\u00e7\u00e3o entre o VFS e o buffer da RAM.<\/p>\n\n<h2>Esclarecer equ\u00edvocos comuns<\/h2>\n\n<p>\u201eA RAM est\u00e1 cheia, o servidor tem um problema\u201c, ou\u00e7o dizer muitas vezes, mas o <strong>Cache<\/strong> Esta \u00e9 a resposta, n\u00e3o a causa. O Linux liberta a mem\u00f3ria de forma flex\u00edvel quando as aplica\u00e7\u00f5es a ocupam e volta a ocup\u00e1-la assim que novos dados s\u00e3o armazenados temporariamente. O esvaziamento manual atrav\u00e9s de <code>echo 3 &gt; \/proc\/sys\/vm\/drop_caches<\/code> raramente traz benef\u00edcios duradouros e distorce as medi\u00e7\u00f5es. Faz mais sentido identificar os verdadeiros pontos cr\u00edticos e aliviar a carga nos percursos de E\/S nesses locais. Al\u00e9m disso, fa\u00e7o a distin\u00e7\u00e3o entre a cache de p\u00e1ginas e as caches \u00abslab\u00bb para dentries\/inodes, para n\u00e3o ter de lidar com duas diferentes <strong>Mecanismos<\/strong> coloque numa panela.<\/p>\n\n<h2>Op\u00e7\u00f5es de montagem e particularidades do sistema de ficheiros<\/h2>\n\n<p>Tenho em conta que as op\u00e7\u00f5es do sistema de ficheiros e de montagem influenciam significativamente a efici\u00eancia da cache de p\u00e1ginas. <strong>tempo<\/strong>- As atualiza\u00e7\u00f5es geram grava\u00e7\u00f5es adicionais; com <em>relatime<\/em> (hoje em dia, \u00e9 a norma) reduzo-as, <em>n\u00e3o h\u00e1 tempo<\/em> poupo ainda mais se nunca tiver de depender de hor\u00e1rios de acesso. <strong>sincroniza\u00e7\u00e3o<\/strong> e <strong>dirsync<\/strong> imp\u00f5em persist\u00eancia imediata e anulam as vantagens do write-back \u2013 s\u00e3o adequados para metadados em que a lat\u00eancia \u00e9 cr\u00edtica; caso contr\u00e1rio, evito-os. Modos de registo em di\u00e1rio (por exemplo, no ext4 <em>dados=ordenados<\/em> vs. <em>writeback<\/em>) influenciam se os dados \u00fateis s\u00e3o gravados no suporte antes ou depois dos metadados; prefiro a seguran\u00e7a ao desempenho aparente. O XFS e o btrfs comportam-se de forma diferente no que diz respeito aos metadados e ao CoW: o CoW, a compress\u00e3o ou a deduplica\u00e7\u00e3o poupam E\/S, mas podem consumir recursos da CPU. Por isso, avalio as cargas de trabalho de forma realista e decido se as op\u00e7\u00f5es de montagem correspondem ao padr\u00e3o de acesso.<\/p>\n\n<h2>Contentores, m\u00e1quinas virtuais e caches duplicados<\/h2>\n\n<p>Nos contentores, todos os processos partilham o mesmo kernel \u2013 e, por conseguinte, tamb\u00e9m o mesmo cache de p\u00e1ginas. Isto facilita a partilha de ficheiros frequentemente utilizados (por exemplo, bibliotecas), mas os limites rigorosos dos cgroups (<em>mem\u00f3ria.max<\/em>) podem substituir antecipadamente as p\u00e1ginas em cache. Prevejo uma margem de seguran\u00e7a para cada servi\u00e7o e utilizo <em>mem\u00f3ria.baixa<\/em>, para dar alguma prote\u00e7\u00e3o aos caches importantes. Nas m\u00e1quinas virtuais, existem <strong>dois<\/strong> Caches: no convidado e, se for o caso, no anfitri\u00e3o (no caso de backups de ficheiros). Isto leva a um armazenamento em buffer duplicado. Se utilizar dispositivos Raw ou Direct-Storage, evito o cache do anfitri\u00e3o, mas perco as suas vantagens. O ballooning e o overcommit influenciam a recupera\u00e7\u00e3o de espa\u00e7o no convidado \u2013 observo se o ballooning constante leva a cache thrashing e ajusto os recursos ou o dimensionamento. No caso do armazenamento em contentores (OverlayFS), pr\u00e9-aqueco as camadas utilizadas com frequ\u00eancia de forma seletiva, para que as implementa\u00e7\u00f5es n\u00e3o tenham de arrancar a frio.<\/p>\n\n<h2>NUMA, cgroups e isolamento<\/h2>\n\n<p>Nos sistemas NUMA, o kernel mant\u00e9m listas LRU por n\u00f3. Se os threads acederem principalmente a dados locais, os acertos na cache de p\u00e1ginas <strong>numa-nah<\/strong> e reduzimos a lat\u00eancia. Atrav\u00e9s da afinidade da CPU e da mem\u00f3ria, garanto que uma aplica\u00e7\u00e3o e os seus dados fiquem pr\u00f3ximos uns dos outros. Atrav\u00e9s de <strong>memcg<\/strong> (cgroups v2) o cache de p\u00e1ginas \u00e9 atribu\u00eddo a um grupo; com <em>mem\u00f3ria.alta<\/em> inicio uma recupera\u00e7\u00e3o controlada, com <em>mem\u00f3ria.max<\/em> estabele\u00e7o limites rigorosos e com <em>mem\u00f3ria.baixa<\/em> Dou prioridade aos servi\u00e7os importantes. Estas ferramentas ajudam a garantir que uma tarefa em lote ruidosa n\u00e3o esvazie a cache de um servi\u00e7o web sens\u00edvel \u00e0 lat\u00eancia. O isolamento permite uma melhor planeamento \u2013 mas procuro encontrar um equil\u00edbrio para que n\u00e3o surjam demasiadas caches pequenas, cada uma das quais com um n\u00famero insuficiente de acertos.<\/p>\n\n<h2>SSD, HDD e a aplica\u00e7\u00e3o pr\u00e1tica do \u00abreadahead\u00bb<\/h2>\n\n<p>O readahead \u00e9 vantajoso para padr\u00f5es sequenciais, mas, no caso de acessos aleat\u00f3rios, \u00e9 muitas vezes apenas um peso. Nos discos r\u00edgidos (HDDs), costumo aumentar o readahead para acelerar as leituras lineares. Nos SSDs NVMe r\u00e1pidos, o benef\u00edcio \u00e9 menor; um readahead excessivo desperdi\u00e7a mem\u00f3ria RAM e prejudica os acertos de cache, porque as p\u00e1ginas n\u00e3o utilizadas substituem outras. Ajusto o Readahead por dispositivo e verifico, atrav\u00e9s de execu\u00e7\u00f5es repetidas, se a taxa de transfer\u00eancia ou as lat\u00eancias beneficiam com isso. Al\u00e9m disso, tenho em conta o agendador de E\/S: para NVMe, \u00e9 comum utilizar \u201enone\u201c\/\u201emq-deadline\u201c, enquanto os discos r\u00edgidos (HDD) podem beneficiar do agendamento por prazo (Deadline). O cache de p\u00e1ginas suaviza os perfis de E\/S, mas a camada de blocos tem de estar em sintonia com isso. O objetivo continua a ser que o cache contenha principalmente dados \u00fateis e reutilizados \u2013 e n\u00e3o apenas bytes pr\u00e9-carregados.<\/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-page-cache-performance-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Arranques a frio, pr\u00e9-aquecimento e implementa\u00e7\u00f5es<\/h2>\n\n<p>Cada cache precisa de uma fase de aquecimento. Ap\u00f3s reinicializa\u00e7\u00f5es ou implementa\u00e7\u00f5es, leio especificamente os hotsets, por exemplo, percorrendo sequencialmente os diret\u00f3rios importantes. Isso reduz sensivelmente o \u201eminuto a frio\u201c ap\u00f3s as implementa\u00e7\u00f5es. Em estrat\u00e9gias de implementa\u00e7\u00e3o gradual, mantenho pelo menos uma inst\u00e2ncia \u00abaquecida\u00bb online, para que o servi\u00e7o global responda rapidamente enquanto as novas inst\u00e2ncias preenchem o seu cache. Evito altera\u00e7\u00f5es em massa na \u00e1rvore de ficheiros (por exemplo, altera\u00e7\u00f5es de caminhos), porque isso \u00abarrefece\u00bb os dentries\/inodes. Em vez disso, trabalho com trocas at\u00f3micas de liga\u00e7\u00f5es simb\u00f3licas ou estrat\u00e9gias de \u00abcopy-on-write\u00bb, nas quais os conte\u00fados dos ficheiros e os caminhos permanecem, em grande parte, est\u00e1veis. Desta forma, n\u00e3o s\u00f3 o cache de p\u00e1ginas permanece eficaz, como tamb\u00e9m os caches de metadados mant\u00eam a sua efic\u00e1cia.<\/p>\n\n<h2>Par\u00e2metros de medi\u00e7\u00e3o em profundidade<\/h2>\n\n<p>Al\u00e9m de <code>\/proc\/meminfo<\/code> para diagn\u00f3sticos precisos, dou uma vista de olhos em <code>\/proc\/vmstat<\/code>: Contadores como <em>pgfault<\/em> e <em>pgmajfault<\/em> distinguem as falhas de p\u00e1gina leves das graves, <em>nr_active_file<\/em>\/<em>nr_inactive_file<\/em> indicam o tamanho do conjunto de trabalho baseado em ficheiros e <em>workingset_refault<\/em> ajuda a detetar o \u00abthrashing\u00bb. Se os \u00abrefaults\u00bb aumentarem enquanto a taxa de E\/S do dispositivo se mantiver elevada, o conjunto de trabalho n\u00e3o cabe na RAM. Fa\u00e7o o teste com duas execu\u00e7\u00f5es da mesma carga de trabalho: a segunda execu\u00e7\u00e3o dever\u00e1 ser significativamente mais r\u00e1pida, caso o cache funcione corretamente. Para testes de arranque a frio reproduz\u00edveis, esvazio as caches exclusivamente no ambiente de laborat\u00f3rio e documento isso cuidadosamente, para n\u00e3o distorcer as medi\u00e7\u00f5es de produ\u00e7\u00e3o. Para mim, \u00e9 importante n\u00e3o sobreinterpretar um \u00fanico indicador, mas sim identificar padr\u00f5es ao longo de s\u00e9ries temporais.<\/p>\n\n<h2>Evitar o swap, o \u00abswappiness\u00bb e o thrashing<\/h2>\n\n<p>Quando est\u00e1 sob press\u00e3o, o Linux esvazia primeiro a cache de p\u00e1ginas antes de recorrer \u00e0s p\u00e1ginas an\u00f3nimas \u2013 desde que isso fa\u00e7a sentido. Se a mem\u00f3ria de trabalho para os processos se tornar escassa e as p\u00e1ginas an\u00f3nimas n\u00e3o forem suficientes, o sistema come\u00e7a a utilizar o swap. Uma <strong>demasiado baixa<\/strong> A \u00abswappiness\u00bb pode fazer com que a mem\u00f3ria an\u00f3nima importante (heaps\/stacks) seja mantida de forma agressiva, levando \u00e0 substitui\u00e7\u00e3o de p\u00e1ginas de cache \u00fateis, o que aumenta as opera\u00e7\u00f5es de E\/S. Uma <strong>demasiado elevada<\/strong> Por outro lado, o uso excessivo da swap leva a um deslocamento antecipado e a picos de lat\u00eancia. Escolho valores moderados, fa\u00e7o medi\u00e7\u00f5es e observo: o objetivo \u00e9 que o meu \u00abhotset\u00bb permane\u00e7a na RAM e que apenas os dados \u00abfrios\u00bb, raramente utilizados, sejam transferidos para a swap \u2013 nunca os \u00abquentes\u00bb.<\/p>\n\n<h2>Seguran\u00e7a e durabilidade: dados no suporte<\/h2>\n\n<p>O \u00abwrite-back\u00bb melhora o desempenho, mas cria um curto intervalo de tempo durante o qual as altera\u00e7\u00f5es ficam apenas na RAM. Para dados que t\u00eam de ser mantidos imediatamente, utilizo <code>fsync()<\/code> ou <code>fdatasync()<\/code>. Al\u00e9m disso, confio em predefini\u00e7\u00f5es seguras, como barreiras de grava\u00e7\u00e3o e registo em di\u00e1rio; evito op\u00e7\u00f5es arriscadas que desativam essas barreiras. Ao n\u00edvel do armazenamento, presto aten\u00e7\u00e3o \u00e0s caches dos controladores: as pol\u00edticas de \u00abwrite-back\u00bb com bateria\/condensador s\u00e3o r\u00e1pidas e seguras, mas as caches inseguras sem prote\u00e7\u00e3o s\u00e3o delicadas. A n\u00edvel do sistema, imp\u00f5e-se <code>sincroniza\u00e7\u00e3o<\/code> A limpeza de todos os dados \u2013 uma ferramenta rudimentar que utilizo de forma consciente e espor\u00e1dica. \u00c9 assim que combino a velocidade proporcionada pela cache de p\u00e1ginas com uma persist\u00eancia adequada nos casos em que esta \u00e9 essencial para o neg\u00f3cio.<\/p>\n\n<h2>WordPress e pilhas web: dicas pr\u00e1ticas<\/h2>\n\n<p>Na pilha web, os caches somam-se: o cache de p\u00e1ginas do Linux acelera os recursos est\u00e1ticos, os ficheiros PHP e as configura\u00e7\u00f5es, enquanto um cache de OpCode do PHP mant\u00e9m o caminho de execu\u00e7\u00e3o e o bytecode na mem\u00f3ria. Asseguro que as implementa\u00e7\u00f5es n\u00e3o alterem constantemente o caminho do c\u00f3digo e reduzo os acessos aos ficheiros atrav\u00e9s da agrega\u00e7\u00e3o de recursos. Uma camada de cache de objetos persistente diminui as opera\u00e7\u00f5es de E\/S da base de dados, permitindo que o cache do sistema de ficheiros atenda aos restantes ficheiros mais acedidos de forma ainda mais eficaz. Sempre que poss\u00edvel, n\u00e3o armazeno sess\u00f5es e dados transit\u00f3rios no disco local, mas sim em caches de mem\u00f3ria ou de rede, para que o cache de p\u00e1ginas possa demonstrar a sua efic\u00e1cia nos restantes ficheiros lidos com frequ\u00eancia. Resultado: menos E\/S f\u00edsica, respostas mais r\u00e1pidas e lat\u00eancias mais est\u00e1veis.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>A cache de p\u00e1ginas do Linux fornece-me respostas r\u00e1pidas aos ficheiros <strong>RAM<\/strong> e reduz consideravelmente os acessos dispendiosos ao suporte de dados. Os \u00abread hits\u00bb aceleram as aplica\u00e7\u00f5es, enquanto o \u00abwrite-back\u00bb agrupa muitas grava\u00e7\u00f5es individuais e aumenta a efici\u00eancia. A mem\u00f3ria livre n\u00e3o fica ociosa, mas funciona como cache para uma plataforma com elevada capacidade de resposta. Com pontos de medi\u00e7\u00e3o como <code>livre -h<\/code>, <code>\/proc\/meminfo<\/code> e <code>iostat<\/code> percebo o efeito antes de considerar par\u00e2metros como <code>vm.dirty_ratio<\/code> ou <code>vm.vfs_cache_pressure<\/code> v\u00e1. Quem conhece as cargas de trabalho, testa as altera\u00e7\u00f5es de forma controlada e utiliza a cache de forma seletiva, consegue um desempenho visivelmente melhor <strong>Desempenho<\/strong> sem altera\u00e7\u00f5es no c\u00f3digo.<\/p>","protected":false},"excerpt":{"rendered":"<p>O Page Cache do Linux utiliza a RAM como cache, melhorando assim o desempenho do servidor em servi\u00e7os de alojamento web, WordPress e acesso a ficheiros.<\/p>","protected":false},"author":1,"featured_media":20533,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20540","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":"146","_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":null,"_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":"Linux Page","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":"20533","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20540","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=20540"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20540\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20533"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}