{"id":21589,"date":"2026-09-20T11:47:21","date_gmt":"2026-09-20T09:47:21","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-adaptive-flushing-optimieren-performance\/"},"modified":"2026-09-20T11:47:21","modified_gmt":"2026-09-20T09:47:21","slug":"otimizar-o-adaptive-flushing-do-mariadb-para-melhorar-o-desempenho","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mariadb-adaptive-flushing-optimieren-performance\/","title":{"rendered":"Otimizar o Adaptive Flushing do MariaDB: guia pr\u00e1tico para um melhor desempenho"},"content":{"rendered":"<p>O \u00abAdaptive Flushing\u00bb no MariaDB controla a velocidade a que eu <strong>P\u00e1ginas sujas<\/strong> escreva do buffer pool para o suporte de dados, para que o redo log nunca se torne um gargalo. Quando otimizo o Adaptive Flushing do MariaDB, os picos de lat\u00eancia diminuem, o <strong>Ponto de controlo<\/strong>- O progresso mant\u00e9m-se est\u00e1vel e a carga de escrita continua a ser previs\u00edvel.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Valores medidos<\/strong> Em primeiro lugar: n\u00edvel de preenchimento do Redo Log, percentagem de p\u00e1ginas sujas, idade do ponto de verifica\u00e7\u00e3o<\/li>\n  <li><strong>Capacidade de E\/S<\/strong> determinar com precis\u00e3o, n\u00e3o estimar<\/li>\n  <li><strong>Valores de limiar<\/strong> Configurar de forma adequada: adaptive_flushing_lwm e Dirty-Page-LWM<\/li>\n  <li><strong>E\/S em segundo plano<\/strong> dosagem: io_capacity e io_capacity_max<\/li>\n  <li><strong>Registos de repeti\u00e7\u00e3o<\/strong> dimensionar adequadamente para garantir um fluxo uniforme<\/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\/09\/mariadb-optimierung-team-3052.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funciona o Adaptive Flushing no MariaDB<\/h2>\n\n<p>Ativo a l\u00f3gica din\u00e2mica atrav\u00e9s de <strong>innodb_adaptive_flushing<\/strong> e orienta o comportamento de alerta precoce com <strong>innodb_adaptive_flushing_lwm<\/strong>. Quanto mais cheio estiver o Redo Log e quanto mais rapidamente crescer, mais agressivamente o InnoDB efetua o flush, para evitar que surja um estrangulamento. Esta regra vincula a taxa de flush ao d\u00e9bito real de altera\u00e7\u00f5es, o que faz com que os picos curtos de E\/S ocorram com menos frequ\u00eancia. De acordo com a documenta\u00e7\u00e3o do MariaDB, a intensidade \u00e9 orientada pelo progresso do ponto de verifica\u00e7\u00e3o, para evitar tempos de espera nas opera\u00e7\u00f5es de grava\u00e7\u00e3o no disco. Tenho sempre em mente que o Adaptive Flushing distribui o trabalho, mas n\u00e3o compensa um desempenho de mem\u00f3ria insuficiente.<\/p>\n\n<h2>Compreender os indicadores-chave: Redo-Log, p\u00e1ginas sujas e pontos de verifica\u00e7\u00e3o<\/h2>\n\n<p>Primeiro, observo o n\u00edvel de enchimento, em percentagem, do <strong>Registos de revers\u00e3o<\/strong>, a taxa de p\u00e1ginas sujas no buffer pool e a idade do checkpoint. Estes tr\u00eas par\u00e2metros indicam-me se o servidor consegue efetuar o flushing atempadamente e de forma uniforme ou se o trabalho se acumula. Se a idade do ponto de verifica\u00e7\u00e3o aumentar demasiado depressa, o Adaptive Flushing entra em a\u00e7\u00e3o, mas, nesse caso, verifico tamb\u00e9m a lat\u00eancia do armazenamento. Para quest\u00f5es mais detalhadas sobre a estrat\u00e9gia de E\/S, ajuda-me dar uma vista de olhos nos <a href=\"https:\/\/webhosting.de\/pt\/mariadb-metodos-de-flush-innodb-fsync-guia-de-desempenho-buffer\/\">M\u00e9todos de limpeza<\/a>, porque determinam a efici\u00eancia com que o kernel processa os comandos de escrita. Associo estes sinais \u00e0 capacidade de E\/S medida, para poder efetuar altera\u00e7\u00f5es nos valores-limite de forma direcionada e garantir que o sistema como um todo se mant\u00e9m coerente.<\/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\/09\/mariadb_flushing_meeting_1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajustar corretamente os parafusos de regula\u00e7\u00e3o<\/h2>\n\n<p>Come\u00e7o por <strong>innodb_io_capacity<\/strong> e defina o valor pr\u00f3ximo da pot\u00eancia cont\u00ednua real do acumulador, e n\u00e3o dos m\u00e1ximos te\u00f3ricos. No que diz respeito aos picos, considero que <strong>innodb_io_capacity_max<\/strong> significativamente mais elevado, para que o InnoDB consiga acelerar momentaneamente em situa\u00e7\u00f5es de carga elevada, sem sobrecarregar a CPU. O valor limite <strong>innodb_adaptive_flushing_lwm<\/strong> Configurei de forma a que o servidor comece o preflushing bem antes de o Redo Log ficar cheio. Al\u00e9m disso, defino <strong>innodb_max_dirty_pages_pct_lwm<\/strong> de forma a que o InnoDB tome medidas corretivas atempadamente \u00e0 medida que a propor\u00e7\u00e3o de p\u00e1ginas sujas aumenta, evitando assim a ocorr\u00eancia de congestionamentos. Altero apenas um par\u00e2metro por ciclo, registo meticulosamente o efeito e dou ao sistema tempo para passar por v\u00e1rias fases de carga antes de prosseguir com a otimiza\u00e7\u00e3o.<\/p>\n\n<h2>Medir concretamente a capacidade de E\/S<\/h2>\n\n<p>Medei o desempenho cont\u00ednuo de grava\u00e7\u00e3o durante a carga de produ\u00e7\u00e3o, porque os testes sint\u00e9ticos de pico muitas vezes criam falsas expectativas e o <strong>Uniformidade<\/strong> ocultar. O que \u00e9 significativo s\u00e3o as m\u00e9dias e os percentis a m\u00e9dio e longo prazo, que resistem a suaviza\u00e7\u00f5es de curto prazo. Analiso os Write-IOPS, o Write-Throughput, as lat\u00eancias e a distribui\u00e7\u00e3o dos tempos de resposta, para n\u00e3o me limitar apenas ao valor m\u00e9dio. Quem se baseia apenas no valor m\u00e1ximo corre o risco de fases de flush agressivas, enquanto as transa\u00e7\u00f5es propriamente ditas ficam mais lentas. Tiro conclus\u00f5es para <strong>innodb_io_capacity<\/strong> com base no comportamento a longo prazo observado, e n\u00e3o em recordes de curta dura\u00e7\u00e3o.<\/p>\n\n<h2>Vis\u00e3o geral dos valores iniciais e dos valores-limite<\/h2>\n\n<p>Utilizo os valores iniciais como ponto de partida, nunca como dogma, e comparo-os com a carga de trabalho real, o tamanho do buffer pool e o crescimento do <strong>Registos de revers\u00e3o<\/strong>. Os sistemas SSD e NVMe apresentam valores claramente mais elevados do que os HDDs, mas defino as taxas apenas ao n\u00edvel necess\u00e1rio para que os acessos de leitura n\u00e3o fiquem na fila. Para sistemas com elevada carga, aumento gradualmente a capacidade e observo em conjunto a lat\u00eancia, a idade dos pontos de verifica\u00e7\u00e3o e o consumo da CPU. Se a taxa de p\u00e1ginas sujas diminuir de forma constante e os picos no n\u00edvel de preenchimento do registo de repeti\u00e7\u00e3o se reduzirem, considero que estou numa margem de seguran\u00e7a saud\u00e1vel. Para mim, continua a ser fundamental que eu <strong>Dicas<\/strong> controlar, em vez de as sobrepor com E\/S em segundo plano excessiva.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Vari\u00e1vel<\/th>\n      <th>Efeito<\/th>\n      <th>Valor inicial t\u00edpico do HDD<\/th>\n      <th>Valor inicial t\u00edpico do SSD<\/th>\n      <th>Valor inicial t\u00edpico do NVMe<\/th>\n      <th>Em que \u00e9 que presto aten\u00e7\u00e3o<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>innodb_adaptive_flushing<\/td>\n      <td>Ativa a limpeza din\u00e2mica<\/td>\n      <td>ON<\/td>\n      <td>ON<\/td>\n      <td>ON<\/td>\n      <td>Compensa\u00e7\u00e3o de picos<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_adaptive_flushing_lwm<\/td>\n      <td>Pr\u00e9-lavagem precoce<\/td>\n      <td>20\u201330%<\/td>\n      <td>20-40%<\/td>\n      <td>30\u201350%<\/td>\n      <td>N\u00edvel de preenchimento do registo de repeti\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_capacity<\/td>\n      <td>Taxa de lavagem de base<\/td>\n      <td>100-300<\/td>\n      <td>800\u20132000<\/td>\n      <td>2000\u20138000<\/td>\n      <td>IOPS de grava\u00e7\u00e3o cont\u00ednua<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_io_capacity_max<\/td>\n      <td>Limite de emerg\u00eancia<\/td>\n      <td>400\u2013800<\/td>\n      <td>2000-6000<\/td>\n      <td>6000\u201320000<\/td>\n      <td>Remover as pontas<\/td>\n    <\/tr>\n    <tr>\n      <td>innodb_max_dirty_pages_pct_lwm<\/td>\n      <td>P\u00e1gina suja - N\u00edvel baixo de \u00e1gua<\/td>\n      <td>5\u201310%<\/td>\n      <td>5\u201315%<\/td>\n      <td>5\u201315%<\/td>\n      <td>Medidas corretivas precoces<\/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\/2026\/09\/mariadb-adaptive-optimierung-2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Identificar casos problem\u00e1ticos e sintomas<\/h2>\n\n<p>Quando eu <strong>Descarga<\/strong>-Quando vejo picos, verifico primeiro o valor de I\/O: se estiver demasiado baixo, as p\u00e1ginas sujas acumulam-se e o sistema tem de as limpar rapidamente. Se o valor estiver demasiado alto, o I\/O em segundo plano sobreponha-se \u00e0 carga de trabalho ativa e obriga as leituras a entrarem em tempos de espera. Uma \u00abCheckpoint Age\u00bb lenta, que de repente dispara, indica-me que o servidor est\u00e1 a reagir com atraso. Ao mesmo tempo, um n\u00edvel de preenchimento do \u00abRedo Log\u00bb em r\u00e1pido crescimento sinaliza que o lado da grava\u00e7\u00e3o n\u00e3o est\u00e1 a acompanhar o ritmo ou que o log tem dimens\u00f5es insuficientes. Analiso estes padr\u00f5es em conjunto, porque um \u00fanico n\u00famero raramente explica por si s\u00f3 o comportamento do \u00abAdaptive Flushing\u00bb.<\/p>\n\n<h2>Dimensionar o Redo-Log para uma carga uniforme<\/h2>\n\n<p>Escolho o tamanho do <strong>Registos de revers\u00e3o<\/strong> de forma a garantir margem suficiente para picos de carga, sem que os pontos de verifica\u00e7\u00e3o fiquem demasiado longos. Um registo maior d\u00e1 \u00e0 fun\u00e7\u00e3o \u00abAdaptive Flushing\u00bb mais margem para distribuir o trabalho, mas tenho em aten\u00e7\u00e3o os tempos de recupera\u00e7\u00e3o e o or\u00e7amento de mem\u00f3ria. Se o registo estiver a crescer a cada segundo em dire\u00e7\u00e3o ao limite, um aumento moderado alivia a press\u00e3o e suaviza a curva de limpeza. Se o aumento n\u00e3o trouxer al\u00edvio, o problema reside, na maioria das vezes, numa capacidade de E\/S inadequada ou numa lat\u00eancia de armazenamento vari\u00e1vel. S\u00f3 decido se devo aumentar novamente o tamanho do registo ap\u00f3s per\u00edodos de observa\u00e7\u00e3o, e n\u00e3o com base em instant\u00e2neos.<\/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\/09\/mariadb_optimierung_3412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Page Cleaner: Threads e paralelismo<\/h2>\n\n<p>Estou a verificar o n\u00famero de threads do Page Cleaner, porque representam o processamento paralelo <strong>Descarga<\/strong>- Controlar o desempenho das inst\u00e2ncias do buffer pool. Em caso de cargas de escrita elevadas, um maior paralelismo proporciona mais rendimento, mas acompanho de perto a fila de armazenamento. Se o disco perder a sua efic\u00e1cia devido a filas sobrecarregadas, reduzo o n\u00famero de threads ou limito a capacidade de E\/S. Para compreender melhor este mecanismo, a vis\u00e3o geral ajuda-me a <a href=\"https:\/\/webhosting.de\/pt\/mariadb-limpeza-de-paginas-threads-base-de-dados\/\">Threads do Page Cleaner<\/a>, para que eu consiga manter o equil\u00edbrio entre press\u00e3o e justi\u00e7a. Tomo decis\u00f5es de forma pragm\u00e1tica: tantos t\u00f3picos quantos forem necess\u00e1rios, mas o m\u00ednimo poss\u00edvel, para que as leituras n\u00e3o fiquem para tr\u00e1s.<\/p>\n\n<h2>Buffer de grava\u00e7\u00e3o dupla: seguran\u00e7a vs. velocidade de grava\u00e7\u00e3o<\/h2>\n\n<p>Tenho em conta o <strong>Doublewrite<\/strong>-O buffer, uma vez que protege contra erros parciais de grava\u00e7\u00e3o, mas implica um custo adicional em termos de E\/S. Em sistemas NVMe fi\u00e1veis, esse custo adicional tem um impacto menor, enquanto que em armazenamento mais lento \u00e9 mais percet\u00edvel. Medei o impacto real nas lat\u00eancias e na taxa de esvaziamento de p\u00e1ginas antes de ajustar esta configura\u00e7\u00e3o. Para uma avalia\u00e7\u00e3o fundamentada, recorro a informa\u00e7\u00f5es mais aprofundadas sobre o <a href=\"https:\/\/webhosting.de\/pt\/innodb-buffer-de-gravacao-dupla-seguranca-otimizacao-de-desempenho-foco\/\">Buffer de grava\u00e7\u00e3o dupla<\/a> e analiso se existe outro perfil de risco e de desempenho que se adapte melhor. Nunca tomo decis\u00f5es de \u00e2nimo leve, porque a seguran\u00e7a dos dados e o d\u00e9bito est\u00e3o aqui em intera\u00e7\u00e3o direta.<\/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\/09\/mariadb_flushing_guide_4528.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitoriza\u00e7\u00e3o e m\u00e9tricas na pr\u00e1tica<\/h2>\n\n<p>Analiso a percentagem de p\u00e1ginas sujas, a rela\u00e7\u00e3o entre a taxa de flush e a taxa de altera\u00e7\u00e3o e a evolu\u00e7\u00e3o da <strong>Ponto de controlo<\/strong>-Age. Al\u00e9m disso, observo a percentagem de utiliza\u00e7\u00e3o do Redo Log ao longo do tempo, pois um aumento linear indica que se est\u00e3o a aproximar de valores-limite. Acompanho as lat\u00eancias de E\/S juntamente com as estat\u00edsticas do InnoDB, para poder atribuir com precis\u00e3o a causa e o efeito. Ap\u00f3s cada altera\u00e7\u00e3o de par\u00e2metro, comparo janelas de carga id\u00eanticas; caso contr\u00e1rio, tiro conclus\u00f5es erradas. Documento as curvas, porque uma imagem revela mais do que um \u00fanico ponto de medi\u00e7\u00e3o e, assim, consigo identificar com seguran\u00e7a quebras de tend\u00eancia.<\/p>\n\n<h2>Plano de afina\u00e7\u00e3o passo a passo<\/h2>\n\n<p>Come\u00e7o por fazer uma avalia\u00e7\u00e3o realista da <strong>Taxa de escrita<\/strong> e, a partir disso, defino o valor de `innodb_io_capacity`. Em seguida, defino `innodb_io_capacity_max` como uma solu\u00e7\u00e3o provis\u00f3ria para situa\u00e7\u00f5es de press\u00e3o, mantendo uma margem suficiente em rela\u00e7\u00e3o ao valor base. Em seguida, verifico o par\u00e2metro `innodb_adaptive_flushing_lwm` e reduzo o seu valor se a idade do ponto de verifica\u00e7\u00e3o (Checkpoint-Age) demorar a diminuir. Depois, defino o par\u00e2metro `innodb_max_dirty_pages_pct_lwm` de forma a que o pr\u00e9-flushing comece atempadamente e os picos sejam atenuados rapidamente. Por fim, ajusto o tamanho do redo log, observo novamente v\u00e1rios ciclos de carga e documento cada altera\u00e7\u00e3o antes de avan\u00e7ar para o pr\u00f3ximo passo.<\/p>\n\n<h2>Mecanismo Flush por baixo do cap\u00f4<\/h2>\n\n<p>Distingo duas motiva\u00e7\u00f5es principais para escrever: a <strong>Limpeza da lista de flushes<\/strong> (impulsionado pelo progresso no Checkpoint) e o <strong>Limpeza da LRU<\/strong> (devido \u00e0 falta de p\u00e1ginas livres na lista). Se o buffer pool ficar cheio e faltar p\u00e1ginas livres, o LRU-Flushing obriga-me a efetuar grava\u00e7\u00f5es imediatas, o que gera picos de lat\u00eancia. O Adaptive Flushing visa evitar estas situa\u00e7\u00f5es de emerg\u00eancia atrav\u00e9s da limpeza cont\u00ednua da lista de flush. Para que isso resulte, mantenho a propor\u00e7\u00e3o de p\u00e1ginas livres est\u00e1vel e monitorizo valores como a profundidade de varredura LRU e a carga por inst\u00e2ncia do buffer pool. Quanto mais uniformemente a lista de limpeza for processada, menos frequentemente terei de esperar por p\u00e1ginas livres em primeiro plano.<\/p>\n\n<p>Neste contexto, tenho em conta a rela\u00e7\u00e3o entre <strong>innodb_buffer_pool_instances<\/strong>, <strong>innodb_page_cleaners<\/strong> e da capacidade f\u00edsica de E\/S. Um maior n\u00famero de inst\u00e2ncias e threads de limpeza aumenta o paralelismo, mas apenas na medida em que as filas de armazenamento n\u00e3o fiquem sobrecarregadas. Se as opera\u00e7\u00f5es de flush atingirem comprimentos de fila elevados, isso \u00e9 um sinal de que eu deveria ter efetuado o flush mais cedo e de forma mais gradual \u2014 \u00e9 precisamente isso que resolvo atrav\u00e9s do `innodb_adaptive_flushing_lwm` e das capacidades m\u00ednima e m\u00e1xima.<\/p>\n\n<h2>Confirma\u00e7\u00e3o da transa\u00e7\u00e3o, redo e binlog no contexto<\/h2>\n\n<p>Analiso os percursos de commit e as garantias de durabilidade no contexto do alisamento de flush. <strong>innodb_flush_log_at_trx_commit<\/strong> e a sincroniza\u00e7\u00e3o do Binlog influenciam a frequ\u00eancia com que o sistema executa fsyncs e a intensidade dos picos de curta dura\u00e7\u00e3o. As minhas diretrizes:<\/p>\n\n<ul>\n  <li>1: M\u00e1xima durabilidade (execu\u00e7\u00e3o do Redo em cada commit no suporte de dados). Seguro, mas exige muitos fsync e pode ser mais inst\u00e1vel.<\/li>\n  <li>2: O Redo \u00e9 atualizado a cada segundo, enquanto o Commit apenas grava na cache do SO. Os picos s\u00e3o menores, mas, em contrapartida, corro o risco de perder dados em caso de falha do SO ou do host.<\/li>\n  <li>0: Semelhante ao 2, mas com um armazenamento em cache ainda mais agressivo. Para sistemas de produ\u00e7\u00e3o, utilizar apenas com precau\u00e7\u00e3o.<\/li>\n<\/ul>\n\n<p>Em conjunto com a sincroniza\u00e7\u00e3o Binlog (<strong>sincronizar_binlog<\/strong>) e os efeitos do Group Commit, consigo agrupar commits e reduzir o n\u00famero de sincroniza\u00e7\u00f5es r\u00edgidas. \u00c9 importante que eu n\u00e3o abuse destas ferramentas como substituto de um ajuste adequado do Adaptive Flushing. Avalio sempre em conjunto o risco, os requisitos de conformidade e o perfil de lat\u00eancia pretendido, e fa\u00e7o ajustes apenas na medida em que as regras de neg\u00f3cio o permitirem.<\/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\/09\/mariadb_optimierung_3412.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Purge-Threads, comprimento do hist\u00f3rico e processos de longa dura\u00e7\u00e3o<\/h2>\n\n<p>Eu tenho a <strong>InnoDB-Purge<\/strong> A ter em conta: muitas linhas eliminadas ou atualizadas geram dados de \u00abUndo\u00bb que s\u00e3o limpos de forma ass\u00edncrona. Se a <em>Dura\u00e7\u00e3o do hist\u00f3rico<\/em> Se for intenso, o consumo de recursos em segundo plano aumenta e entra em concorr\u00eancia com os \u00abpage cleaners\u00bb pela E\/S. Isso pode, indiretamente, abrandar o \u00abAdaptive Flushing\u00bb. As solu\u00e7\u00f5es consistem em definir um valor adequado para a paraleliza\u00e7\u00e3o da purga e evitar transa\u00e7\u00f5es de longa dura\u00e7\u00e3o que mantenham o hist\u00f3rico artificialmente aberto. Al\u00e9m disso, planeio as opera\u00e7\u00f5es em lote de forma a controlar o volume de Redo e Undo, em vez de alterar milh\u00f5es de linhas em lotes num curto espa\u00e7o de tempo.<\/p>\n\n<h2>Fases do Change Buffer e da fus\u00e3o<\/h2>\n\n<p>Tenho em conta o <strong>Alterar buffer<\/strong> durante atualiza\u00e7\u00f5es intensivas de \u00edndices secund\u00e1rios. Reduz as E\/S aleat\u00f3rias em tempo de execu\u00e7\u00e3o, mas transfere parte do trabalho para fases de fus\u00e3o posteriores. Estas fus\u00f5es podem gerar uma carga adicional de flush, caso coincidam de forma desfavor\u00e1vel com picos de produ\u00e7\u00e3o. Por isso, monitorizo o tamanho e a atividade do buffer de altera\u00e7\u00f5es, limito-o quando necess\u00e1rio e distribuo as altera\u00e7\u00f5es em massa de forma a que as fases de fus\u00e3o n\u00e3o coincidam com os hor\u00e1rios de pico. Desta forma, a taxa de esvaziamento torna-se mais previs\u00edvel e uniforme.<\/p>\n\n<h2>M\u00e9todos de flush e influ\u00eancias do sistema de ficheiros<\/h2>\n\n<p>Decido conscientemente sobre a <strong>M\u00e9todo Flush<\/strong> e as op\u00e7\u00f5es do sistema de ficheiros. O_DIRECT evita a duplica\u00e7\u00e3o de caches e, com isso, muitas vezes suaviza as lat\u00eancias de grava\u00e7\u00e3o, enquanto as vias AIO e Fsync t\u00eam as suas pr\u00f3prias caracter\u00edsticas. Mido o impacto destes m\u00e9todos na distribui\u00e7\u00e3o da lat\u00eancia e na estabilidade do progresso do ponto de verifica\u00e7\u00e3o e, para quest\u00f5es mais detalhadas, remeto para as notas sobre <a href=\"https:\/\/webhosting.de\/pt\/mariadb-metodos-de-flush-innodb-fsync-guia-de-desempenho-buffer\/\">M\u00e9todos de limpeza<\/a>. Al\u00e9m disso, verifico as op\u00e7\u00f5es de montagem do sistema de ficheiros e as rotinas de manuten\u00e7\u00e3o (por exemplo, estrat\u00e9gias consistentes de TRIM\/Discard em SSDs), para garantir que a infraestrutura n\u00e3o introduza jitter sem que isso seja detetado.<\/p>\n\n<h2>Diagn\u00f3stico: interpretar corretamente as mensagens de estado<\/h2>\n\n<p>Eu vou <em>MOSTRAR O ESTADO DO MOTOR INNODB<\/em> para avaliar a idade do ponto de verifica\u00e7\u00e3o e o progresso do flush. De <em>N\u00famero de sequ\u00eancia do registo<\/em>, <em>Registo esvaziado at\u00e9<\/em> e <em>\u00daltimo ponto de verifica\u00e7\u00e3o em<\/em> Determino qual \u00e9 a diferen\u00e7a entre as altera\u00e7\u00f5es geradas e as que foram persistidas. Se essa diferen\u00e7a aumentar continuamente a um ritmo superior ao permitido pelo tamanho do Redo Log, significa que o meu flush em segundo plano \u00e9 demasiado lento ou que a lat\u00eancia de E\/S \u00e9 demasiado elevada. Comparo estes valores com as m\u00e9tricas do InnoDB relativas \u00e0s p\u00e1ginas sujas, \u00e0 taxa de flush e \u00e0 atividade do Page Cleaner, para que possa ajustar os par\u00e2metros adequados de forma direcionada, em vez de tratar apenas os sintomas.<\/p>\n\n<h2>Cen\u00e1rios operacionais: Bulk, DDL e janelas de manuten\u00e7\u00e3o<\/h2>\n\n<p>Estou a planear <strong>Cargas a granel<\/strong> e abrangentes <strong>DDL<\/strong>-Opera\u00e7\u00f5es de forma a n\u00e3o sobrepor a fun\u00e7\u00e3o \u00abAdaptive Flushing\u00bb. Para janelas de manuten\u00e7\u00e3o program\u00e1veis, aumentei temporariamente <strong>innodb_io_capacity_max<\/strong>, para processar de forma controlada as grava\u00e7\u00f5es pendentes, e, em seguida, volto a reduzi-lo ao n\u00edvel normal. Em importa\u00e7\u00f5es de grande dimens\u00e3o, modero as frequ\u00eancias de commit, para que o crescimento do redo e o avan\u00e7o dos checkpoints acompanhem o ritmo. Entretanto, observo continuamente o n\u00edvel de preenchimento do registo de redo, a taxa de p\u00e1ginas sujas e os percentis de lat\u00eancia, para poder tomar medidas corretivas imediatas em caso de desvios.<\/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\/09\/mariadb-optimizierung-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Equ\u00edvocos comuns e anti-padr\u00f5es<\/h2>\n\n<p>N\u00e3o vou cair nessa armadilha, <strong>innodb_io_capacity_max<\/strong> utilizar como estado permanente. Um valor m\u00e1ximo demasiado elevado pode sobrecarregar as filas de mem\u00f3ria e abrandar os acessos de leitura em tempo real. Da mesma forma, n\u00e3o \u201eescondo\u201c mem\u00f3ria fraca atr\u00e1s de um registo de repeti\u00e7\u00e3o (redo log) gigantesco \u2013 os registos maiores suavizam o tr\u00e1fego, mas n\u00e3o criam reservas de E\/S. E n\u00e3o aceito os picos de lat\u00eancia como um dado adquirido: muitas vezes s\u00e3o o resultado de um preflushing tardio ou de uma carga em segundo plano altamente vari\u00e1vel, que posso atenuar atrav\u00e9s de limiares de LWM mais baixos e valores de capacidade realistas. Por fim, evito alterar v\u00e1rios par\u00e2metros ao mesmo tempo; caso contr\u00e1rio, perco a causalidade e n\u00e3o consigo tornar as melhorias reproduz\u00edveis.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Eu uso <strong>Adaptativo<\/strong> Flushing, para distribuir uniformemente as opera\u00e7\u00f5es de escrita ao longo do tempo e, assim, evitar picos de lat\u00eancia. O maior impacto \u00e9 obtido atrav\u00e9s de uma defini\u00e7\u00e3o precisa do par\u00e2metro innodb_io_capacity e de uma rela\u00e7\u00e3o adequada com o par\u00e2metro innodb_io_capacity_max. Limites de a\u00e7\u00e3o precoce para o n\u00edvel de preenchimento do redo log e a propor\u00e7\u00e3o de p\u00e1ginas sujas ajudam-me a manter as filas de espera pequenas. Com redo logs adequados, um paralelismo razo\u00e1vel dos threads do Page Cleaner e uma monitoriza\u00e7\u00e3o atenta, consigo criar rotinas de grava\u00e7\u00e3o mais fi\u00e1veis. De acordo com a documenta\u00e7\u00e3o do MariaDB sobre vari\u00e1veis de sistema e limpeza de p\u00e1ginas, estes par\u00e2metros atuam em conjunto \u2014 ajusto-os gradualmente e acompanho o efeito at\u00e9 que o sistema funcione de forma est\u00e1vel e previs\u00edvel.<\/p>","protected":false},"excerpt":{"rendered":"<p>Otimizar o Adaptive Flushing do MariaDB atrav\u00e9s do ajuste do InnoDB, da capacidade de E\/S e de dicas pr\u00e1ticas para um desempenho est\u00e1vel.<\/p>","protected":false},"author":1,"featured_media":21582,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21589","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"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":"82","_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":"Adaptive Flushing","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":"21582","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21589","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=21589"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21589\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21582"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21589"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21589"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21589"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}