{"id":21026,"date":"2026-08-26T15:05:23","date_gmt":"2026-08-26T13:05:23","guid":{"rendered":"https:\/\/webhosting.de\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/"},"modified":"2026-08-26T15:05:23","modified_gmt":"2026-08-26T13:05:23","slug":"linux-cache-de-paginas-transparente-diferencas-entre-caches-de-paginas-otimizacao-cache-de-dados","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-transparent-page-cache-page-cache-unterschiede-optimierung-datencache\/","title":{"rendered":"Cache de p\u00e1ginas transparente do Linux: no\u00e7\u00f5es b\u00e1sicas e diferen\u00e7as em rela\u00e7\u00e3o ao cache de p\u00e1ginas cl\u00e1ssico"},"content":{"rendered":"<p>Vou explicar, em duas frases, como o Linux acelera o acesso aos ficheiros na RAM e como um <strong>cache de p\u00e1ginas transparente<\/strong> que utiliza unidades de p\u00e1gina maiores para reduzir a carga administrativa. Al\u00e9m disso, explico as diferen\u00e7as em rela\u00e7\u00e3o ao cache de p\u00e1gina cl\u00e1ssico com p\u00e1ginas de 4 KiB, bem como o impacto na TLB, na fragmenta\u00e7\u00e3o e no comportamento da carga de trabalho.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>tamanho da p\u00e1gina<\/strong>: 4 KiB vs. 2 MiB influencia a granularidade e a efici\u00eancia.<\/li>\n  <li><strong>Impress\u00e3o TLB<\/strong>: Os sites de grande dimens\u00e3o reduzem o n\u00famero de publica\u00e7\u00f5es, enquanto os mais pequenos mant\u00eam a flexibilidade.<\/li>\n  <li><strong>Fragmenta\u00e7\u00e3o<\/strong>: As p\u00e1ginas grandes precisam de mem\u00f3ria RAM cont\u00ednua.<\/li>\n  <li><strong>Cargas de trabalho<\/strong>: Em sequ\u00eancia, lucra muito; aleatoriamente, lucra menos.<\/li>\n  <li><strong>Controlo<\/strong>: Testar, medir e, em seguida, configurar gradualmente.<\/li>\n<\/ul>\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-serverraum-8473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que \u00e9 o cache de p\u00e1ginas cl\u00e1ssico do Linux?<\/h2>\n\n<p>O cache de p\u00e1ginas cl\u00e1ssico mant\u00e9m as p\u00e1ginas de ficheiros mais utilizadas na mem\u00f3ria principal, para que os acessos de leitura sejam efetuados diretamente a partir de <strong>RAM<\/strong> ocorre. Normalmente, funciona com p\u00e1ginas de 4 KiB e gere cada p\u00e1gina como uma unidade independente na cache. Desta forma, muitos ficheiros pequenos ou partes muito solicitadas de ficheiros grandes permanecem dispon\u00edveis, sem sobrecarregar o SSD ou o HDD. O kernel d\u00e1 prioridade \u00e0s p\u00e1ginas ativas, descarta conte\u00fados pouco utilizados e reage assim de forma din\u00e2mica aos picos de carga. Para informa\u00e7\u00f5es mais aprofundadas, remeto para uma introdu\u00e7\u00e3o concisa sobre a <a href=\"https:\/\/webhosting.de\/pt\/otimizador-de-desempenho-do-cache-de-paginas-do-linux\/\">Desempenho da cache de p\u00e1ginas<\/a>, que descreve o princ\u00edpio b\u00e1sico de forma pr\u00e1tica.<\/p>\n\n<h2>Por que raz\u00e3o um cache de p\u00e1ginas transparente?<\/h2>\n\n<p>A exist\u00eancia de muitas p\u00e1ginas individuais de 4 KiB gera trabalho administrativo e aumenta a press\u00e3o sobre a <strong>TLB<\/strong>. P\u00e1ginas maiores, como 2 MiB, podem abranger o mesmo espa\u00e7o de endere\u00e7os com menos entradas, poupando assim tempo de CPU. Uma cache de p\u00e1ginas transparente agrupa automaticamente p\u00e1ginas de ficheiros em unidades maiores, sempre que os padr\u00f5es de acesso e a localiza\u00e7\u00e3o na mem\u00f3ria o permitirem. Isto assemelha-se \u00e0 ideia por tr\u00e1s das Transparent Huge Pages, mas, neste caso, refere-se a um cache baseado em ficheiros em vez de mem\u00f3ria an\u00f3nima. S\u00f3 recorro a estas funcionalidades depois de compreender os padr\u00f5es de acesso, a fragmenta\u00e7\u00e3o e os requisitos de lat\u00eancia, pois p\u00e1ginas maiores aumentam a granularidade.<\/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\/LinuxPageCacheMeeting4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Comparar sistematicamente as diferen\u00e7as<\/h2>\n\n<p>Para uma classifica\u00e7\u00e3o clara, apresento lado a lado as principais caracter\u00edsticas da cache cl\u00e1ssica, da cache de p\u00e1ginas transparente e do THP, para que a escolha seja feita com base em <strong>Carga de trabalho<\/strong> \u00e9 mais f\u00e1cil. O foco est\u00e1 no tamanho da p\u00e1gina, na TLB, na fragmenta\u00e7\u00e3o, nos benef\u00edcios e nos riscos. A tabela apresenta pontos fortes e limita\u00e7\u00f5es sem frases de efeito de marketing. Leio-a da esquerda para a direita e verifico qual a coluna que melhor se adequa \u00e0 carga. Em seguida, decido se mantenho a cache de 4 KiB ou se testo p\u00e1ginas maiores.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Carater\u00edstica<\/th>\n      <th>Cache de p\u00e1ginas cl\u00e1ssico (4 KiB)<\/th>\n      <th>Cache de p\u00e1gina transparente (por exemplo, 2 MiB)<\/th>\n      <th>THP (mem\u00f3ria an\u00f3nima)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Tamanho da p\u00e1gina\/granularidade<\/td>\n      <td>Caching preciso e detalhado<\/td>\n      <td>A grosso modo, \u00e1reas bastante extensas<\/td>\n      <td>Aproximadamente, grandes pilhas\/montes<\/td>\n    <\/tr>\n    <tr>\n      <td>Impress\u00e3o TLB<\/td>\n      <td>Mais alto devido ao grande n\u00famero de registos<\/td>\n      <td>Mais abaixo, menos entradas<\/td>\n      <td>Mais abaixo, menos entradas<\/td>\n    <\/tr>\n    <tr>\n      <td>Despesas administrativas<\/td>\n      <td>Elevado em muitas p\u00e1ginas<\/td>\n      <td>Menos metadados<\/td>\n      <td>Menos metadados<\/td>\n    <\/tr>\n    <tr>\n      <td>Fragmenta\u00e7\u00e3o<\/td>\n      <td>N\u00e3o \u00e9 cr\u00edtico, n\u00e3o requer contiguidade<\/td>\n      <td>Requer mem\u00f3ria RAM cont\u00ednua<\/td>\n      <td>Requer mem\u00f3ria RAM cont\u00ednua<\/td>\n    <\/tr>\n    <tr>\n      <td>Cargas adequadas<\/td>\n      <td>Ficheiros pequenos, acessos aleat\u00f3rios<\/td>\n      <td>Ficheiros grandes, padr\u00f5es sequenciais<\/td>\n      <td>Heaps grandes, bases de dados na RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>Riscos<\/td>\n      <td>Mais sobrecarga da TLB e da CPU<\/td>\n      <td>Overfetch, picos de lat\u00eancia durante o Split\/Merge<\/td>\n      <td>Overfetch, picos de lat\u00eancia durante o Split\/Merge<\/td>\n    <\/tr>\n    <tr>\n      <td>Depend\u00eancia do kernel\/funcionalidade<\/td>\n      <td>Amplamente dispon\u00edvel<\/td>\n      <td>Ter em conta a vers\u00e3o\/implementa\u00e7\u00e3o<\/td>\n      <td>Verificar as defini\u00e7\u00f5es de distribui\u00e7\u00e3o<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>A tabela n\u00e3o substitui um teste, mas estrutura a minha <strong>Decis\u00e3o<\/strong>. Primeiro, avalio os padr\u00f5es de acesso e o tamanho dos ficheiros. Depois, me\u00e7o a lat\u00eancia, o tempo de CPU e a taxa de acertos na cache, com e sem p\u00e1ginas de grande dimens\u00e3o. Se os benchmarks revelarem vantagens claras, sem valores at\u00edpicos, procuro expandir a implementa\u00e7\u00e3o com cautela. Se surgirem picos, recuo ou limito a implementa\u00e7\u00e3o.<\/p>\n\n<h2>Como \u00e9 que o kernel cria p\u00e1ginas de ficheiros de grande dimens\u00e3o<\/h2>\n\n<p>Para que se formem unidades de p\u00e1gina maiores na cache de p\u00e1ginas, o kernel necessita de \u00e1reas cont\u00ednuas de ficheiros na mem\u00f3ria e de um acesso suficientemente coerente. Um exemplo t\u00edpico \u00e9 a \u00abpromo\u00e7\u00e3o\u00bb: v\u00e1rias p\u00e1ginas de 4 KiB s\u00e3o agrupadas num f\u00f3lio maior. Por outro lado, quando os padr\u00f5es n\u00e3o s\u00e3o adequados, ocorre uma divis\u00e3o de volta em unidades mais pequenas. Observo estas transi\u00e7\u00f5es especialmente sob carga, porque a promo\u00e7\u00e3o e a divis\u00e3o consomem CPU momentaneamente e atualizam as listas LRU. As leituras sequenciais favorecem a promo\u00e7\u00e3o, enquanto as cargas de trabalho muito dispersas tendem a provocar divis\u00f5es.<\/p>\n\n<p>A leitura antecipada desempenha um papel essencial neste contexto: quando s\u00e3o lidos antecipadamente dados suficientes e esses dados s\u00e3o posteriormente efetivamente consumidos, criam-se grandes folios, por assim dizer, de forma natural. Por outro lado, se as aplica\u00e7\u00f5es acedem aos dados em pequenos passos imprevis\u00edveis, a cache permanece granular. Tamb\u00e9m <strong>Writeback<\/strong> interage com p\u00e1ginas de grande dimens\u00e3o: se forem gravadas simultaneamente muitas p\u00e1ginas \u00abdirty\u00bb interligadas, a taxa de transfer\u00eancia e as IOPS podem beneficiar, embora os tamanhos dos picos aumentem. Por isso, tenho em conta os par\u00e2metros de ajuste das p\u00e1ginas \u00abdirty\u00bb (por exemplo,. <code>vm.dirty_background_bytes<\/code> e <code>vm.dirty_bytes<\/code>), para evitar ondas de flush demasiado grandes.<\/p>\n\n<h2>Sistemas de ficheiros, percursos de E\/S e a sua influ\u00eancia<\/h2>\n\n<p>A E\/S com buffer beneficia diretamente da cache de p\u00e1ginas, enquanto a E\/S direta (<code>O_DIRECTO<\/code>) contorna-o em grande parte. Para bases de dados ou ferramentas de c\u00f3pia de seguran\u00e7a que utilizam deliberadamente o Direct I\/O, um cache de p\u00e1ginas transparente tem, consequentemente, menos influ\u00eancia. No caso de <code>mmap()<\/code> o efeito depende do padr\u00e3o de acesso: as visualiza\u00e7\u00f5es p\u00e1gina a p\u00e1gina e progressivas tiram bom partido de f\u00f3lios maiores; os saltos aleat\u00f3rios, n\u00e3o. Com <code>posix_fadvise()<\/code> posso fornecer instru\u00e7\u00f5es ao kernel (por exemplo,. <code>SEQUENCIAL<\/code>, <code>WILLNEED<\/code>, <code>ALEAT\u00d3RIO<\/code>), que orientam o readahead e a substitui\u00e7\u00e3o. Essas dicas n\u00e3o s\u00e3o garantias, mas aumentam as hip\u00f3teses de o cache se adequar \u00e0 minha carga de trabalho.<\/p>\n\n<p>Os sistemas de ficheiros t\u00eam as suas pr\u00f3prias heur\u00edsticas. Em alguns sistemas, o ext4 e o XFS reagem de forma bastante adequada a fluxos sequenciais, enquanto os sistemas de ficheiros \u00abcopy-on-write\u00bb com desduplica\u00e7\u00e3o ou compress\u00e3o (por exemplo, \u00e1rvores com muitos instant\u00e2neos) apresentam outros perfis de desempenho. Por isso, verifico se o layout e a fragmenta\u00e7\u00e3o do sistema de ficheiros permitem a exist\u00eancia de grandes \u00e1reas cont\u00ednuas. Uma opera\u00e7\u00e3o de desfragmenta\u00e7\u00e3o para dados altamente fragmentados pode trazer vantagens mensur\u00e1veis, mas deve ser sempre planeada com cuidado e dentro de janelas de manuten\u00e7\u00e3o.<\/p>\n\n<h2>Fatores de hardware: arquitetura, NUMA e dispositivos<\/h2>\n\n<p>Nem todas as arquiteturas utilizam 4 KiB como p\u00e1gina base. Em sistemas com p\u00e1ginas base maiores, a granularidade e o comportamento da TLB alteram-se j\u00e1 por predefini\u00e7\u00e3o. Isso desloca a faixa de utilidade de grandes folios na cache. Al\u00e9m disso, tenho em conta as topologias NUMA: As p\u00e1ginas grandes t\u00eam melhor desempenho quando se encontram localmente na CPU que executa o thread de E\/S ou a aplica\u00e7\u00e3o. Por isso, associo os trabalhadores aos n\u00f3s, monitorizo as estat\u00edsticas por NUMA e evito acessos remotos desnecess\u00e1rios. No Linux, as m\u00e9tricas por n\u00f3 ajudam-me (<code>\/sys\/devices\/system\/node\/node*\/meminfo<\/code>) e o \u00abscheduler-pinning\u00bb, para manter a localidade.<\/p>\n\n<p>No lado do dispositivo, analiso as filas do controlador, a profundidade NVMe e a curva de lat\u00eancia. Os dispositivos de grande capacidade funcionam bem com um elevado d\u00e9bito e uma lat\u00eancia est\u00e1vel, mas s\u00e3o sens\u00edveis a picos de lat\u00eancia na cauda. Um agendador de E\/S que suavize as cargas em rajadas pode fazer toda a diferen\u00e7a neste caso. Valores de pr\u00e9-leitura (<code>blockdev --getra\/--setra<\/code>) fa\u00e7o a calibra\u00e7\u00e3o com cuidado, dispositivo a dispositivo e carga de trabalho a carga de trabalho.<\/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-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Metodologia de medi\u00e7\u00e3o, KPIs e observabilidade<\/h2>\n\n<p>Defino antecipadamente alguns indicadores, poucos mas significativos: taxa de falhas de p\u00e1gina, taxa de acertos de cache, tempo de CPU por pedido, carga da TLB, acertos de pr\u00e9-leitura, percentis de lat\u00eancia (P50\/P95\/P99) e acessos falhados de E\/S. Para a vis\u00e3o geral do sistema, utilizo <code>vmstat<\/code>, <code>sar -B<\/code>, <code>iostat<\/code> e <code>pidstat<\/code>, para identificar tend\u00eancias. <code>\/proc\/meminfo<\/code> e <code>smaps<\/code> ajudam a identificar o que se encontra ativamente na mem\u00f3ria de trabalho; <code>tampo da laje<\/code> mostra a sobrecarga de metadados. Se for necess\u00e1rio, fa\u00e7o a medi\u00e7\u00e3o com <code>perfeito<\/code> Erros de TLB e ciclos da CPU sob carga real, para tornar vis\u00edvel o efeito das p\u00e1ginas grandes.<\/p>\n\n<p>Para mim, um teste consiste em tr\u00eas fases: aquecimento at\u00e9 se atingir uma taxa de aceder est\u00e1vel, intervalo de medi\u00e7\u00e3o sob carga controlada e arrefecimento para observar a evic\u00e7\u00e3o e o writeback. Repito os testes com um conjunto de dados id\u00eantico e par\u00e2metros vari\u00e1veis (por exemplo, Readahead, modo THP) <code>sempre\/aconselhar mal\/nunca<\/code>), para obter resultados fi\u00e1veis. N\u00e3o ignoro os valores at\u00edpicos: se o P99 piorar, apesar de a m\u00e9dia baixar, isso significa que, na maioria das vezes, a configura\u00e7\u00e3o n\u00e3o se enquadra no meu intervalo-alvo.<\/p>\n\n<h2>Padr\u00f5es t\u00edpicos na pr\u00e1tica<\/h2>\n\n<p>As cargas de trabalho de streaming e multim\u00e9dia leem ficheiros de grande dimens\u00e3o, na sua maioria, de forma sequencial. \u00c9 aqui que os folios de grande dimens\u00e3o se destacam regularmente, uma vez que reduzem a press\u00e3o sobre a TLB e o esfor\u00e7o de gest\u00e3o. As opera\u00e7\u00f5es de c\u00f3pia de seguran\u00e7a\/restaura\u00e7\u00e3o e replica\u00e7\u00e3o com blocos longos e sequenciais apresentam vantagens semelhantes, especialmente quando v\u00e1rios processos leem as mesmas \u00e1reas. Os pipelines de aprendizagem autom\u00e1tica beneficiam quando os conjuntos de dados s\u00e3o agrupados e mantidos em mem\u00f3ria; no entanto, a amostragem fortemente aleat\u00f3ria a partir de muitos ficheiros min\u00fasculos atenua este efeito, a menos que se opte antecipadamente por formatos de contentores com blocos cont\u00edguos.<\/p>\n\n<p>Os ambientes de compila\u00e7\u00e3o e CI com milhares e milhares de ficheiros pequenos funcionam geralmente melhor com uma granularidade de 4 KiB. Nesses casos, o que importa \u00e9 a disponibilidade r\u00e1pida e precisa de fragmentos utilizados com maior frequ\u00eancia. Neste contexto, invisto numa elevada propor\u00e7\u00e3o de RAM para o Active(file), numa pr\u00e9-leitura adequada por dispositivo e, eventualmente, em caches pr\u00f3ximos das aplica\u00e7\u00f5es (por exemplo, caches de depend\u00eancias), em vez de for\u00e7ar p\u00e1ginas grandes no kernel.<\/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_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gest\u00e3o de recursos: Cgroups e prote\u00e7\u00e3o do conjunto de trabalho<\/h2>\n\n<p>Em ambientes multi-tenant, limito e protejo o espa\u00e7o de mem\u00f3ria por servi\u00e7o. Com o cgroup v2, \u00e9 poss\u00edvel atribuir recursos de forma precisa a processos que consomem muito cache de p\u00e1ginas e, se necess\u00e1rio, atrav\u00e9s de <code>mem\u00f3ria.baixa<\/code> proteger, para que os conjuntos de trabalho importantes sejam substitu\u00eddos com menos frequ\u00eancia. <code>mem\u00f3ria.alta<\/code> estabelece limites m\u00e1ximos flex\u00edveis, <code>mem\u00f3ria.max<\/code> Limites r\u00edgidos. Observo como a equidade e a evic\u00e7\u00e3o funcionam quando v\u00e1rios servi\u00e7os partilham a mesma cache do host. P\u00e1ginas de grande dimens\u00e3o podem ajudar a aliviar a carga da CPU, mas tamb\u00e9m podem levar a blocos de evic\u00e7\u00e3o de maior dimens\u00e3o. Por isso, calibro os limites de prote\u00e7\u00e3o em pequenos passos e verifico a din\u00e2mica da LRU.<\/p>\n\n<h2>Sinais de falha e medidas corretivas<\/h2>\n\n<p>Quando a promo\u00e7\u00e3o e o split ocorrem com frequ\u00eancia, observo lat\u00eancia vari\u00e1vel, elevada utiliza\u00e7\u00e3o da CPU pelo kernel e uma taxa de acertos inst\u00e1vel. Solu\u00e7\u00f5es: ajustar o readahead, evitar cascatas de split, desagregar as cargas de trabalho ou reduzir a agressividade das p\u00e1ginas grandes. Em caso de sintomas de overfetch (muito conte\u00fado em cache, aumento da press\u00e3o de swap, diminui\u00e7\u00e3o da taxa de acertos para pequenos hotsets), recorro a uma granularidade mais fina ou isolo os grandes leitores em n\u00f3s dedicados. Se os picos de reescrita aumentarem a lat\u00eancia de cauda, defino limites mais rigorosos para os bytes sujos e uniformizo os intervalos de limpeza.<\/p>\n\n<p>Resolvo o jitter NUMA atrav\u00e9s do \u00abpinning\u00bb de CPU\/mem\u00f3ria e de um posicionamento adequado dos threads de E\/S. Se ocorrerem falhas de TLB, mas a aplica\u00e7\u00e3o continuar lenta, verifico a conten\u00e7\u00e3o de bloqueios, os bloqueios do sistema de ficheiros e o impacto da compress\u00e3o\/descriptografia na pilha. Um ganho de desempenho atrav\u00e9s de p\u00e1ginas grandes s\u00f3 \u00e9 um verdadeiro sucesso se se refletir no ponto final da aplica\u00e7\u00e3o.<\/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_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Calend\u00e1rio pr\u00e1tico para os exames<\/h2>\n\n<p>Come\u00e7o por definir uma linha de base: kernel atual, estado do THP (<code>\/sys\/kernel\/mm\/transparent_hugepage\/<\/code>), valores de pr\u00e9-leitura, agendador de E\/S, disposi\u00e7\u00e3o de ficheiros e suportes de dados. Em seguida, defino duas a tr\u00eas hip\u00f3teses concretas (por exemplo, \u201efluxos de multim\u00e9dia sequenciais: -10% CPU, P99 mais est\u00e1vel\u201c). Em seguida, defino conjuntos de dados fixos e perfis de carga que reproduzem padr\u00f5es de tr\u00e1fego realistas. Cada s\u00e9rie de testes tem tempos de aquecimento id\u00eanticos, dura\u00e7\u00e3o id\u00eantica e recolha de m\u00e9tricas id\u00eantica.<\/p>\n\n<p>Vario apenas um par\u00e2metro de cada vez: primeiro o readahead, depois a agressividade das p\u00e1ginas grandes e, por fim, as defini\u00e7\u00f5es de LRU\/Dirty. Ap\u00f3s cada passo, guardo as m\u00e9tricas e as notas, para que as atualiza\u00e7\u00f5es posteriores do kernel continuem a ser compar\u00e1veis. S\u00f3 quando duas execu\u00e7\u00f5es independentes apresentarem a mesma tend\u00eancia e as lat\u00eancias P95\/P99 estiverem est\u00e1veis \u00e9 que aplico a altera\u00e7\u00e3o a um grupo de produ\u00e7\u00e3o limitado. Faz sempre parte do processo um plano de revers\u00e3o com valores-limite claros (por exemplo, \u201eP99 &gt; +15% durante 5 min\u201c).<\/p>\n\n<h2>Padr\u00f5es de acesso e sensibilidade<\/h2>\n\n<p>Os leitores sequenciais que lidam com ficheiros de grande dimens\u00e3o beneficiam com mais frequ\u00eancia de mem\u00f3rias maiores <strong>P\u00e1ginas<\/strong>. Os acessos aleat\u00f3rios a muitos ficheiros pequenos funcionam geralmente melhor com 4 KiB, porque, nesse caso, a cache armazena apenas os fragmentos necess\u00e1rios. As cargas mistas exigem medi\u00e7\u00f5es com conjuntos de dados realistas, uma vez que os testes sint\u00e9ticos costumam revelar resultados demasiado otimistas. Estou atento para ver se o overfetch ocupa mem\u00f3ria que falta noutros locais. Um pequeno ganho em tempo de CPU n\u00e3o compensa se isso aumentar a press\u00e3o sobre a LRU e fizer com que as lat\u00eancias disparem.<\/p>\n\n<h2>Cen\u00e1rios de alojamento web com muitos ficheiros pequenos<\/h2>\n\n<p>A hospedagem partilhada t\u00edpica aloja uma grande quantidade de pequenos scripts, imagens e recursos, que o cache de 4 KiB consegue armazenar bem no <strong>Pega<\/strong> tem. P\u00e1ginas grandes raramente trazem valor acrescentado neste contexto, uma vez que os ficheiros s\u00e3o frequentemente menores do que 2 MiB ou s\u00e3o utilizados de forma irregular. Em vez disso, invisto em mem\u00f3ria RAM suficiente, um readahead adequado por dispositivo e caches ao n\u00edvel da aplica\u00e7\u00e3o, como o OPCache. Al\u00e9m disso, verifico se os recursos est\u00e1ticos s\u00e3o carregados mais rapidamente atrav\u00e9s de um cache HTTP do que a partir do dispositivo de bloco. S\u00f3 quando os perfis de carga indicam ficheiros maiores \u00e9 que abro a porta para p\u00e1ginas de cache de p\u00e1gina maiores.<\/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-differences-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bases de dados, caches e registos<\/h2>\n\n<p>As bases de dados em mem\u00f3ria e os heaps de grande dimens\u00e3o beneficiam frequentemente do THP no modo an\u00f3nimo <strong>Mem\u00f3ria<\/strong>. No caso de motores baseados em ficheiros e pipelines de registos com leituras longas e sequenciais, um cache de p\u00e1ginas transparente tamb\u00e9m pode revelar-se vantajoso. Testo de forma reprodut\u00edvel se as falhas de p\u00e1gina diminuem e se a CPU funciona de forma mais tranquila. Ao mesmo tempo, observo se o overfetch aumenta a RAM ocupada e se os tempos de arranque a frio se alteram. Uma breve contextualiza\u00e7\u00e3o ajuda no in\u00edcio: utilizo este guia para <a href=\"https:\/\/webhosting.de\/pt\/paginas-enormes-transparentes-impulsionador-de-desempenho-do-linux-ou-problema-de-otimizacao\/\">Avaliar o THP<\/a> e avaliar corretamente as intera\u00e7\u00f5es.<\/p>\n\n<h2>Virtualiza\u00e7\u00e3o e contentores<\/h2>\n\n<p>V\u00e1rias m\u00e1quinas virtuais ou contentores partilham o kernel do anfitri\u00e3o e, consequentemente, o <strong>P\u00e1gina<\/strong>-Cache. Os bin\u00e1rios e bibliotecas utilizados com frequ\u00eancia s\u00e3o ent\u00e3o fornecidos a todas as inst\u00e2ncias a partir do mesmo cache, o que poupa opera\u00e7\u00f5es de E\/S. O THP no sistema convidado pode reduzir a carga na CPU, mas requer que se tenha em conta as zonas NUMA e o overcommit. Fa\u00e7o medi\u00e7\u00f5es por n\u00f3 NUMA, para que p\u00e1ginas de grande dimens\u00e3o n\u00e3o se desloquem por todo o sistema. Se ocorrer jitter sob carga, reduzo a agressividade (madvise) ou desativo o THP de forma seletiva, at\u00e9 que as curvas voltem a ficar suaves.<\/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_tech_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Verificar a configura\u00e7\u00e3o e definir os par\u00e2metros de forma adequada<\/h2>\n\n<p>Come\u00e7o com uma an\u00e1lise s\u00f3bria <strong>Invent\u00e1rio<\/strong>: Que vers\u00e3o do kernel, que predefini\u00e7\u00f5es, que op\u00e7\u00f5es de montagem, que valores de pr\u00e9-leitura? Verifico o estado do THP em \/sys\/kernel\/mm\/transparent_hugepage\/ (por exemplo, enabled, defrag, khugepaged). Para verificar o comportamento da cache de p\u00e1ginas, consulto \/proc\/meminfo, as estat\u00edsticas por n\u00f3 e o readahead por bloco. Nunca aplico altera\u00e7\u00f5es \u00e0s cegas, mas sim num ambiente de teste com dados reais. S\u00f3 depois \u00e9 que transfiro as configura\u00e7\u00f5es est\u00e1veis para o ambiente de produ\u00e7\u00e3o.<\/p>\n\n<h2>Ajuste fino: pr\u00e9-leitura, evic\u00e7\u00e3o e monitoriza\u00e7\u00e3o<\/h2>\n\n<p>As p\u00e1ginas grandes s\u00f3 funcionam se o readahead, o agendador de E\/S e a LRU estiverem bem configurados <strong>juntos<\/strong>testar. Observo a taxa de falhas de p\u00e1gina, os erros de acesso, o tempo de CPU e eventuais picos de lat\u00eancia durante a divis\u00e3o\/fus\u00e3o de p\u00e1ginas grandes. Em condi\u00e7\u00f5es de carga elevada, interessa-me saber com que rapidez a cache substitui as p\u00e1ginas antigas e se ficheiros importantes s\u00e3o exclu\u00eddos. Um bom ponto de partida para analisar a substitui\u00e7\u00e3o \u00e9 este artigo sobre <a href=\"https:\/\/webhosting.de\/pt\/servidor-despejo-de-cache-de-pagina-linux-memoria-impressao-otimizacao-insight\/\">Despejo sob press\u00e3o da mem\u00f3ria<\/a>, que explica o padr\u00e3o t\u00edpico. Depois disso, ajusto cuidadosamente o readahead, as op\u00e7\u00f5es do sistema de ficheiros e, se for caso disso, a utiliza\u00e7\u00e3o de p\u00e1ginas grandes.<\/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_pagecache_schreibtisch4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lista de verifica\u00e7\u00e3o pr\u00e1tica sem mitos<\/h2>\n\n<p>Come\u00e7o com objetivos claros: menos tempo de CPU, lat\u00eancia mais est\u00e1vel, adequada <strong>Taxa de acerto<\/strong> na cache de p\u00e1ginas. Em seguida, defino pontos de medi\u00e7\u00e3o e seleciono cargas de trabalho reais que apresentem picos e cargas mistas. Depois, testo gradualmente p\u00e1ginas maiores, primeiro no ambiente de teste e, posteriormente, de forma limitada, em produ\u00e7\u00e3o. Tenho planos de revers\u00e3o preparados, caso ocorram overfetch, fragmenta\u00e7\u00e3o ou jitter. Por fim, documento os efeitos, para que a configura\u00e7\u00e3o permane\u00e7a reproduz\u00edvel e as atualiza\u00e7\u00f5es futuras do kernel possam ser avaliadas.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>A cache cl\u00e1ssica de 4 KiB continua a ser a op\u00e7\u00e3o mais fi\u00e1vel para muitas aplica\u00e7\u00f5es <strong>Base<\/strong>, porque \u00e9 granular e faz uma utiliza\u00e7\u00e3o eficiente da RAM. Uma cache de p\u00e1ginas transparente reduz a press\u00e3o sobre a TLB e os metadados quando ficheiros de grande dimens\u00e3o s\u00e3o lidos sequencialmente. O THP trata \u00e1reas de mem\u00f3ria an\u00f3nimas e pode ajudar em heaps de grande dimens\u00e3o, mas requer cuidado devido a poss\u00edveis picos de lat\u00eancia. Tomo a decis\u00e3o com base em dados: medir, comparar e, depois, implementar. Quem procede assim consegue tempos de resposta previs\u00edveis, uma utiliza\u00e7\u00e3o sensata da RAM e uma CPU visivelmente mais tranquila.<\/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-setup-5726.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>Descubra como funciona o Transparent Page Cache do Linux, quais s\u00e3o as diferen\u00e7as em rela\u00e7\u00e3o ao Page Cache cl\u00e1ssico e como otimizar a gest\u00e3o da mem\u00f3ria para obter o m\u00e1ximo desempenho. Foco: Transparent Page Cache.<\/p>","protected":false},"author":1,"featured_media":21019,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21026","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":"93","_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":"transparent page cache","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":"21019","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21026","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=21026"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21026\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21019"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21026"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21026"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21026"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}