{"id":20548,"date":"2026-08-11T15:09:51","date_gmt":"2026-08-11T13:09:51","guid":{"rendered":"https:\/\/webhosting.de\/writeback-cache-linux-kernel-cache\/"},"modified":"2026-08-11T15:09:51","modified_gmt":"2026-08-11T13:09:51","slug":"cache-de-reescrita-cache-do-kernel-do-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"Compreender a cache de reescrita e as p\u00e1ginas sujas no kernel do Linux"},"content":{"rendered":"<p>A cache de reescrita no kernel do Linux controla quando os dados alterados s\u00e3o gravados como <strong>P\u00e1ginas sujas<\/strong> permanecem na RAM e quando \u00e9 que o kernel as grava, agrupadas, no suporte de armazenamento. Vou explicar como funciona este processo <strong>Desempenho<\/strong>, as lat\u00eancias e a seguran\u00e7a dos dados, e quais s\u00e3o os controladores que realmente importam no dia a dia.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>P\u00e1ginas sujas<\/strong> marcam as p\u00e1ginas alteradas na RAM que ainda n\u00e3o se encontram no suporte de dados.<\/li>\n  <li><strong>Writeback<\/strong> agrupa as altera\u00e7\u00f5es e grava-as de forma eficiente em blocos maiores.<\/li>\n  <li><strong>Valores de limiar<\/strong> Tal como o vm.dirty_ratio, controla a velocidade e a limita\u00e7\u00e3o.<\/li>\n  <li><strong>Sincroniza\u00e7\u00e3o<\/strong> O uso do fsync\/Flush protege contra a perda de dados.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> Atrav\u00e9s de \/proc e das ferramentas, \u00e9 poss\u00edvel visualizar a carga e os atrasos.<\/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\/linuxserver-writeback-3901.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funciona a cache de p\u00e1ginas<\/h2>\n\n<p>Eu leio um ficheiro, o kernel coloca os dados na cache de p\u00e1ginas e os acessos posteriores s\u00e3o efetuados a partir da <strong>Mem\u00f3ria<\/strong> em vez de a partir do disco. Durante a grava\u00e7\u00e3o, o sistema marca as p\u00e1ginas alteradas como <strong>Sujo<\/strong> e, muitas vezes, confirma a chamada imediatamente, para que a aplica\u00e7\u00e3o continue a funcionar. Esta dissocia\u00e7\u00e3o reduz os tempos de espera, uma vez que os acessos de E\/S lentos n\u00e3o travam diretamente todas as aplica\u00e7\u00f5es. Al\u00e9m disso, a cache mant\u00e9m os blocos mais utilizados \u00e0 disposi\u00e7\u00e3o e aumenta a taxa de acertos em acessos subsequentes. Quem quiser aprofundar o assunto pode encontrar mais informa\u00e7\u00f5es na minha 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>, que ilustra o papel dos percursos de leitura e escrita no dia-a-dia.<\/p>\n\n<h2>P\u00e1ginas obscenas: significado e consequ\u00eancias<\/h2>\n\n<p>As \u00abDirty Pages\u00bb s\u00e3o p\u00e1ginas de mem\u00f3ria que foram alteradas, mas que ainda n\u00e3o foram guardadas de forma permanente e, por isso, s\u00f3 est\u00e3o dispon\u00edveis na <strong>RAM<\/strong> existem. Enquanto estiverem sujos, uso um certo <strong>Risco<\/strong>: Uma falha de energia poderia anular estas altera\u00e7\u00f5es. Ainda assim, consigo assim uma taxa de grava\u00e7\u00e3o mais elevada, porque o kernel agrupa muitas pequenas atualiza\u00e7\u00f5es. Se a percentagem de p\u00e1ginas sujas aumentar, a press\u00e3o sobre os m\u00f3dulos de reescrita tamb\u00e9m aumenta. Nesse caso, o sistema pode libertar mem\u00f3ria, gravando as p\u00e1ginas em quest\u00e3o na unidade de armazenamento de forma priorit\u00e1ria.<\/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_kernel_meeting_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Revers\u00e3o: fatores desencadeantes e processo<\/h2>\n\n<p>A revers\u00e3o de valores \u00e9 executada de forma programada, acionada por eventos e a pedido <strong>Apps<\/strong>. O kernel agrupa as p\u00e1ginas sujas, cria sequ\u00eancias de E\/S adequadas e envia-as atrav\u00e9s da camada de blocos para o <strong>Dispositivo de armazenamento<\/strong>. Ao longo do processo, os sistemas de ficheiros, os mecanismos de recupera\u00e7\u00e3o e os agendadores de E\/S interv\u00eam para controlar a ordem e o tamanho. Chamadas de sincroniza\u00e7\u00e3o, como o fsync, garantem que determinados dados sejam gravados com seguran\u00e7a no suporte antes de se prosseguir. Em fases de elevada atividade, observo nas estat\u00edsticas uma percentagem crescente de writeback, que volta a diminuir ap\u00f3s o flush.<\/p>\n\n<h2>Mecanismos internos: balance_dirty_pages, BDI e Writeback-Worker<\/h2>\n\n<p>Nos bastidores, v\u00e1rios componentes interagem entre si. Os threads de escrita percorrem <strong>balance_dirty_pages()<\/strong>, que tem em conta a carga suja atual, a velocidade do dispositivo e os limites definidos. Este sistema regula a taxa de grava\u00e7\u00e3o dos processos (throttling), para que a grava\u00e7\u00e3o em segundo plano consiga acompanhar o ritmo. Cada <strong>Dispositivo de apoio<\/strong>-Contexto (bdi) \u2013 normalmente um dispositivo de bloco ou um backend de sistema de ficheiros \u2013 possui as suas pr\u00f3prias filas de trabalho com <strong>T\u00f3picos de limpeza<\/strong>, que convertem as \u00abDirty Pages\u00bb em pedidos de E\/S ordenados. Esta reparti\u00e7\u00e3o evita que um dispositivo lento atrase todos os outros e melhora a equidade entre as cargas de trabalho.<\/p>\n\n<p>A limita\u00e7\u00e3o \u00e9 adaptativa: quando deteto gravadores mais r\u00e1pidos ou blocos cont\u00edguos maiores, os limites de dados sujos permitidos aumentam a curto prazo. Em caso de congestionamentos, lat\u00eancias elevadas ou filas saturadas, o kernel aplica o trav\u00e3o de forma mais agressiva e obriga os escritores a fazer pausas at\u00e9 que o buffer volte a ter margem. \u00c9 precisamente esta intera\u00e7\u00e3o que explica por que raz\u00e3o pequenas altera\u00e7\u00f5es nos par\u00e2metros podem conduzir a perfis de lat\u00eancia visivelmente diferentes.<\/p>\n\n<h2>Valores-limite: vm.dirty_background_ratio e vm.dirty_ratio<\/h2>\n\n<p>Controlo esse comportamento atrav\u00e9s de dois limites importantes, que determinam a propor\u00e7\u00e3o de p\u00e1ginas contaminadas em rela\u00e7\u00e3o ao <strong>RAM<\/strong> definir. Se eu ultrapassar o valor de refer\u00eancia, o kernel come\u00e7a a <strong>Contexto<\/strong> de escrita. Se atingir o limite m\u00e1ximo, o sistema limita os processos de escrita at\u00e9 que sejam devolvidos dados suficientes. Desta forma, a mem\u00f3ria permanece dispon\u00edvel, mesmo que alguns programas gerem grandes quantidades de altera\u00e7\u00f5es. Quem trabalha com limites baseados em bytes deve definir os par\u00e2metros *_bytes correspondentes, em vez dos valores de r\u00e1cio.<\/p>\n\n<h2>Tabela: Par\u00e2metros relevantes do kernel e indicadores-chave<\/h2>\n\n<p>Utilizo alguns controlos centrais para gerir de forma espec\u00edfica o writeback, a lat\u00eancia e o d\u00e9bito, e para os tornar vis\u00edveis; a seguinte vis\u00e3o geral ajuda a <strong>Classifica\u00e7\u00e3o<\/strong> e r\u00e1pido <strong>Exame<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metro\/Indicador<\/th>\n      <th>Efeito<\/th>\n      <th>Valores iniciais\/Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Inicia o writeback em segundo plano quando a percentagem de p\u00e1ginas corrompidas ultrapassar este valor-limite.<\/td>\n      <td>No caso dos servidores, opte por uma configura\u00e7\u00e3o mais conservadora, para que o Flush comece a funcionar mais cedo.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>Limite m\u00e1ximo para as \u00abDirty Pages\u00bb; a partir daqui, os gravadores s\u00e3o limitados.<\/td>\n      <td>Se for demasiado elevada, aumenta os riscos de lat\u00eancia; se for demasiado baixa, desperdi\u00e7a a taxa de transfer\u00eancia.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisegundos<\/td>\n      <td>Intervalo durante o qual o kernel verifica as p\u00e1ginas sujas para a limpeza em segundo plano.<\/td>\n      <td>Intervalos mais curtos suavizam os picos de carga, mas geram mais ativa\u00e7\u00f5es.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>Idade a partir da qual as \u201eDirty Pages\u201c s\u00e3o consideradas \u00abadequadas\u00bb e passam a ser escritas com prioridade.<\/td>\n      <td>Valores mais elevados proporcionam uma maior centraliza\u00e7\u00e3o, mas reduzem as garantias de consist\u00eancia em caso de erro.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo: Dirty, Writeback<\/td>\n      <td>Quantidade atual de p\u00e1ginas sujas ou que foram efetivamente anuladas.<\/td>\n      <td>\u00datil para observa\u00e7\u00e3o em tempo real durante testes de carga.<\/td>\n    <\/tr>\n    <tr>\n      <td>Op\u00e7\u00f5es de montagem\/FS (por exemplo, barreiras, modo de registo)<\/td>\n      <td>Influenciam a ordem, a persist\u00eancia e os custos de cada flush.<\/td>\n      <td>Selecione a op\u00e7\u00e3o adequada, consoante o sistema de ficheiros e o dispositivo.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Leio estes valores regularmente e correlaciono-os com os tempos de espera de E\/S no Top, no iostat ou em ferramentas semelhantes <strong>Ferramentas<\/strong>. Isto permite perceber claramente se o pr\u00f3prio Writeback est\u00e1 a limitar-se ou se o <strong>Armazenamento<\/strong> est\u00e1 no limite.<\/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-kernel-cache-dirty-pages-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e diagn\u00f3stico: o que eu me\u00e7o<\/h2>\n\n<p>Primeiro, verifico o ficheiro \/proc\/meminfo e observo os campos \u00abDirty\u00bb e \u00abWriteback\u00bb, enquanto, de forma espec\u00edfica, <strong>Carga<\/strong> gerar. Se os \u00abDirty\u00bb subirem fortemente e se mantiverem elevados, muitas vezes faltam \u00abflushes\u00bb oportunos ou o <strong>M\u00e9dio<\/strong> est\u00e1 a funcionar a plena capacidade. Se o Writeback aumenta, mas o Dirty diminui apenas lentamente, isso est\u00e1 a travar o dispositivo de destino ou o caminho de E\/S. Se os picos de lat\u00eancia coincidirem com os picos de Writeback, suavizo o intervalo ou reduzo os valores da taxa. Para me familiarizar com os padr\u00f5es t\u00edpicos, ajuda-me um breve <a href=\"https:\/\/webhosting.de\/pt\/otimizador-de-desempenho-do-cache-de-paginas-do-linux\/\">Potenciador da cache de p\u00e1ginas<\/a>, que re\u00fane os parafusos de ajuste e os pontos de medi\u00e7\u00e3o.<\/p>\n\n<h2>Pontos de medi\u00e7\u00e3o avan\u00e7ados, vmstat e rastreamento<\/h2>\n\n<p>Para al\u00e9m do \/proc\/meminfo, recorro a contadores de alta granularidade para distinguir causa e efeito. Em <strong>\/proc\/vmstat<\/strong> Campos como nr_dirty, nr_writeback, nr_dirtied e nr_written fornecem indica\u00e7\u00f5es sobre a din\u00e2mica: com que rapidez ocorre a contamina\u00e7\u00e3o e com que rapidez \u00e9 efetuada a limpeza? Al\u00e9m disso, observo o comprimento das filas de E\/S e as taxas de interrup\u00e7\u00e3o das opera\u00e7\u00f5es de fus\u00e3o na camada de blocos.<\/p>\n\n<ul>\n  <li>vmstat 1: mostra, por segundo, o desvio de Dirty\/Writeback e a espera de E\/S (wa),<\/li>\n  <li>\/proc\/pressure\/memory: revela a press\u00e3o de mem\u00f3ria que desencadeia indiretamente o writeback,<\/li>\n  <li>Pontos de rastreio (writeback:*) e eventos de bloco: revelam a ordem e o tamanho das opera\u00e7\u00f5es de flush,<\/li>\n  <li>perf\/ftrace: identifica pontos cr\u00edticos em balance_dirty_pages e nas filas de trabalho do Flusher.<\/li>\n<\/ul>\n\n<p>Quando vejo que o valor de nr_dirtied se mant\u00e9m constantemente superior ao de nr_written, isso \u00e9 um sinal claro de que se aproxima uma limita\u00e7\u00e3o de desempenho ou de que as limpezas em segundo plano est\u00e3o a ser realizadas demasiado tarde. Se os picos nos pontos de rastreio de writeback coincidirem com picos de lat\u00eancia, otimizo o intervalo e os tamanhos dos lotes.<\/p>\n\n<h2>HDD vs. SSD: Implica\u00e7\u00f5es no design do writeback<\/h2>\n\n<p>Em rolos girat\u00f3rios, as sequ\u00eancias cont\u00ednuas de cartas mais altas rendem particularmente bem, porque evitam a dispendiosa busca <strong>Evitar<\/strong>. Os SSDs tamb\u00e9m beneficiam, mas, neste caso, o que conta \u00e9 a distribui\u00e7\u00e3o das grava\u00e7\u00f5es e a intera\u00e7\u00e3o com o <strong>Controlador<\/strong>. Evito um n\u00famero excessivo de pequenas sincroniza\u00e7\u00f5es, para que o firmware possa funcionar de forma eficiente. Ao mesmo tempo, presto cada vez mais aten\u00e7\u00e3o \u00e0s barreiras de consist\u00eancia e \u00e0 sem\u00e2ntica de flush nos SSDs, para tirar verdadeiramente partido das garantias do dispositivo. As cargas de trabalho mistas, com leituras e grava\u00e7\u00f5es aleat\u00f3rias, reagem de forma percet\u00edvel a pequenos ajustes nos limiares de \u00abdirty\u00bb e no tempo de flush.<\/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\/tech_office_nacht_6342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cache do dispositivo, sem\u00e2ntica de limpeza e prote\u00e7\u00e3o contra falhas de energia (PLP)<\/h2>\n\n<p>O facto de um flush persistir realmente depende tamb\u00e9m do <strong>Cache do dispositivo<\/strong> . Muitas unidades de disco armazenam dados em buffer na sua pr\u00f3pria DRAM. Sem <strong>Prote\u00e7\u00e3o contra perdas de energia (PLP)<\/strong> Corro o risco de perder dados se a cache n\u00e3o for esvaziada atempadamente. Embora o \u00abwriteback\u00bb tire partido da cache do dispositivo, certifico-me de que as barreiras e os comandos de esvaziamento s\u00e3o respeitados. Em sistemas com controladores RAID, avalio se existe um cache alimentado por bateria ou por mem\u00f3ria flash; nesse caso, as grava\u00e7\u00f5es sincronizadas s\u00e3o frequentemente mais vantajosas, sem comprometer a seguran\u00e7a.<\/p>\n\n<p>Al\u00e9m disso, fa\u00e7o a seguinte distin\u00e7\u00e3o: o FUA (Force Unit Access) imp\u00f5e a persist\u00eancia por cada opera\u00e7\u00e3o de E\/S, mas tem um custo em termos de IOPS. As barreiras de flush podem guardar v\u00e1rias grava\u00e7\u00f5es em simult\u00e2neo. Para percursos particularmente cr\u00edticos (como os di\u00e1rios), aceito a sobrecarga do FUA\/flush, enquanto mantenho os dados em massa no fluxo de grava\u00e7\u00e3o posterior. Quem alterar as op\u00e7\u00f5es de montagem ou as defini\u00e7\u00f5es do controlador deve, posteriormente, verificar atrav\u00e9s de testes de carga se a sem\u00e2ntica de flush pretendida est\u00e1 a funcionar.<\/p>\n\n<h2>Consist\u00eancia dos dados: utilizar corretamente o fsync, o Flush e o FUA<\/h2>\n\n<p>Utilizo o fsync especificamente para dados com elevado <strong>Valor<\/strong>, que necessitam de uma garantia clara de durabilidade. O kernel pode conduzir as opera\u00e7\u00f5es de flush at\u00e9 ao suporte e, com o FUA, garantir que uma grava\u00e7\u00e3o seja realmente <strong>persiste<\/strong>, antes de receber a confirma\u00e7\u00e3o. Este procedimento consome tempo e IOPS, mas evita a perda de dados em caso de falhas. Sem essas barreiras, o sistema reporta as opera\u00e7\u00f5es como bem-sucedidas, embora os bytes ainda se encontrem na cache do SSD ou na RAM. Coordeno estas decis\u00f5es com a aplica\u00e7\u00e3o: os registos de transa\u00e7\u00f5es s\u00e3o guardados de forma definitiva, enquanto as atualiza\u00e7\u00f5es em massa s\u00e3o guardadas de forma provis\u00f3ria.<\/p>\n\n<h2>Exemplos de otimiza\u00e7\u00e3o para cargas de trabalho de alojamento e bases de dados<\/h2>\n\n<p>Para servidores Web e de bases de dados, costumo definir um valor moderado para o `dirty_background_ratio` e mantenho o `dirty_ratio` significativamente acima desse valor, para que a limpeza em segundo plano ocorra atempadamente <strong>in\u00edcio<\/strong>, sem que o Schreiber se precipitasse <strong>Trav\u00e3o<\/strong>. Em picos de grava\u00e7\u00e3o, reduzo o intervalo de reescrita para que os mecanismos de reescrita entrem em a\u00e7\u00e3o mais cedo. Em sistemas com muita RAM, prefiro valores em *_bytes, para que sejam utilizados valores reais em vez de percentagens. Testo cada altera\u00e7\u00e3o com benchmarks repet\u00edveis e me\u00e7o a lat\u00eancia, o d\u00e9bito e os percentis 95 e 99. Esta vis\u00e3o geral pr\u00e1tica fornece-me um guia conciso sobre o efeito da cache de p\u00e1ginas: <a href=\"https:\/\/webhosting.de\/pt\/otimizador-de-desempenho-do-cache-de-paginas-do-linux\/\">Otimizador de desempenho do cache de p\u00e1ginas do Linux<\/a>.<\/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\/devdesk_linux_cache_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>I\/O direto e mmap: quando o cache de p\u00e1ginas \u00e9 contornado<\/h2>\n\n<p>Nem todas as aplica\u00e7\u00f5es utilizam o cache de p\u00e1ginas da mesma forma. Com <strong>O_DIRECTO<\/strong> pode contornar deliberadamente a cache e escrever ou ler diretamente no dispositivo. Isso alivia a carga na RAM e encurta os percursos, mas priva-me das vantagens do processamento em lote e da leitura antecipada. Para transfer\u00eancias grandes e pontuais, isso pode fazer sentido; por outro lado, no caso de muitas pequenas grava\u00e7\u00f5es, perco as vantagens do writeback.<\/p>\n\n<p>Com <strong>mapa<\/strong> e, com o Copy-on-Write, marco as p\u00e1ginas como \u00abdirty\u00bb quando s\u00e3o alteradas; o flush \u00e9 efetuado atrav\u00e9s do caminho normal de writeback ou atrav\u00e9s de <strong>msync<\/strong>. Tenho isso em conta quando as aplica\u00e7\u00f5es dependem fortemente da E\/S mapeada em mem\u00f3ria: podem ocorrer picos de dados sujos de forma inesperada, apesar de a aplica\u00e7\u00e3o \u201eapenas\u201c gravar na mem\u00f3ria. Tamb\u00e9m neste caso, os limites de r\u00e1cio\/bytes ajudam a controlar o momento da grava\u00e7\u00e3o.<\/p>\n\n<h2>Ambientes de contentores e writeback do cgroup<\/h2>\n\n<p>Em configura\u00e7\u00f5es multi-tenant, evito os \u201evizinhos ruidosos\u201c atrav\u00e9s de <strong>cgroups<\/strong>. O kernel atribui as p\u00e1ginas sujas ao grupo respons\u00e1vel (cgroup-Writeback), de modo a que o esvaziamento em segundo plano e a regula\u00e7\u00e3o de fluxo sejam distribu\u00eddos de forma mais equitativa. Com limites de mem\u00f3ria (<strong>mem\u00f3ria.alta<\/strong>, memory.max) limito os picos de mem\u00f3ria suja por contentor. Al\u00e9m disso, defino quotas de E\/S atrav\u00e9s do controlador de E\/S, para evitar que cargas de trabalho individuais ocupem toda a fila do dispositivo.<\/p>\n\n<p>Na pr\u00e1tica, defino limites m\u00e1ximos realistas para cada classe de servi\u00e7o: os trabalhos em lote com elevada carga de grava\u00e7\u00e3o recebem \u00abDirty Budgets\u00bb mais amplos, enquanto os front-ends sens\u00edveis \u00e0 lat\u00eancia recebem limites mais restritos. Desta forma, a lat\u00eancia total mant\u00e9m-se mais est\u00e1vel, uma vez que o Writeback n\u00e3o reduz abruptamente a capacidade para todos assim que um \u00fanico contentor sai do normal.<\/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-kernel-cache-8974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sistemas de ficheiros em rede (NFS, SMB, sistemas de ficheiros distribu\u00eddos)<\/h2>\n\n<p>Nos sistemas de ficheiros em rede, existe um n\u00edvel adicional de buffer. As p\u00e1ginas sujas locais apenas indicam que os dados est\u00e3o a ser transferidos; se estes <strong>remoto<\/strong> A decis\u00e3o sobre quais dados s\u00e3o persistidos cabe ao protocolo (sem\u00e2ntica de commit) e ao servidor. N\u00e3o confio em flushes impl\u00edcitos: sincronizo explicitamente os dados cr\u00edticos. Ao mesmo tempo, tenho em conta os custos de ida e volta \u2013 sincroniza\u00e7\u00f5es demasiado frequentes atrav\u00e9s da rede agravam sensivelmente as lat\u00eancias.<\/p>\n\n<p>Em cargas de trabalho mistas, separo os caminhos: os ficheiros locais e tempor\u00e1rios tiram o m\u00e1ximo partido da cache de p\u00e1ginas; as montagens de rede t\u00eam pontos de sincroniza\u00e7\u00e3o mais rigorosos. Desta forma, evito que o \u00abwriteback\u00bb atrav\u00e9s da rede se torne um gargalo, enquanto as tarefas locais ainda t\u00eam reservas.<\/p>\n\n<h2>Agendador de E\/S, blk-mq e profundidade da fila<\/h2>\n\n<p>A efici\u00eancia com que os lotes de reescrita chegam ao dispositivo depende tamb\u00e9m do <strong>Blocklayer<\/strong> a partir de. Com <strong>blk-mq<\/strong> As opera\u00e7\u00f5es de E\/S distribuem-se por v\u00e1rias filas; os agendadores, como o mq-deadline ou o kyber, estabelecem prioridades e organizam-nas. Escolho o agendador adequado ao suporte: no NVMe, a op\u00e7\u00e3o \u201enone\u201c \u00e9 frequentemente a mais adequada; no caso do SATA ou do SAS, o Deadline ajuda a organizar as grava\u00e7\u00f5es.<\/p>\n\n<p>O <strong>Profundidade da fila<\/strong> Defino-o de forma a que o dispositivo esteja a funcionar a plena capacidade, mas sem ficar sobrecarregado. Se for demasiado raso, desperdi\u00e7a-se o d\u00e9bito; se for demasiado profundo, aumenta a dispers\u00e3o da lat\u00eancia e torna o estrangulamento mais dif\u00edcil de gerir. O writeback beneficia de profundidades moderadas e de pedidos grandes e cont\u00ednuos. Observo as taxas de fus\u00e3o e os contadores \u201einflight\u201c; taxas de fus\u00e3o em queda indicam lotes demasiado pequenos ou cargas de trabalho aleat\u00f3rias concorrentes.<\/p>\n\n<h2>Testes reproduz\u00edveis e revers\u00e3o segura<\/h2>\n\n<p>Antes de ajustar os reguladores, registo o estado atual e verifico <strong>Reprodut\u00edvel<\/strong> e planeio retrocessos. Utilizo cargas de trabalho id\u00eanticas, volumes de dados id\u00eanticos e pr\u00e9-aqueco o cache de forma espec\u00edfica ou esvazio-o deliberadamente, para tornar os testes compar\u00e1veis. Aplico primeiro as altera\u00e7\u00f5es de configura\u00e7\u00e3o de forma tempor\u00e1ria, observo as m\u00e9tricas e s\u00f3 depois as registo de forma permanente.<\/p>\n\n<pre><code># Exemplo: ajustes tempor\u00e1rios (Root)\nsysctl -w vm.dirty_background_bytes=$((512*1024*1024))\nsysctl -w vm.dirty_bytes=$((2*1024*1024*1024))\nsysctl -w vm.dirty_writeback_centisecs=100\nsysctl -w vm.dirty_expire_centisecs=3000\n\n# Teste de carga curto (exemplo, dependente da carga de trabalho)\n# fio --name=wbtest --filename=\/data\/testfile --size=8G --ioengine=libaio \\\n#     --rw=randwrite --bs=128k --iodepth=32 --direct=0 --numjobs=4 --runtime=60 --time_based\n<\/code><\/pre>\n\n<p>Entretanto, leio em paralelo os ficheiros \/proc\/meminfo, vmstat e iostat e correlaciono os picos. Ap\u00f3s o teste, reinicio os valores ou incorporo-os de forma controlada na configura\u00e7\u00e3o do sistema. Para tal, documento <strong>data<\/strong>, <strong>Kernel<\/strong>- Vers\u00e3o, detalhes do dispositivo e do sistema de ficheiros, para que as compara\u00e7\u00f5es posteriores sejam fi\u00e1veis.<\/p>\n\n<h2>Problemas frequentes e medidas corretivas<\/h2>\n\n<p>Se o sistema parecer funcionar com fluidez, mas as opera\u00e7\u00f5es de escrita ficarem lentas, verifico se h\u00e1 limita\u00e7\u00e3o de desempenho devido a um valor demasiado baixo de <strong>r\u00e1cio de sujidade<\/strong>. Se o \u00abDirty\u00bb se mantiver num n\u00edvel elevado, falta largura de banda ou o <strong>Intervalo<\/strong> \u00c9 demasiado longo para o flush. Se as lat\u00eancias dispararem durante picos de sincroniza\u00e7\u00e3o curtos, distribuo a carga por lotes mais pequenos e otimizo o planeamento de E\/S. Se a cache mal conseguir ganhar velocidade, talvez um limite *_bytes demasiado baixo esteja a impedir uma divis\u00e3o em lotes eficaz. Uma an\u00e1lise mais aprofundada em <a href=\"https:\/\/webhosting.de\/pt\/servidor-despejo-de-cache-de-pagina-linux-memoria-impressao-otimizacao-insight\/\">Expuls\u00e3o da cache durante a impress\u00e3o<\/a> ajuda quando a falta de espa\u00e7o de armazenamento vem complicar ainda mais a situa\u00e7\u00e3o.<\/p>\n\n<h2>Boas pr\u00e1ticas e lista de verifica\u00e7\u00e3o sucinta<\/h2>\n\n<p>Fa\u00e7o uma distin\u00e7\u00e3o rigorosa entre os dados que t\u00eam de ser gravados imediatamente e os dados cuja persist\u00eancia pode ser adiada, a fim de <strong>Desempenho<\/strong> para ganhar. Para registos e di\u00e1rios de transa\u00e7\u00f5es, imponho sincroniza\u00e7\u00f5es; para artefactos tempor\u00e1rios, deixo o \u00abwriteback\u00bb funcionar livremente e fico apenas atento ao limite de restri\u00e7\u00e3o. Antes de cada ajuste, avalio o estado atual e comparo A\/B atrav\u00e9s de cen\u00e1rios definidos. Mantenho o n\u00famero de escritores simult\u00e2neos sob controlo, pois picos descoordenados reduzem a utilidade do processamento em lote. E documento as altera\u00e7\u00f5es imediatamente, para que futuras an\u00e1lises se baseiem em dados claros <strong>Dados<\/strong> baseado.<\/p>\n\n<h2>Resumo pr\u00e1tico para um sucesso r\u00e1pido<\/h2>\n\n<p>A cache de reescrita agrupa as altera\u00e7\u00f5es no <strong>P\u00e1gina<\/strong> A cache reduz os custos de E\/S e alivia a carga das aplica\u00e7\u00f5es. As p\u00e1ginas sujas n\u00e3o s\u00e3o um erro, mas sim um recurso espec\u00edfico para ganhar velocidade, desde que se conhe\u00e7am os limites e os requisitos de consist\u00eancia. Com os par\u00e2metros vm.dirty_background_ratio e vm.dirty_ratio, controlo quando o kernel trabalha discretamente em segundo plano e quando limita as opera\u00e7\u00f5es de grava\u00e7\u00e3o. As ferramentas e o diret\u00f3rio \/proc proporcionam-me a vis\u00e3o necess\u00e1ria sobre as p\u00e1ginas sujas e o writeback, para que eu n\u00e3o fique \u00e0s cegas. Se eu dominar estas alavancas, a Web, as bases de dados e os trabalhos em lote funcionam visivelmente mais r\u00e1pido, sem que o <strong>Integridade<\/strong> comprometer os meus dados.<\/p>","protected":false},"excerpt":{"rendered":"<p>Cache de reescrita no kernel do Linux: p\u00e1ginas sujas, cache de p\u00e1ginas e reescrita explicadas de forma compreens\u00edvel.<\/p>","protected":false},"author":1,"featured_media":20541,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20548","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":"137","_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":"Writeback 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":"20541","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20548","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=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}