{"id":20858,"date":"2026-08-21T11:49:48","date_gmt":"2026-08-21T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/"},"modified":"2026-08-21T11:49:48","modified_gmt":"2026-08-21T09:49:48","slug":"racio-de-dados-sujos-do-linux-racio-de-fundo-sujo-otimizacao-writeback","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"R\u00e1cio \u00abDirty\u00bb do Linux e r\u00e1cio \u00abDirty Background\u00bb: ajustes finos para um desempenho de grava\u00e7\u00e3o ideal"},"content":{"rendered":"<p>Eu mostro como <strong>linux sujo<\/strong> e a rela\u00e7\u00e3o de fundo sujo (dirty background ratio) controlam a cache da p\u00e1gina, influenciando assim o d\u00e9bito de escrita, a lat\u00eancia e a seguran\u00e7a dos dados. Desta forma, podes definir valores-limite concretos que ativam os flusher em tempo \u00fatil, evitam bloqueios e aumentam o desempenho de escrita das tuas cargas de trabalho.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Para come\u00e7ar, vou resumir brevemente as ideias principais, antes de aprofundar o assunto.<\/p>\n<ul>\n  <li><strong>P\u00e1ginas obscenas<\/strong> armazena os Writes na RAM e agrupa muitos pequenos acessos em opera\u00e7\u00f5es de E\/S mais eficientes.<\/li>\n  <li><strong>r\u00e1cio_de_fundo_sujo<\/strong> inicia threads do Flusher em segundo plano, limitando assim, de forma impercept\u00edvel, a quantidade de res\u00edduos.<\/li>\n  <li><strong>r\u00e1cio de sujidade<\/strong> limita os processos de grava\u00e7\u00e3o quando o limite m\u00e1ximo \u00e9 ultrapassado.<\/li>\n  <li><strong>Rela\u00e7\u00e3o<\/strong> Ambos os valores determinam os picos de lat\u00eancia, o d\u00e9bito e o tamanho do buffer.<\/li>\n  <li><strong>Variantes de bytes<\/strong> (dirty_bytes) proporcionam um controlo mais preciso e absoluto em servidores de grande dimens\u00e3o.<\/li>\n<\/ul>\n\n<h2>Compreender as \u00abDirty Pages\u00bb<\/h2>\n\n<p>Quando um processo grava dados, estes v\u00e3o primeiro para o <strong>Cache de p\u00e1gina<\/strong> e s\u00e3o marcados como \u201edirty\u201c at\u00e9 que o kernel consiga grav\u00e1-los no disco. Este armazenamento em buffer acelera as aplica\u00e7\u00f5es, porque a RAM reage mais rapidamente do que qualquer SSD ou HDD e as pequenas grava\u00e7\u00f5es acabam por se agrupar em grandes transfer\u00eancias sequenciais. Tenho sempre em mente a quantidade de \u201esujidade\u201c que permito, pois um buffer excessivo pode prolongar as filas de espera ou, em caso de falhas, colocar em risco mais dados n\u00e3o guardados. Quem compreende o funcionamento toma melhores decis\u00f5es em rela\u00e7\u00e3o ao writeback, \u00e0 lat\u00eancia e \u00e0 press\u00e3o de mem\u00f3ria. Um breve artigo de contextualiza\u00e7\u00e3o sobre o <a href=\"https:\/\/webhosting.de\/pt\/cache-de-reescrita-cache-do-kernel-do-linux\/\">Cache de reescrever<\/a> ajuda a compreender bem este mecanismo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-schreibfeintuning-7492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguran\u00e7a de dados, fsync e janela de falha<\/h2>\n<p>Os valores-limite n\u00e3o influenciam apenas o desempenho, mas tamb\u00e9m a tua janela de risco. Fa\u00e7o uma estimativa com uma regra pr\u00e1tica simples: a quantidade m\u00e1xima de dados n\u00e3o seguros dividida pela taxa de transfer\u00eancia sustent\u00e1vel do dispositivo resulta, de forma aproximada, no tempo que demora at\u00e9 o buffer ficar vazio. Exemplo: se eu permitir 4 GB de dados \u00absujos\u00bb e o suporte de destino atingir 500 MB\/s, a grava\u00e7\u00e3o completa demora cerca de 8 segundos. Durante esse tempo, em caso de falha de energia ou de \u00abkernel panic\u00bb, as grava\u00e7\u00f5es mais recentes podem vir a faltar.<\/p>\n<p>As aplica\u00e7\u00f5es podem fechar a janela atrav\u00e9s de <code>fsync()<\/code> ou <code>fdatasync()<\/code> reduzir, pois esses acessos obrigam o sistema de ficheiros a gravar dados (e, dependendo do modo de registo, tamb\u00e9m metadados) no suporte. Isto \u00e9 mais dispendioso, mas essencial para bases de dados ou registos. Tenho o cuidado de garantir que os meus limites de \u00abdirty\u00bb estejam de acordo com o comportamento de sincroniza\u00e7\u00e3o: frequentes <code>fsync()<\/code>-As visualiza\u00e7\u00f5es beneficiam de uma taxa mais baixa <em>r\u00e1cio de sujidade<\/em>, para que o kernel n\u00e3o reduza ainda mais o desempenho, uma vez que a persist\u00eancia j\u00e1 \u00e9 efetuada regularmente. Por outro lado, no caso de registos com grande volume de adi\u00e7\u00f5es (append) que raramente s\u00e3o esvaziados, posso permitir buffers maiores \u2013 sempre tendo em conta o risco de perda aceit\u00e1vel.<\/p>\n<p>As barreiras e as sequ\u00eancias de grava\u00e7\u00e3o tamb\u00e9m s\u00e3o importantes: os sistemas de ficheiros modernos utilizam comandos FUA\/Flush para esvaziar corretamente as caches dos controladores. Em suportes sem prote\u00e7\u00e3o contra perda de energia (PLP), os buffers de grande dimens\u00e3o aumentam o risco; com PLP ou prote\u00e7\u00e3o do cache de grava\u00e7\u00e3o, buffers maiores s\u00e3o frequentemente aceit\u00e1veis.<\/p>\n\n<h2>R\u00e1cio de fundo sujo: o valor-limiar suave<\/h2>\n\n<p>Com <strong>r\u00e1cio_de_fundo_sujo<\/strong> Indico a partir de que percentagem da mem\u00f3ria dispon\u00edvel os threads do flusher come\u00e7am a escrever em segundo plano. Este valor n\u00e3o bloqueia as aplica\u00e7\u00f5es, mas inicia silenciosamente as tarefas de limpeza para que o buffer n\u00e3o fique sobrecarregado. Valores baixos geram grava\u00e7\u00f5es em segundo plano mais frequentes, mas mais uniformes, e suavizam os picos de lat\u00eancia. Valores mais elevados permitem um buffer maior, o que aumenta o d\u00e9bito em grandes grava\u00e7\u00f5es sequenciais, mas pode provocar picos de E\/S consider\u00e1veis em caso de limpeza repentina. Normalmente, os valores predefinidos situam-se em cerca de dez por cento, mas eu ajusto esse limite consoante o suporte, a carga de trabalho e os requisitos de seguran\u00e7a.<\/p>\n\n<h2>Dirty Ratio: a travagem brusca<\/h2>\n\n<p>O par\u00e2metro <strong>r\u00e1cio de sujidade<\/strong> indica o limite a partir do qual o kernel limita os processos de escrita at\u00e9 que sejam regravadas p\u00e1ginas suficientes. Este limite r\u00edgido protege a mem\u00f3ria contra uma inunda\u00e7\u00e3o de dados n\u00e3o persistentes e, assim, tem um impacto direto nas aplica\u00e7\u00f5es assim que estas pretendem continuar a produzir dados. No caso das bases de dados, defino um valor mais baixo, para que as consultas mantenham tempos de resposta constantes e n\u00e3o surjam longas fases de flush. Por outro lado, para tarefas de c\u00f3pia de seguran\u00e7a, utilizo buffers mais generosos, para transferir blocos de grande dimens\u00e3o de forma eficiente. Os valores predefinidos habituais variam entre vinte e quarenta por cento, mas adapto sempre este intervalo \u00e0 carga espec\u00edfica.<\/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_perf_neu_opt_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Intera\u00e7\u00e3o e rela\u00e7\u00f5es t\u00edpicas<\/h2>\n\n<p>Ambos os valores-limite funcionam como <strong>Tandem<\/strong> e s\u00f3 surtem efeito quando atuam em conjunto. Mantengo sempre o valor de `dirty_background_ratio` inferior ao de `dirty_ratio`, para que o kernel inicie a tempo em segundo plano e a limita\u00e7\u00e3o severa raramente seja aplicada. Como regra geral, costumo escolher um valor entre um quarto e metade do limite m\u00e1ximo, ou seja, por exemplo, 5\u201310 para 20. Desta forma, o Writeback \u00e9 iniciado com anteced\u00eancia suficiente, sem reduzir desnecessariamente a taxa de transfer\u00eancia. Quem n\u00e3o respeitar esta rela\u00e7\u00e3o ir\u00e1 enfrentar ou uma limita\u00e7\u00e3o prematura, ou um trabalho em segundo plano demasiado tardio, com picos de lat\u00eancia percet\u00edveis.<\/p>\n\n<h2>Controlo por dispositivo e granularidade da camada de blocos<\/h2>\n<p>Para al\u00e9m dos limites globais, vale a pena dar uma olhadela ao n\u00edvel do dispositivo. O Linux distribui a carga suja atrav\u00e9s dos chamados <em>Dispositivos compat\u00edveis<\/em> (bdi). Em <code>\/sys\/class\/block\/\/bdi\/<\/code> Considero que par\u00e2metros como <code>max_ratio<\/code>, que determinam a quantidade do \u00abDirty-Budget\u00bb global permitido que um \u00fanico dispositivo pode utilizar. Em sistemas com unidades de disco lentas e r\u00e1pidas a funcionar em paralelo, limito as unidades lentas para que n\u00e3o se tornem um gargalo.<\/p>\n<p>Tamb\u00e9m \u00e9 relevante a limita\u00e7\u00e3o da camada de blocos atrav\u00e9s de <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). Com isto, defino uma lat\u00eancia-alvo; o kernel limita ent\u00e3o a carga de escrita quando esta ultrapassa esse tempo-alvo. No caso de discos r\u00edgidos SATA, costumo definir valores conservadores para proteger a interatividade. Em unidades NVMe muito r\u00e1pidas, desativo ou aumentei a lat\u00eancia-alvo, para que o controlador possa tirar partido da sua capacidade de paralelismo. Escolho o agendador de E\/S (mq-deadline, BFQ, none) de acordo com as necessidades: o BFQ ajuda em sistemas interativos com carga mista, enquanto <em>nenhum<\/em> ou o mq-deadline costuma funcionar melhor em tarefas puramente de d\u00e9bito em NVMe.<\/p>\n<p>A intera\u00e7\u00e3o \u00e9 decisiva: se <em>r\u00e1cio_de_fundo_sujo<\/em> baixa, mas como o dispositivo est\u00e1 sujeito a limites rigorosos por parte do WBT, ocorrem, mesmo assim, congestionamentos vis\u00edveis. Por isso, calibro ambos os n\u00edveis em conjunto \u2013 limites globais de \u00abdirty\u00bb para o tamanho do buffer e a camada de blocos para prote\u00e7\u00e3o contra a lat\u00eancia.<\/p>\n\n<h2>R\u00e1cio vs. bytes: valores predefinidos e variantes<\/h2>\n\n<p>Em sistemas com muita <strong>RAM<\/strong> Os valores percentuais aumentam rapidamente, atingindo grandes ordens de grandeza absolutas. Nesse caso, prefiro definir limites m\u00e1ximos absolutos com `dirty_bytes` e `dirty_background_bytes`, para limitar claramente a quantidade de mem\u00f3ria tamp\u00e3o a cerca de 2\u20138 GB. Isto dissocia a regula\u00e7\u00e3o dos n\u00edveis de mem\u00f3ria com fortes oscila\u00e7\u00f5es e mant\u00e9m a quantidade de dados n\u00e3o persistentes calcul\u00e1vel. A escolha continua a ser din\u00e2mica: para servidores pequenos com pouca RAM, as percentagens s\u00e3o frequentemente suficientes. Quem disp\u00f5e de elevada capacidade, consegue muitas vezes planear melhor com valores em bytes.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Par\u00e2metros<\/th>\n      <th>Significado<\/th>\n      <th>Predefini\u00e7\u00f5es t\u00edpicas<\/th>\n      <th>Quando \u00e9 que se deve mudar?<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>In\u00edcio do <strong>Flush de fundo<\/strong> em percentagem<\/td>\n      <td>\u2248 10%<\/td>\n      <td>Em caso de flutua\u00e7\u00f5es de lat\u00eancia ou SSD\/NVMe muito r\u00e1pidos<\/td>\n      <td>Mais baixo = lat\u00eancia mais suave, mais alto = mais buffer<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Dif\u00edcil <strong>Limite de estrangulamento<\/strong> em percentagem<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>Mais baixo no caso das bases de dados, mais elevado no caso das c\u00f3pias de seguran\u00e7a<\/td>\n      <td>Demasiado elevado \u2192 Possibilidade de bloqueios durante o flush<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>In\u00edcio da limpeza em segundo plano em <strong>Bytes<\/strong><\/td>\n      <td>Desativado quando se utiliza o Ratio<\/td>\n      <td>Grande quantidade de RAM, alvos de buffer fixos<\/td>\n      <td>Anula os par\u00e2metros do Ratio<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Limite r\u00edgido de modera\u00e7\u00e3o em <strong>Bytes<\/strong><\/td>\n      <td>Desativado quando se utiliza o Ratio<\/td>\n      <td>Grande capacidade de RAM, limite m\u00e1ximo program\u00e1vel<\/td>\n      <td>Anula os par\u00e2metros do Ratio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Cen\u00e1rios de carga de trabalho e recomenda\u00e7\u00f5es<\/h2>\n\n<p>Cargas de escrita sequenciais, tais como <strong>C\u00f3pias de seguran\u00e7a<\/strong> beneficiam de grandes buffers e de uma escrita em segundo plano moderada, porque o kernel consegue escrever no suporte em grandes blocos. Aqui, costumo definir o dirty_ratio entre 30 e 40 por cento e o dirty_background_ratio entre 10 e 20 por cento. As bases de dados e as pequenas aplica\u00e7\u00f5es de E\/S aleat\u00f3ria dependem de uma lat\u00eancia previs\u00edvel; por isso, opto por 10\u201315 por cento de \u00abhard\u00bb e 3\u20135 por cento de \u00absoft\u00bb. Para servidores mistos de Web e de aplica\u00e7\u00f5es, 15\u201320 por cento de \u00abhard\u00bb e 5\u201310 por cento de \u00absoft\u00bb revelam-se um bom compromisso. Estes intervalos servem como ponto de partida; depois, o que conta \u00e9 a realidade medida do seu sistema.<\/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-schreibperformance-feintuning-5648.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspectos do sistema de ficheiros e op\u00e7\u00f5es de montagem<\/h2>\n<p>O percurso de reescrita termina no sistema de ficheiros \u2013 cuja estrat\u00e9gia determina as lat\u00eancias e a seguran\u00e7a. O Ext4 com <em>dados=ordenados<\/em> (Padr\u00e3o) grava os dados de utilizador antes das confirma\u00e7\u00f5es do journal; <em>data=writeback<\/em> reduz a lat\u00eancia, mas coloca em risco os dados antigos em caso de falhas. O par\u00e2metro <code>comprometer=<\/code> (segundos) determina a frequ\u00eancia com que o registo \u00e9 guardado. Intervalos mais curtos reduzem a perda de dados, mas implicam mais opera\u00e7\u00f5es de E\/S. O XFS utiliza um design de registo bem desenvolvido; grandes <em>tamanho do registo<\/em> e um alinhamento adequado ajudam nas tarefas de alto rendimento. O Btrfs agrupa as grava\u00e7\u00f5es atrav\u00e9s do \u00abcopy-on-write\u00bb \u2014 o que estabiliza as lat\u00eancias, mas pode levar \u00e0 fragmenta\u00e7\u00e3o no caso de pequenas grava\u00e7\u00f5es aleat\u00f3rias e SSDs com pouca capacidade. Op\u00e7\u00f5es como <em>nodatacow<\/em> ajudam na desfragmenta\u00e7\u00e3o de determinados caminhos ou na desfragmenta\u00e7\u00e3o direcionada, quando ocorrem picos de lat\u00eancia.<\/p>\n<p>Al\u00e9m disso, tenho em conta que <em>relatime<\/em>\/<em>n\u00e3o h\u00e1 tempo<\/em> (reduz as grava\u00e7\u00f5es de metadados), <em>hora da pregui\u00e7a<\/em> (atime\/mtime mais persistentes) e barreiras de registo. Especialmente em controladores RAID ou em m\u00e1quinas virtuais, a sem\u00e2ntica correta da cache \u00e9 decisiva: caches de grava\u00e7\u00e3o mal configuradas anulam todo o trabalho de \u00abdirty tuning\u00bb.<\/p>\n\n<h2>E\/S direta, O_SYNC e comportamento da aplica\u00e7\u00e3o<\/h2>\n<p>Nem todas as aplica\u00e7\u00f5es passam pelo cache de p\u00e1ginas. Com <code>O_DIRECTO<\/code> ou <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Os processos contornam partes da cache ou exigem persist\u00eancia imediata. As bases de dados escrevem normalmente um WAL\/registo de refazer de forma s\u00edncrona e as \u00e1reas de dados de forma ass\u00edncrona. Calibro os limites de \u00abdirty\u00bb especialmente para os caminhos ass\u00edncronos, enquanto garanto a lat\u00eancia dos caminhos s\u00edncronos atrav\u00e9s de registos r\u00e1pidos (NVMe, LUN dedicado). Quando as aplica\u00e7\u00f5es executam com muita frequ\u00eancia <code>fsync()<\/code> Quando se trata de chamadas de fun\u00e7\u00e3o, os buffers grandes s\u00e3o pouco \u00fateis \u2013 a lat\u00eancia depende, nesse caso, mais do controlador, da profundidade da fila e do agendador de E\/S do que de <em>r\u00e1cio de sujidade<\/em>.<\/p>\n\n<h2>Afina\u00e7\u00e3o pr\u00e1tica, passo a passo<\/h2>\n\n<p>Antes de cada altera\u00e7\u00e3o, verifico a <strong>valores reais<\/strong> com <code>sysctl vm.dirty_ratio<\/code> e <code>sysctl vm.dirty_background_ratio<\/code>, para registar a situa\u00e7\u00e3o inicial. Para testes de curta dura\u00e7\u00e3o, anoto os valores diretamente em <code>\/proc\/sys\/vm\/<\/code>por exemplo <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> e <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Se a altera\u00e7\u00e3o for permanente, vou guard\u00e1-la em <code>\/etc\/sysctl.conf<\/code> ou <code>\/etc\/sysctl.d\/*.conf<\/code>. As altera\u00e7\u00f5es s\u00e3o implementadas com <code>sysctl -p<\/code> imediatamente, para que eu possa avaliar o efeito em tempo \u00fatil. Quem se aprofundar no tema das regras do sistema beneficiar\u00e1 de dicas pr\u00e1ticas sobre o <a href=\"https:\/\/webhosting.de\/pt\/ajuste-do-sysctl-para-otimizar-o-desempenho-do-servidor-de-alojamento-web\/\">Ajuste de par\u00e2metros sysctl<\/a> em servidores produtivos.<\/p>\n\n<h2>Calcular valores: exemplos de c\u00e1lculos<\/h2>\n<p>Gosto de come\u00e7ar com valores concretos. Exemplo 1: servidor web\/de aplica\u00e7\u00f5es com 64 GB de RAM e NVMe. O objetivo \u00e9 uma lat\u00eancia baixa. Eu defino <code>dirty_background_bytes=1073741824<\/code> (1 GB) e <code>dirty_bytes=3221225472<\/code> (3 GB). Com uma taxa de transfer\u00eancia NVMe sustentada de 2 GB\/s, isso significa cerca de 0,5\u20131,5 segundos para esvaziar \u2013 adequado para cargas interativas. Exemplo 2: N\u00f3 de c\u00f3pia de seguran\u00e7a com 128 GB de RAM, RAID SATA r\u00e1pido com 800 MB\/s. Escolho <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. Em termos absolutos, s\u00e3o cerca de 12,8 GB e 44,8 GB; o RAID demora entre 16 e 56 segundos a esvaziar-se. Isso \u00e9 aceit\u00e1vel, porque a tarefa n\u00e3o \u00e9 interativa.<\/p>\n<p>Exemplo 3: Servidor de base de dados com 256 GB de RAM, di\u00e1rio separado em NVMe, dados num conjunto de SSD. Estabele\u00e7o limites absolutos para evitar valores at\u00edpicos: <code>dirty_background_bytes=2147483648<\/code> (2 GB), <code>dirty_bytes=8589934592<\/code> (8 GB). Isto permite manter o tamanho da janela de falhas dentro do previsto e reduz as travagens bruscas durante os pontos de verifica\u00e7\u00e3o.<\/p>\n\n<h2>Tempo de reescrita e par\u00e2metros relacionados<\/h2>\n\n<p>Para al\u00e9m dos valores-limite, influenciam <strong>Temporizador<\/strong> o comportamento de grava\u00e7\u00e3o e, consequentemente, a sensa\u00e7\u00e3o proporcionada pelas aplica\u00e7\u00f5es. Com <code>vm.dirty_writeback_centisegundos<\/code> controlo o intervalo em que o Kernel Flusher \u00e9 ativado, enquanto <code>vm.dirty_expire_centisecs<\/code> define a idade m\u00e1xima que as p\u00e1ginas sujas podem atingir. Intervalos mais curtos garantem flushes mais frequentes, mas de menor dimens\u00e3o; intervalos mais longos poupam chamadas de E\/S, mas arriscam a forma\u00e7\u00e3o de lotes maiores. S\u00f3 ajusto estes valores se as medi\u00e7\u00f5es revelarem desvantagens reais, como, por exemplo, flushes demasiado raros em unidades NVMe r\u00e1pidas. Quem adotar uma abordagem met\u00f3dica evita oscila\u00e7\u00f5es entre uma atividade de writeback demasiado intensa e outra demasiado lenta.<\/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_performance_finetune_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e ajuste fino<\/h2>\n\n<p>Ap\u00f3s os ajustes, observo que <strong>cont\u00ednuo<\/strong> os indicadores para tornar vis\u00edveis os sucessos e os efeitos secund\u00e1rios. Em <code>\/proc\/meminfo<\/code> Verifico o \u201eDirty\u201c e o \u201eWriteback\u201c para ver os n\u00edveis dos buffers e os flushes ativos. Ferramentas como o iostat, o sar ou o atop mostram-me a taxa de transfer\u00eancia, as filas e as tend\u00eancias de lat\u00eancia. Este artigo sobre o tema oferece uma boa introdu\u00e7\u00e3o \u00e0s m\u00e9tricas <a href=\"https:\/\/webhosting.de\/pt\/server-io-wait-analyse-iostat-vmstat-metrics-disk\/\">Analisar a espera de E\/S<\/a>. S\u00f3 com base nestes dados \u00e9 que vou reduzir ou aumentar os limites em pequenos passos, para que n\u00e3o surjam efeitos secund\u00e1rios inesperados.<\/p>\n\n<h2>Containers, cgroups e distribui\u00e7\u00e3o equitativa<\/h2>\n<p>Em ambientes de contentores, as cargas de trabalho partilham os mesmos mecanismos do kernel. O Cgroup-Writeback garante que as p\u00e1ginas sujas sejam atribu\u00eddas ao seu autor. Utilizo os controladores de E\/S dos cgroups (blkcg) para limitar a largura de banda ou os IOPS por contentor, caso determinados inquilinos utilizem a mem\u00f3ria tamp\u00e3o de forma demasiado agressiva. Limites absolutos de bytes ao n\u00edvel do anfitri\u00e3o (<em>bytes_sujos<\/em>) evitar que um \u00fanico h\u00f3spede esgote todo o or\u00e7amento para despesas extraordin\u00e1rias. Al\u00e9m disso, limito o espa\u00e7o de armazenamento atrav\u00e9s de <code>mem\u00f3ria.max<\/code>, para que o Writeback n\u00e3o reaja apenas quando houver press\u00e3o global. O objetivo continua a ser: nenhuma carga do convidado deve provocar limita\u00e7\u00f5es em todo o anfitri\u00e3o do <em>r\u00e1cio de sujidade<\/em> impor.<\/p>\n\n<h2>Ambientes de alojamento e m\u00e1quinas virtuais<\/h2>\n\n<p>Em configura\u00e7\u00f5es multi-cliente e m\u00e1quinas virtuais, presto aten\u00e7\u00e3o ao seguinte: <strong>Sobre-reserva<\/strong> de RAM e E\/S, porque os limites percentuais t\u00eam um impacto diferente nessas \u00e1reas. Os limites absolutos em bytes podem impedir que determinados convidados acumulem demasiado buffer e atrasem os vizinhos. Tenho em conta a deduplica\u00e7\u00e3o de mem\u00f3ria, o ballooning e as caches dos controladores, porque estes fatores se sobrep\u00f5em aos efeitos do buffer. No caso dos servidores geridos, \u00e9 vantajoso que o fornecedor defina valores predefinidos adequados, para que os clientes tenham tempos de resposta constantes. Quem opera os seus pr\u00f3prios n\u00f3s beneficia de configura\u00e7\u00f5es de perfil bem definidas para cada classe de carga 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\/2026\/08\/DirtyRatioTuning1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Equ\u00edvocos e obst\u00e1culos frequentes<\/h2>\n<ul>\n  <li><strong>\u201eMais margem de seguran\u00e7a = cada vez mais rendimento.\u201c<\/strong> Isto n\u00e3o se aplica a cargas de trabalho com grande predomin\u00e2ncia de opera\u00e7\u00f5es aleat\u00f3rias ou a dispositivos com profundidade de fila reduzida. Buffers demasiado grandes geram picos de esvaziamento e filas.<\/li>\n  <li><strong>\u201eO dirty_ratio n\u00e3o afeta as leituras.\u201c<\/strong> Indiretamente, sim: as fases agressivas de reescrita substituem as p\u00e1ginas da cache e aumentam as lat\u00eancias de leitura.<\/li>\n  <li><strong>\u201eOs bytes e a raz\u00e3o somam-se.\u201c<\/strong> N\u00e3o. Se definires variantes \u00abBytes\u00bb, estas anular\u00e3o as variantes \u00abRatio\u00bb correspondentes. Mant\u00e9m-te claro.<\/li>\n  <li><strong>\u201eA fun\u00e7\u00e3o fsync() torna os limites de dados alterados irrelevantes.\u201c<\/strong> N\u00e3o. Embora as sincroniza\u00e7\u00f5es frequentes reduzam a janela de risco, o restante da carga continua sujeito aos valores-limite.<\/li>\n  <li><strong>\u201eUm suporte de dados r\u00e1pido resolve tudo.\u201c<\/strong> N\u00e3o, se o Block-Layer estiver a limitar a velocidade (WBT) ou se o sistema de ficheiros estiver montado de forma sub\u00f3tima.<\/li>\n  <li><strong>\u201eO Drop_caches \u00e9 uma ferramenta de otimiza\u00e7\u00e3o.\u201c<\/strong> Esvaziar a cache distorce as medi\u00e7\u00f5es e agrava os picos de lat\u00eancia. Em ambiente de produ\u00e7\u00e3o, evito faz\u00ea-lo.<\/li>\n<\/ul>\n\n<h2>Resolu\u00e7\u00e3o de problemas: sintomas t\u00edpicos e solu\u00e7\u00f5es<\/h2>\n\n<p>Amontoar <strong>Picos de lat\u00eancia<\/strong>, come\u00e7o por reduzir o valor limite de fundo, para que os flushes comecem mais cedo e as grandes ondas de grava\u00e7\u00e3o ocorram com menos frequ\u00eancia. Se as aplica\u00e7\u00f5es ficarem bloqueadas em determinados momentos, isso significa que, na maioria das vezes, o limite m\u00e1ximo est\u00e1 demasiado alto ou que o suporte n\u00e3o consegue lidar com os picos de flush que surgem. Nesses casos, reduzo o `dirty_ratio`, verifico as defini\u00e7\u00f5es de `readahead` e analiso as op\u00e7\u00f5es de journaling do sistema de ficheiros. No caso de hardware NVMe muito r\u00e1pido, aumento gradualmente o limiar de fundo para n\u00e3o limitar artificialmente a taxa de transfer\u00eancia. Ap\u00f3s cada altera\u00e7\u00e3o, baseio-me nos dados de medi\u00e7\u00e3o e n\u00e3o na intui\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-schreibperformance-5712.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumo pr\u00e1tico<\/h2>\n\n<p>Com poucos <strong>Parafusos de regula\u00e7\u00e3o<\/strong> Posso influenciar a forma como o Linux armazena dados de escrita em buffer, quando os flushers s\u00e3o iniciados e quando o kernel abranda. O \u00abDirty Background Ratio\u00bb garante uma limpeza silenciosa, enquanto o \u00abDirty Ratio\u00bb limita o consumo de RAM de forma mais rigorosa. A rela\u00e7\u00e3o entre estes dois valores determina se o teu sistema se orienta mais para lat\u00eancias uniformes ou para o m\u00e1ximo rendimento. Registo os valores predefinidos, fa\u00e7o altera\u00e7\u00f5es em pequenos passos e analiso as medi\u00e7\u00f5es de forma consistente. Assim, cria-se uma configura\u00e7\u00e3o que equilibra de forma razo\u00e1vel a carga de trabalho, o suporte e o risco e que, na pr\u00e1tica, funciona de forma visivelmente mais r\u00e1pida.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubra como pode otimizar de forma espec\u00edfica o desempenho de grava\u00e7\u00e3o e o desempenho do kernel do seu servidor atrav\u00e9s dos par\u00e2metros \u00abdirty ratio\u00bb e \u00abdirty background ratio\u00bb do Linux, e como gerir de forma eficiente as p\u00e1ginas sujas.<\/p>","protected":false},"author":1,"featured_media":20851,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20858","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":"142","_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":"linux dirty","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":"20851","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20858","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=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}