{"id":16421,"date":"2025-12-31T18:20:15","date_gmt":"2025-12-31T17:20:15","guid":{"rendered":"https:\/\/webhosting.de\/filesystem-caching-linux-page-cache-cacheboost\/"},"modified":"2025-12-31T18:20:15","modified_gmt":"2025-12-31T17:20:15","slug":"sistema-de-ficheiros-cache-linux-cache-de-pagina-cacheboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/filesystem-caching-linux-page-cache-cacheboost\/","title":{"rendered":"Cache do sistema de ficheiros na hospedagem Linux: compreender corretamente o cache de p\u00e1ginas"},"content":{"rendered":"<p>A cache de p\u00e1ginas do Linux determina a velocidade com que as cargas de trabalho de alojamento leem e escrevem ficheiros, pois mant\u00e9m os dados utilizados com frequ\u00eancia na RAM, evitando assim acessos dispendiosos ao dispositivo. Vou mostrar como <strong>Sistema de ficheiros<\/strong> O cache na hospedagem Linux funciona, quais s\u00e3o os indicadores importantes e como posso controlar o cache no dia a dia sem comprometer o <strong>Servidor<\/strong>-Aumentar a carga.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>Cache de p\u00e1gina<\/strong> mant\u00e9m blocos de ficheiros na RAM e reduz as lat\u00eancias.<\/li>\n  <li><strong>P\u00e1ginas sujas<\/strong> re\u00fanem acessos de escrita e os gravam de forma agrupada.<\/li>\n  <li><strong>LRU<\/strong>As estrat\u00e9gias removem entradas antigas para dar lugar a novos dados.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> com free, \/proc\/meminfo, vmstat, iostat fornece clareza.<\/li>\n  <li><strong>Otimiza\u00e7\u00e3o<\/strong> atrav\u00e9s de RAM, Logrotate, Opcache e limites razo\u00e1veis.<\/li>\n<\/ul>\n\n<h2>O que \u00e9 o cache de p\u00e1ginas do Linux?<\/h2>\n<p>A cache de p\u00e1ginas do Linux armazena blocos de ficheiros frequentemente lidos na mem\u00f3ria RAM, acelerando assim cada novo acesso a <strong>Arquivos<\/strong>. Eu me beneficio imediatamente, porque os acessos \u00e0 RAM ocorrem em microssegundos, enquanto mesmo os SSDs r\u00e1pidos precisam de milissegundos e, portanto, s\u00e3o significativamente mais lentos do que <strong>Mem\u00f3ria<\/strong> na RAM. Quando uma aplica\u00e7\u00e3o abre um ficheiro, o kernel armazena os blocos lidos na cache e atende \u00e0s solicita\u00e7\u00f5es futuras diretamente da mem\u00f3ria de trabalho. Isso funciona de forma transparente para os programas, n\u00e3o preciso ajustar ou reconfigurar nada. As cargas de trabalho de hospedagem, como servidores web, PHP-FPM, entrega de imagens ou processos de leitura de logs, acessam constantemente a cache e economizam I\/O.<\/p>\n\n<h2>Como funciona a cache durante a leitura<\/h2>\n<p>Ao ler um ficheiro pela primeira vez, o sistema carrega blocos na cache e marca-os como quentes, para que permane\u00e7am dispon\u00edveis em caso de acesso repetido e para que a <strong>Tempo<\/strong> \u00e9 extremamente curto para o segundo requisito. Se eu ler um ficheiro de 100 MB duas vezes seguidas, a segunda leitura ser\u00e1 feita praticamente toda a partir da RAM. O kernel utiliza estrat\u00e9gias como LRU (Least Recently Used) e prioriza as entradas utilizadas mais recentemente, para que os conte\u00fados web atuais permane\u00e7am mais tempo na cache e os dados frios sejam removidos. Esta l\u00f3gica adapta-se bem aos padr\u00f5es de alojamento, pois muitos visitantes acedem repetidamente a imagens, ficheiros CSS e JavaScript id\u00eanticos, que eu, gra\u00e7as ao <strong>Cache<\/strong> rapidamente. A taxa de acertos aumenta com o tamanho da cache, ou seja, com a RAM dispon\u00edvel.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Escrever e p\u00e1ginas sujas compreens\u00edveis<\/h2>\n<p>Ao escrever, os dados s\u00e3o primeiro armazenados na cache como p\u00e1ginas sujas, ou seja, blocos alterados que o kernel ainda n\u00e3o gravou de volta no disco e que eu posso acessar atrav\u00e9s de <strong>Writeback<\/strong>-mecanismos em tempo real. Posso observar facilmente o comportamento ao vivo: se eu criar um ficheiro de 10 MB com o dd, os valores sujos aumentam at\u00e9 que o kernel os grave no SSD de uma s\u00f3 vez. Uma sincroniza\u00e7\u00e3o manual for\u00e7a o sistema a tornar o cache consistente e redefine a m\u00e9trica suja para zero. Esse agrupamento poupa I\/O, pois combina muitas pequenas opera\u00e7\u00f5es em transfer\u00eancias maiores, reduzindo assim o <strong>Desempenho<\/strong> por processo de escrita. A moderna abordagem de writeback por dispositivo mant\u00e9m os discos paralelos ocupados de forma independente e reduz os tempos de espera.<\/p>\n\n<h2>Arquitetura de cache: Dentry\/Inode vs. Cache de p\u00e1gina<\/h2>\n<p>Para completar o quadro, \u00e9 importante referir que o Linux n\u00e3o armazena apenas dados de ficheiros em cache. Al\u00e9m do pr\u00f3prio <strong>Cache de p\u00e1gina<\/strong> Para conte\u00fados, existem caches Dentry e Inode, que mant\u00eam estruturas de diret\u00f3rios, nomes de ficheiros e metadados na RAM. Eles poupam resolu\u00e7\u00f5es de caminho e pesquisas Inode dispendiosas. Em <em>free -m<\/em> essas participa\u00e7\u00f5es aparecem no valor <strong>armazenado em cache<\/strong> tamb\u00e9m, enquanto <strong>buffers<\/strong> refiro-me mais a buffers relacionados com dispositivos de bloco. Em \/proc\/meminfo, vejo isso detalhado de forma mais precisa (por exemplo, dentries, inativo (ficheiro), ativo (ficheiro)). Para cargas de trabalho de alojamento com muitos ficheiros pequenos, esses caches de metadados s\u00e3o essenciais, pois reduzem ainda mais o n\u00famero de acessos reais ao dispositivo por solicita\u00e7\u00e3o HTTP.<\/p>\n\n<h2>Interpretar corretamente os indicadores<\/h2>\n<p>Primeiro, verifico o free -m e observo as colunas para cached, bem como as linhas Mem e Swap, para avaliar com seguran\u00e7a o efeito do cache e a real <strong>Use<\/strong> Para compreender. Em \/proc\/meminfo, leio valores como Cached, Dirty, Writeback e Buffers, que juntos fornecem uma boa imagem do estado da mem\u00f3ria. vmstat 1 mostra continuamente se o sistema est\u00e1 \u00e0 espera devido a I\/O, e iostat complementa os detalhes por dispositivo. Decisivo: o Linux utiliza RAM livre como cache, mas marca-a temporariamente como ocupada, embora as aplica\u00e7\u00f5es possam recuper\u00e1-la imediatamente, se necess\u00e1rio. Portanto, eu sempre avalio a situa\u00e7\u00e3o geral, incluindo <strong>Carga de trabalho<\/strong> e n\u00e3o apenas um \u00fanico n\u00famero.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e9tricas<\/th>\n      <th>Fonte\/Comando<\/th>\n      <th>Significado<\/th>\n      <th>Sinal t\u00edpico<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Em cache<\/td>\n      <td>free -m, \/proc\/meminfo<\/td>\n      <td>Quota de RAM para dados de ficheiros<\/td>\n      <td>Valor elevado em caso de acessos frequentes aos ficheiros<\/td>\n    <\/tr>\n    <tr>\n      <td>Sujo<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>P\u00e1ginas ainda n\u00e3o reescritas<\/td>\n      <td>Aumenta com grava\u00e7\u00f5es intensas, diminui ap\u00f3s a sincroniza\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>Writeback<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>Opera\u00e7\u00f5es de registo ativas<\/td>\n      <td>Valores diferentes de zero na fase de flush<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo (vmstat)<\/td>\n      <td>vmstat 1<\/td>\n      <td>Entrada\/sa\u00edda de E\/S em bloco<\/td>\n      <td>Os picos indicam falhas de cache ou flushes<\/td>\n    <\/tr>\n    <tr>\n      <td>r\/s, w\/s (iostat)<\/td>\n      <td>iostat -xz 1<\/td>\n      <td>Opera\u00e7\u00f5es de leitura\/grava\u00e7\u00e3o por segundo<\/td>\n      <td>Saltos em Misses, ru\u00eddo de fundo constante ok<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linuxcachemeeting2347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Vantagens no dia a dia da hospedagem<\/h2>\n<p>Um cache de p\u00e1gina bem preenchido reduz significativamente os tempos de espera de E\/S e transfere o acesso aos dados do suporte de dados para a RAM, o que diminui consideravelmente a lat\u00eancia de consultas individuais e a <strong>Tempo de resposta<\/strong> de p\u00e1ginas web. Imagens, ficheiros CSS e HTML frequentemente utilizados permanecem na cache, para que o servidor web os sirva sem passar pelo SSD. Em caso de tr\u00e1fego intenso, o que conta \u00e9 a taxa de acertos: quanto mais repeti\u00e7\u00f5es, maior o benef\u00edcio. Em cen\u00e1rios com alta paralelidade, o cache alivia a camada de mem\u00f3ria e suaviza os picos de carga. Para uma compreens\u00e3o mais profunda das rela\u00e7\u00f5es entre caches de mem\u00f3ria, web e proxy, vale a pena dar uma olhada em <a href=\"https:\/\/webhosting.de\/pt\/caching-hierarquias-tecnologia-web-alojamento-boost\/\">Hierarquias de cache<\/a>, para que eu possa utilizar cada n\u00edvel de forma sensata e <strong>Recursos<\/strong> n\u00e3o desperdice.<\/p>\n\n<h2>Influenciar de forma inteligente o tamanho da cache<\/h2>\n<p>Eu influencio o efeito do cache de duas maneiras: mais RAM e menos acessos desnecess\u00e1rios a ficheiros, para que haja espa\u00e7o livre para dados importantes e o kernel possa colocar os blocos corretos no <strong>Cache<\/strong> O Logrotate com Gzip limpa ficheiros de registo grandes, reduz a quantidade de ficheiros na mem\u00f3ria e evita que os registos substituam ativos web importantes. Sempre que poss\u00edvel, marco grandes transfer\u00eancias \u00fanicas, como backups ou dumps SQL, como menos relevantes, processando-as fora dos hor\u00e1rios de pico. S\u00f3 utilizo o esvaziamento manual da cache do kernel com echo 3 &gt; \/proc\/sys\/vm\/drop_caches em testes, pois isso destr\u00f3i a mistura de cache produtiva e a <strong>Lat\u00eancia<\/strong> aumenta temporariamente. No final, o que decide \u00e9 a quantidade de trabalho: quanto melhor ela se encaixar na RAM, mais constante ser\u00e1 o desempenho.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-page-cache-erklaert-7273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>E\/S direta, fsync e consist\u00eancia<\/h2>\n<p>Nem todos os acessos passam pelo cache de p\u00e1gina. Algumas cargas de trabalho abrem ficheiros com O_DIRECT ou O_SYNC, contornando deliberadamente o cache ou for\u00e7ando a persist\u00eancia imediata. Isso \u00e9 \u00fatil quando se deseja evitar o buffer duplo (pool de buffer do banco de dados mais cache de p\u00e1gina) ou quando a consist\u00eancia \u00e9 mais importante do que a lat\u00eancia. Para cargas de trabalho da Web e de m\u00eddia, geralmente mantenho a E\/S normal em buffer, porque a taxa de acertos prevalece na maioria das vezes. Tamb\u00e9m \u00e9 importante compreender o fsync: aplicativos que executam frequentemente o fsync em ficheiros de log impulsionam ciclos de writeback e podem gerar picos de E\/S. Eu agrupo essas chamadas sempre que poss\u00edvel ou defino intervalos de flush de aplica\u00e7\u00e3o de forma sensata para minimizar o <strong>Rendimento<\/strong> manter em alta.<\/p>\n\n<h2>Op\u00e7\u00f5es de montagem: relatime, noatime e outras.<\/h2>\n<p>Cada acesso ao ficheiro pode atualizar o Atime (Access Time) e, assim, desencadear grava\u00e7\u00f5es adicionais. Com <strong>relatime<\/strong> (padr\u00e3o atual), os atimes s\u00e3o ajustados apenas quando necess\u00e1rio, o que reduz significativamente a E\/S. Em cargas de trabalho exclusivamente web, nas quais n\u00e3o \u00e9 utilizada l\u00f3gica baseada em atime, costumo definir <strong>n\u00e3o h\u00e1 tempo<\/strong>, para provocar ainda menos acessos de escrita. Tamb\u00e9m relevante na pr\u00e1tica: tamanhos de bloco adequados, padr\u00f5es de barreira e, se necess\u00e1rio, compress\u00e3o no n\u00edvel do sistema de arquivos, se o padr\u00e3o e a margem da CPU permitirem. Essas op\u00e7\u00f5es de montagem contribuem diretamente para uma maior taxa de acertos do cache, pois menos atualiza\u00e7\u00f5es desnecess\u00e1rias de metadados <strong>Mem\u00f3ria<\/strong>-Os caminhos sobrecarregam.<\/p>\n\n<h2>Contentores e cgroups: cache de p\u00e1gina em opera\u00e7\u00e3o multitenant<\/h2>\n<p>Na hospedagem de contentores, v\u00e1rias cargas de trabalho partilham o cache de p\u00e1gina global. Os limites de mem\u00f3ria atrav\u00e9s de cgroups definem a quantidade de mem\u00f3ria an\u00f3nima (heap\/stack) permitida por contentor, mas o cache de ficheiros \u00e9 gerido pelo kernel do host. Se um contentor estiver sobrecarregado e ler muitos ficheiros novos, poder\u00e1 substituir as p\u00e1ginas de cache de outros contentores. Por isso, utilizo controlos de mem\u00f3ria e E\/S (memory.high, memory.max, io.max) para suavizar picos de carga e aumentar a equidade. O OverlayFS, frequentemente utilizado em contentores, traz camadas de metadados adicionais. Isso pode afetar as resolu\u00e7\u00f5es de caminho e os caminhos de grava\u00e7\u00e3o Copy-on-Write. Eu avalio especificamente se as camadas de sobreposi\u00e7\u00e3o aumentam significativamente a lat\u00eancia e considero bind mounts sem camadas adicionais para ativos est\u00e1ticos.<\/p>\n\n<h2>Pr\u00e9-aquecimento e prote\u00e7\u00e3o da cache<\/h2>\n<p>Ap\u00f3s uma reinicializa\u00e7\u00e3o ou grandes implementa\u00e7\u00f5es, a cache fica vazia. Posso definir hotsets de forma espec\u00edfica. <strong>pr\u00e9-aquecer<\/strong>, lendo sequencialmente os ativos mais procurados. Isso reduz significativamente a lat\u00eancia de arranque a frio nos primeiros minutos. Por outro lado, evito a polui\u00e7\u00e3o do cache: leio ferramentas para backups, verifica\u00e7\u00f5es de malware ou grandes c\u00f3pias sequenciais com baixa prioridade (nice\/ionice) e, se poss\u00edvel, marco-as como menos importantes (DONTNEED) atrav\u00e9s do Fadvise, para que as p\u00e1ginas desapare\u00e7am ap\u00f3s a execu\u00e7\u00e3o. Assim, o cache para o tr\u00e1fego da Web permanece focado nos realmente importantes. <strong>Dados<\/strong>.<\/p>\n\n<h2>NUMA e grandes hosts<\/h2>\n<p>Nos sistemas NUMA, a localiza\u00e7\u00e3o da mem\u00f3ria desempenha um papel importante. A cache de p\u00e1ginas est\u00e1 fisicamente localizada nos n\u00f3s, e os acessos remotos aumentam a lat\u00eancia. Eu presto aten\u00e7\u00e3o \u00e0 liga\u00e7\u00e3o consistente da CPU e da mem\u00f3ria para servi\u00e7os com acesso intenso a ficheiros e verifico se o zone_reclaim_mode \u00e9 adequado. Na pr\u00e1tica, muitas vezes ajuda agrupar processos web e PHP centrais por n\u00f3 NUMA, para que a parte mais quente do cache permane\u00e7a local. Ao mesmo tempo, observo se grandes processos Java ou de base de dados substituem o cache de p\u00e1ginas devido \u00e0s suas pr\u00f3prias necessidades de mem\u00f3ria \u2013 ent\u00e3o, escalo a RAM ou separo as cargas de trabalho.<\/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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NFS e mem\u00f3ria partilhada<\/h2>\n<p>Em configura\u00e7\u00f5es de cluster com NFS ou sistemas de ficheiros de rede semelhantes, o cache \u00e9 mais complicado. O cache de p\u00e1gina atua localmente no host consumidor, enquanto as altera\u00e7\u00f5es em outro n\u00f3 precisam ser invalidadas por meio de protocolos. Portanto, eu calibro os caches de atributos e os intervalos de invalida\u00e7\u00e3o de forma a manter a consist\u00eancia sem gerar muito I\/O. Para ativos web est\u00e1ticos em armazenamento partilhado, vale a pena limitar as revalida\u00e7\u00f5es e tornar as implementa\u00e7\u00f5es at\u00f3micas (por exemplo, troca de diret\u00f3rios), para que o cache n\u00e3o seja limpo desnecessariamente. Sempre que poss\u00edvel, replico hotsets nos n\u00f3s web individuais para obter o m\u00e1ximo <strong>Taxas de acerto<\/strong> alcan\u00e7ar.<\/p>\n\n<h2>Tmpfs e dados ef\u00e9meros<\/h2>\n<p>Para dados tempor\u00e1rios e frequentemente lidos, como ficheiros de sess\u00e3o, artefactos de compila\u00e7\u00e3o ou filas de upload curtas, eu uso <strong>tmpfs<\/strong> . Isso permite-me poupar completamente o acesso aos dispositivos e deixar que a cache da p\u00e1gina se torne, na pr\u00e1tica, o n\u00edvel de armazenamento prim\u00e1rio. No entanto, dimensiono o tmpfs com cuidado: ele utiliza RAM (e, se necess\u00e1rio, swap), e montagens tmpfs demasiado grandes podem ocupar espa\u00e7o de outras caches. Um processo de limpeza regular (por exemplo, systemd-tmpfiles) evita que os dados se acumulem e esgotem a mem\u00f3ria de trabalho.<\/p>\n\n<h2>Padr\u00f5es de carga de trabalho: pequeno vs. grande, sequencial vs. aleat\u00f3rio<\/h2>\n<p>O comportamento ideal da cache depende muito do padr\u00e3o. Muitos ficheiros pequenos e recorrentes beneficiam ao m\u00e1ximo do LRU e de uma propor\u00e7\u00e3o elevada. <strong>Ativo (ficheiro)<\/strong>. Por outro lado, ficheiros grandes, lidos uma \u00fanica vez (backups, transcodifica\u00e7\u00f5es de m\u00eddia), n\u00e3o devem dominar a cache. Eu defino read_ahead_kb moderadamente para que os leitores sequenciais fiquem mais r\u00e1pidos, sem inflar os acessos aleat\u00f3rios. Em servidores web com muitos ficheiros est\u00e1ticos, eu ativo caminhos zero-copy (sendfile, splice) para evitar c\u00f3pias no espa\u00e7o do utilizador \u2013 o cache de p\u00e1gina ent\u00e3o fornece diretamente no soquete, o que economiza CPU e suaviza a lat\u00eancia.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Observa\u00e7\u00e3o aprofundada e sintomas<\/h2>\n<p>Al\u00e9m do vmstat e do iostat, se necess\u00e1rio, consulto as estat\u00edsticas de recupera\u00e7\u00e3o (por exemplo, Active\/Inactive, pgscan\/pgsteal atrav\u00e9s do \/proc\/meminfo) para verificar se o sistema est\u00e1 a recuperar p\u00e1ginas de forma agressiva. Falhas de p\u00e1gina graves frequentes, valores crescentes de espera de IO e tempos de writeback persistentemente elevados indicam que a cache est\u00e1 sob press\u00e3o. Nestas fases, verifico primeiro se posso reduzir a carga de trabalho ou aumentar a RAM. Se as falhas continuarem elevadas, segmento os dados (por exemplo, separando arquivos raros e recursos web usados com frequ\u00eancia) para que o mecanismo LRU d\u00ea prefer\u00eancia aos blocos corretos.<\/p>\n\n<h2>Regras pr\u00e1ticas<\/h2>\n<ul>\n  <li>Estou a planear o <strong>RAM<\/strong> de forma que os Hotsets (ativos est\u00e1ticos da web + partes ativas de bases de dados) caibam 1 a 2 vezes. Isso duplica a chance de acertos de cache em picos de tr\u00e1fego.<\/li>\n  <li>Evito consistentemente o swapping: assim que as p\u00e1ginas an\u00f3nimas s\u00e3o transferidas, o pager compete com o cache de p\u00e1ginas pela E\/S \u2013 as lat\u00eancias come\u00e7am a diminuir. Mantenho o swappiness moderado.<\/li>\n  <li>Eu rodo os ficheiros de registo mais rapidamente, comprimo as gera\u00e7\u00f5es mais antigas e garanto que os registos de conversa\u00e7\u00e3o n\u00e3o disputem espa\u00e7o na cache com os recursos da web.<\/li>\n  <li>Eu agrupo implementa\u00e7\u00f5es que alteram muitos ficheiros em poucas etapas at\u00f3micas. Assim, invalido menos entradas de cache de uma s\u00f3 vez e mantenho a <strong>Taxa de acerto<\/strong> elevado.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sistemas de ficheiros e acessos \u00e0 cache<\/h2>\n<p>O sistema de ficheiros influencia a efici\u00eancia com que o kernel armazena e grava dados, por isso conhe\u00e7o as caracter\u00edsticas do Ext4, XFS e ZFS e adapto a escolha \u00e0s minhas cargas de trabalho, para que o <strong>Cache<\/strong> funciona de forma ideal. O Ext4 oferece um desempenho geral s\u00f3lido, o XFS destaca-se em cargas de escrita paralelas e o ZFS traz os seus pr\u00f3prios n\u00edveis de cache, como o ARC. Dependendo do padr\u00e3o \u2013 muitos ficheiros pequenos versus grandes objetos de m\u00eddia \u2013, os metadados e os caminhos de escrita comportam-se de forma diferente. Eu avalio cargas de trabalho reais antes de definir a plataforma. Para obter uma vis\u00e3o geral compacta, utilizo o artigo <a href=\"https:\/\/webhosting.de\/pt\/ext4-xfs-zfs-comparacao-de-desempenho-de-alojamento-armazenamento\/\">Ext4, XFS e ZFS em compara\u00e7\u00e3o<\/a> e alinhe configura\u00e7\u00f5es como op\u00e7\u00f5es de montagem, para que o kernel n\u00e3o execute <strong>Senhoras<\/strong> produzido.<\/p>\n\n<h2>Bases de dados, Opcache e Page Cache<\/h2>\n<p>No MySQL ou MariaDB, o InnoDB Buffer Pool assume a maior parte das p\u00e1ginas de dados e \u00edndices, enquanto o Page Cache acelera adicionalmente os blocos do sistema de ficheiros, reduzindo assim o I\/O total, o que <strong>Consulta<\/strong>-Lat\u00eancias reduzidas. Eu configuro o buffer pool com um tamanho suficiente para acomodar os hotsets, caso contr\u00e1rio, o motor produz acessos desnecess\u00e1rios ao disco r\u00edgido. Para aplica\u00e7\u00f5es PHP, combino Opcache para bytecode e APCu para dados relacionados \u00e0 aplica\u00e7\u00e3o, reduzindo assim a press\u00e3o sobre o cache de p\u00e1gina. Os ativos est\u00e1ticos continuam a ser candidatos para o cache do sistema de ficheiros e carregam rapidamente. Essa camada evita trabalho duplicado e mant\u00e9m o <strong>CPU<\/strong> livre para partes din\u00e2micas.<\/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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e diagn\u00f3stico<\/h2>\n<p>Eu observo o vmstat 1 para sinais de mem\u00f3ria e E\/S em tempo real, verifico o iostat -xz 1 por dispositivo e procuro em \/proc\/meminfo por Dirty, Cached, Writeback, para que eu possa limitar rapidamente as causas e agir de forma direcionada. <strong>ato<\/strong> pode. Um valor IO-Wait permanentemente elevado indica congestionamentos, que eu primeiro atenuo com cache e RAM. Em seguida, verifico se o sistema de ficheiros, RAID ou firmware SSD est\u00e3o a causar lentid\u00e3o. Se o IO-Wait continuar cr\u00edtico, analiso os acessos \u00e0 aplica\u00e7\u00e3o e as taxas de acerto do cache. Para uma introdu\u00e7\u00e3o aos caminhos de diagn\u00f3stico, o <a href=\"https:\/\/webhosting.de\/pt\/io-wait-compreender-gargalo-de-memoria-resolver-otimizacao\/\">Entender IO-Wait<\/a>, para separar os sintomas das causas e realizar um tratamento direcionado <strong>Passos<\/strong> deduzir.<\/p>\n\n<h2>Par\u00e2metros de ajuste sem riscos<\/h2>\n<p>Eu apenas ajusto alguns par\u00e2metros do kernel e testo as altera\u00e7\u00f5es de forma controlada, porque existem bons padr\u00f5es e pequenas corre\u00e7\u00f5es geralmente s\u00e3o suficientes para <strong>Efici\u00eancia<\/strong> para ganhar. vm.dirty_background_bytes determina a partir de que limite o sistema come\u00e7a a escrever de forma ass\u00edncrona, enquanto vm.dirty_bytes define o limite superior para p\u00e1ginas sujas. Quem definir esses valores em bytes em vez de percentagem obt\u00e9m uma base est\u00e1vel, independentemente da expans\u00e3o da RAM. Al\u00e9m disso, read_ahead_kb influencia o pr\u00e9-carregamento de dados por dispositivo de bloco, o que acelera a leitura sequencial, mas permanece neutro em acessos aleat\u00f3rios. Eu documento todas as etapas e, em caso de efeitos colaterais, volto rapidamente \u00e0s configura\u00e7\u00f5es originais. <strong>Valores<\/strong> de volta.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Recursos modernos explicados resumidamente<\/h2>\n<p>As p\u00e1ginas transparentes enormes (THP) podem agrupar p\u00e1ginas suportadas por ficheiros em unidades maiores, o que reduz os custos administrativos por p\u00e1gina e beneficia o TLB quando as cargas de trabalho s\u00e3o demasiado grandes e cont\u00edguas. <strong>Quantidades<\/strong> adequadas. Em ambientes de alojamento com acessos altamente aleat\u00f3rios, verifico cuidadosamente o efeito, uma vez que as vantagens n\u00e3o s\u00e3o garantidas. Por outro lado, a mem\u00f3ria persistente promete lat\u00eancias muito baixas e abre novos caminhos de dados que contornam parcialmente o fluxo cl\u00e1ssico da cache de p\u00e1gina. Aqui, observo os benchmarks e avalio se a aplica\u00e7\u00e3o beneficia realmente das novas classes de mem\u00f3ria. Realizo experi\u00eancias precoces separadamente do <strong>Em direto<\/strong>-Tr\u00e1fego.<\/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\/2025\/12\/linux-hosting-cache-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumo: O que eu levo comigo<\/h2>\n<p>O Linux Page Cache acelera as cargas de trabalho de alojamento, transferindo opera\u00e7\u00f5es frequentes de ficheiros para a RAM, reduzindo assim as lat\u00eancias, diminuindo a carga de E\/S e aumentando a <strong>Escalonamento<\/strong> melhorado. Eu me\u00e7o valores significativos, reconhe\u00e7o interpreta\u00e7\u00f5es erradas no free -m e uso \/proc\/meminfo, vmstat, iostat para obter uma vis\u00e3o completa. Com o Logrotate, RAM suficiente, limites de kernel adequados e PHP-Opcache, aumento o desempenho sem interven\u00e7\u00f5es arriscadas. Escolho os sistemas de ficheiros tendo em conta os perfis de acesso e observo o IO-Wait para eliminar atempadamente os pontos de estrangulamento. Assim, mantenho os acessos web recorrentes na cache, alivio a carga do <strong>Mem\u00f3ria<\/strong>e entregue p\u00e1ginas rapidamente.<\/p>","protected":false},"excerpt":{"rendered":"<p>Cache do sistema de ficheiros na hospedagem Linux: compreender corretamente o cache de p\u00e1ginas do Linux e maximizar o desempenho do servidor.<\/p>","protected":false},"author":1,"featured_media":16414,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-16421","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":"1500","_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":null,"_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 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":"16414","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16421","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=16421"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/16421\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/16414"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=16421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=16421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=16421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}