{"id":21467,"date":"2026-09-16T18:21:26","date_gmt":"2026-09-16T16:21:26","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-page-cleaner-threads-datenbank\/"},"modified":"2026-09-16T18:21:26","modified_gmt":"2026-09-16T16:21:26","slug":"mariadb-limpeza-de-paginas-threads-base-de-dados","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mariadb-page-cleaner-threads-datenbank\/","title":{"rendered":"Compreender os threads do MariaDB Page Cleaner: como influenciam o desempenho"},"content":{"rendered":"<p><strong>Limpa-p\u00e1ginas<\/strong> Os threads no MariaDB controlam a forma como o InnoDB grava as p\u00e1ginas alteradas do buffer pool no disco, suavizando assim os tempos de resposta sob carga de escrita. Quem compreender a arquitetura atual, com um \u00fanico thread de limpeza, evita gargalos no caminho de escrita e mant\u00e9m a <strong>base de dados<\/strong> desempenho constante.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Arquitetura<\/strong>: Um thread de limpeza esvazia as p\u00e1ginas sujas independentemente das inst\u00e2ncias do buffer pool.<\/li>\n  <li><strong>Vers\u00f5es<\/strong>: A vari\u00e1vel <code>innodb_page_cleaners<\/code> Foi eliminado a partir do MariaDB 10.6.<\/li>\n  <li><strong>Foco na LRU<\/strong>: A sele\u00e7\u00e3o de limpeza baseia-se no fim da LRU e no progresso do ponto de verifica\u00e7\u00e3o.<\/li>\n  <li><strong>Mito<\/strong>: Um maior n\u00famero de threads n\u00e3o significa, automaticamente, um melhor desempenho.<\/li>\n  <li><strong>Pr\u00e1tica<\/strong>: O tamanho do buffer pool, a capacidade de E\/S e a cria\u00e7\u00e3o de pontos de verifica\u00e7\u00e3o s\u00e3o os fatores que mais influenciam o resultado.<\/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\/server-performance-5647.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que o Page Cleaner faz exatamente<\/h2>\n\n<p>O t\u00f3pico \u00abPage Cleaner\u00bb diz <strong>Sujo<\/strong> Recupera p\u00e1ginas do buffer pool do InnoDB antes que as opera\u00e7\u00f5es do utilizador cheguem diretamente ao disco. Desta forma, dissocia as opera\u00e7\u00f5es de escrita das consultas e reduz significativamente a varia\u00e7\u00e3o nos tempos de resposta, sobretudo durante os picos de carga. Vejo o Cleaner como um regulador de ritmo: divide as grava\u00e7\u00f5es em por\u00e7\u00f5es adequadas, em vez de processar grandes volumes de forma descontrolada. O thread recorre \u00e0s p\u00e1ginas que acabam por ficar no fim da lista LRU, para que a cache fique rapidamente livre para dados de alta demanda. Ao mesmo tempo, acelera o processo de checkpoint, para que n\u00e3o fiquem demasiadas altera\u00e7\u00f5es n\u00e3o gravadas na mem\u00f3ria. Quem compreender este processo percebe mais rapidamente se <strong>E\/S<\/strong> se o gargalo reside a\u00ed ou se o estrangulamento resulta, antes, de uma cache demasiado pequena e de um n\u00famero excessivo de p\u00e1ginas sujas.<\/p>\n\n<h2>Vers\u00e3o atual: De v\u00e1rios t\u00f3picos a um s\u00f3<\/h2>\n\n<p>Historicamente, era poss\u00edvel configurar v\u00e1rios \u00abcleaners\u00bb, mas o MariaDB 10.5.1 deu in\u00edcio \u00e0 reformula\u00e7\u00e3o e o MariaDB 10.6 removeu <strong>innodb_page_cleaners<\/strong> definitivamente. Desde ent\u00e3o, um \u00fanico <code>buf_flush_page_cleaner<\/code>-Um \u00fanico thread realiza o trabalho para todas as inst\u00e2ncias do buffer pool. Isto reduz os custos de coordena\u00e7\u00e3o, simplifica o ajuste e reflete a constata\u00e7\u00e3o de que um bom algoritmo \u00e9 mais importante do que a diversidade de threads. Quem segue instru\u00e7\u00f5es de artigos sobre o MySQL ou de artigos antigos depara-se rapidamente com par\u00e2metros que hoje em dia n\u00e3o t\u00eam qualquer efeito. Verifico primeiro a vers\u00e3o exata do MariaDB antes de ajustar os supostos par\u00e2metros. Assim, evito perder tempo e concentro-me nos par\u00e2metros que influenciam o <strong>Caminho de escrita<\/strong> influenciar realmente.<\/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_perfmeeting_3829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buffer Pool, p\u00e1ginas sujas e LRU<\/h2>\n\n<p>O Buffer Pool mant\u00e9m os dados mais utilizados na RAM e poupa recursos dispendiosos <strong>Disco<\/strong>-acessos. Assim que as transa\u00e7\u00f5es escrevem, surgem \u00abDirty Pages\u00bb, que, inicialmente, s\u00f3 existem na mem\u00f3ria. O \u00abCleaner\u00bb grava-as atempadamente, para que a LRU fique livre no final e as p\u00e1ginas lidas com frequ\u00eancia permane\u00e7am no topo da cache. Estou atento ao n\u00famero de inst\u00e2ncias do buffer pool ativas e \u00e0 forma como o acesso se distribui, pois o paralelismo pode aliviar as filas de espera. Quem quiser aprofundar o assunto encontrar\u00e1 dicas pr\u00e1ticas sobre <a href=\"https:\/\/webhosting.de\/pt\/mariadb-buffer-pool-instancias-sistemas-multicore-otimizacao-de-desempenho-base-de-dados\/\">Inst\u00e2ncias do buffer pool<\/a>, por exemplo, para hosts multicore. No final, a taxa de p\u00e1ginas sujas indica se a frequ\u00eancia de limpeza acompanha a taxa de grava\u00e7\u00e3o e se a cache est\u00e1 a <strong>Acertos<\/strong> fornecimentos.<\/p>\n\n<h2>Progresso do ponto de verifica\u00e7\u00e3o e lat\u00eancia<\/h2>\n\n<p>O ponto de verifica\u00e7\u00e3o define um marcador at\u00e9 ao qual as altera\u00e7\u00f5es est\u00e3o guardadas com seguran\u00e7a no suporte de dados, e o Page Cleaner avan\u00e7a esse marcador. Se o ponto de verifica\u00e7\u00e3o ficar para tr\u00e1s, a taxa de utiliza\u00e7\u00e3o do registo e a amplifica\u00e7\u00e3o de grava\u00e7\u00e3o aumentam, o que se reflete no tempo de commit e no pico de n nas consultas. Verifico regularmente a amplitude das oscila\u00e7\u00f5es na dist\u00e2ncia do ponto de verifica\u00e7\u00e3o e se o limpador est\u00e1 a gerar picos excessivos. Se a suaviza\u00e7\u00e3o n\u00e3o for bem-sucedida, h\u00e1 o risco de ocorrerem picos de tr\u00e1fego em que os threads dos utilizadores ficam bloqueados. Para uma compreens\u00e3o b\u00e1sica, vale a pena dar uma vista de olhos em <a href=\"https:\/\/webhosting.de\/pt\/base-de-dados-checkpointing-amplificacao-da-escrita-guia-de-alojamento-escalonamento\/\">Checkpointing e amplifica\u00e7\u00e3o de grava\u00e7\u00e3o<\/a> no contexto da hospedagem. Quem analisa estes indicadores percebe rapidamente se <strong>Descarga<\/strong>- se o trabalho \u00e9 conclu\u00eddo atempadamente ou se o sistema acaba por ter de recuperar o atraso de forma apressada em fases posteriores.<\/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-threads-performance-6574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Equ\u00edvocos t\u00edpicos no tuning<\/h2>\n\n<p>Muitos esperam que threads adicionais em segundo plano proporcionem automaticamente um maior rendimento, mas isso n\u00e3o se verifica neste caso. O que continua a ser decisivo \u00e9 a qualidade do algoritmo de flush e a dose adequada de <strong>E\/S<\/strong>-Trabalho por intervalo. Um limpador demasiado agressivo gera picos de carga curtos, o que aumenta os tempos de resposta. Um limpador demasiado brando acumula demasiadas p\u00e1ginas sujas, o que acaba por provocar ondas de limpeza mais intensas posteriormente. Ambas as situa\u00e7\u00f5es criam uma sensa\u00e7\u00e3o de efeito de acorde\u00e3o nas lat\u00eancias. Por isso, procuro um padr\u00e3o uniforme que se adapte ao subsistema de mem\u00f3ria e que afete o menos poss\u00edvel os threads dos utilizadores <strong>bloqueado<\/strong>.<\/p>\n\n<h2>M\u00e9tricas e monitoriza\u00e7\u00e3o: o que eu verifico<\/h2>\n\n<p>Para tomar decis\u00f5es, baseio-me em n\u00fameros, n\u00e3o em intui\u00e7\u00e3o. Observo a percentagem de p\u00e1ginas sujas, o progresso dos pontos de verifica\u00e7\u00e3o, as taxas de grava\u00e7\u00e3o e de Fsync, bem como os tempos de espera no registo de refazer e nos ficheiros de dados. Se os tempos de commit oscilarem sob carga, analiso os atrasos de flush e o tamanho dos ficheiros do registo de refazer. A percentagem de p\u00e1ginas no fim da lista LRU tamb\u00e9m d\u00e1 uma ideia da press\u00e3o de evic\u00e7\u00e3o e da necessidade de opera\u00e7\u00f5es de flush. Picos anormais nos IOPS indicam que o Cleaner est\u00e1 a gravar pacotes demasiado grandes ou que o limite de armazenamento foi atingido. Estes indicadores revelam se o gargalo est\u00e1 mais relacionado com o tamanho da cache, <strong>Mem\u00f3ria<\/strong>- No que diz respeito ao d\u00e9bito ou \u00e0 estrat\u00e9gia de lavagem.<\/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_page_cleaner_5372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configura\u00e7\u00e3o: escolher corretamente as dimens\u00f5es e a capacidade de E\/S<\/h2>\n\n<p>Os principais par\u00e2metros de ajuste continuam a ser o tamanho do buffer pool, a capacidade de E\/S e o layout do registo. Um buffer pool maior reduz a press\u00e3o de leitura, mas n\u00e3o deve permitir que a percentagem de p\u00e1ginas sujas cres\u00e7a de forma descontrolada. Os par\u00e2metros relativos \u00e0 capacidade de E\/S controlam a quantidade de dados que o \u00abcleaner\u00bb tenta gravar numa unidade de tempo. Valores demasiado baixos provocam congestionamento, enquanto valores demasiado altos geram picos no perfil de lat\u00eancia. Eu adapto estes valores ao sistema de armazenamento real, em vez de confiar em valores padr\u00e3o abstratos. A tabela seguinte resume as configura\u00e7\u00f5es relevantes que determinam o comportamento do <strong>Descarga<\/strong>-marcar o processo.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Perspetiva\/Aspecto<\/th>\n      <th>Efeito no Page Cleaner<\/th>\n      <th>Nota sobre o MariaDB<\/th>\n      <th>Orienta\u00e7\u00e3o pr\u00e1tica<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>innodb_buffer_pool_size<\/code><\/td>\n      <td>Influencia a quantidade de p\u00e1ginas sujas e a press\u00e3o de evic\u00e7\u00e3o<\/td>\n      <td>Um pool maior requer uma cad\u00eancia consistente de flushes<\/td>\n      <td>Utilizar a RAM, mas deixar uma reserva para o SO e <strong>Consulta<\/strong>-Manter a cache<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_io_capacity<\/code> \/ <code>innodb_io_capacity_max<\/code><\/td>\n      <td>\u00c2mbito limitado dos trabalhos de limpeza previstos<\/td>\n      <td>Ajustar \u00e0s IOPS reais do SSD\/NVMe<\/td>\n      <td>Come\u00e7ar com um valor conservador e, depois, aument\u00e1-lo gradualmente<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_flush_log_at_trx_commit<\/code><\/td>\n      <td>Controla a frequ\u00eancia de Commit-Fsync<\/td>\n      <td>A escolha influencia a lat\u00eancia e a durabilidade<\/td>\n      <td>\u201e1\u201c para a maior durabilidade; \u201e2\/0\u201c para uma durabilidade inferior <strong>Lat\u00eancia<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Tamanho do registo de repeti\u00e7\u00e3o<\/td>\n      <td>Atua na dist\u00e2ncia do Checkpoint e nas ondas de Flush<\/td>\n      <td>Se for demasiado pequeno, obriga a pontos de verifica\u00e7\u00e3o frequentes<\/td>\n      <td>Dimensionar com maior capacidade para suavizar os picos de escrita<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_page_cleaners<\/code> (antigo)<\/td>\n      <td>Hoje, sem influ\u00eancia<\/td>\n      <td>Removido a partir do MariaDB 10.6<\/td>\n      <td>N\u00e3o tocar mais, concentrar-se nas atividades <strong>Par\u00e2metros<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Guia pr\u00e1tico: Testar passo a passo<\/h2>\n\n<p>Come\u00e7o por estabelecer uma refer\u00eancia clara sob carga, antes de alterar as configura\u00e7\u00f5es. Depois, regulo <code>innodb_io_capacity<\/code> em pequenos passos e observo se os picos de lat\u00eancia ocorrem com menos frequ\u00eancia. Se surgirem ondas de flush mais longas, aumentei o tamanho do redo log, para que o checkpoint disponha de mais espa\u00e7o no buffer. Em seguida, verifico se o buffer pool tem espa\u00e7o suficiente para que os dados mais solicitados n\u00e3o sejam substitu\u00eddos demasiado rapidamente. Cada altera\u00e7\u00e3o tem tempo suficiente para que os efeitos e os efeitos colaterais se manifestem de forma clara. S\u00f3 quando os indicadores e a experi\u00eancia do utilizador melhorarem em conjunto \u00e9 que considero a <strong>Etapa<\/strong> de.<\/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-pagecleaner-4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Influ\u00eancia do buffer de grava\u00e7\u00e3o dupla<\/h2>\n\n<p>O buffer de grava\u00e7\u00e3o dupla protege as p\u00e1ginas contra grava\u00e7\u00f5es parciais e blocos corrompidos, mas, ao mesmo tempo, afeta a taxa de grava\u00e7\u00e3o e os padr\u00f5es de limpeza. Especialmente quando a propor\u00e7\u00e3o de atualiza\u00e7\u00f5es \u00e9 elevada, pode influenciar a taxa de transfer\u00eancia percebida do limpador. Os sistemas de armazenamento modernos com ordem de grava\u00e7\u00e3o persistente atenuam em parte este efeito, mas este continua a ser mensur\u00e1vel. Por isso, analiso a carga de trabalho, as expectativas em termos de integridade dos dados e a lat\u00eancia aceit\u00e1vel antes de ajustar esta configura\u00e7\u00e3o. Quem precisar de mais detalhes sobre o assunto pode encontrar informa\u00e7\u00f5es adicionais no artigo 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>. Desta forma, \u00e9 poss\u00edvel determinar se a vida \u00fatil e <strong>Prote\u00e7\u00e3o<\/strong> Obter prioridade sobre a lat\u00eancia m\u00ednima.<\/p>\n\n<h2>Sintomas frequentes e medidas a tomar<\/h2>\n\n<p>Se os tempos de commit dispararem, apesar de haver CPU dispon\u00edvel, isso indica um congestionamento no flush ou um armazenamento insuficiente. Grandes oscila\u00e7\u00f5es nas IOPS sugerem que os pacotes de flush s\u00e3o demasiado grandes; nesse caso, reduzo a capacidade de E\/S e aumente o redol. Se a percentagem de p\u00e1ginas sujas se mantiver permanentemente elevada, ou o \u00abCleaner\u00bb est\u00e1 a funcionar de forma demasiado defensiva, ou o conjunto de buffers \u00e9 demasiado pequeno. Se as p\u00e1ginas mais utilizadas forem rapidamente empurradas para o fim da lista LRU, significa que falta espa\u00e7o na cache ou que a carga de grava\u00e7\u00e3o est\u00e1 a sobrecarregar demasiado o conjunto de buffers. Em ambientes de alojamento, o armazenamento partilhado costuma ser um freio; neste caso, a \u00fanica solu\u00e7\u00e3o \u00e9 medir a carga ao longo do dia e, se necess\u00e1rio, mudar para suportes mais r\u00e1pidos. Documento todas as altera\u00e7\u00f5es, para que a causa e <strong>Efeito<\/strong> permanecer\u00e1 inequ\u00edvoco mais tarde.<\/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-performance-4629.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como o Cleaner estabelece prioridades entre a lista de limpeza e a LRU<\/h2>\n<p>O InnoDB distingue, durante a grava\u00e7\u00e3o, entre duas fontes principais: a lista LRU (p\u00e1ginas que t\u00eam de dar lugar a novos acessos) e a lista de flush (todas as p\u00e1ginas sujas, ordenadas pelo n\u00famero de sequ\u00eancia de registo mais antigo). O Page Cleaner equilibra estes dois objetivos: limpa a parte final da lista LRU para evitar evic\u00e7\u00f5es e, em paralelo, retira p\u00e1ginas da lista de flush para fazer avan\u00e7ar constantemente o ponto de verifica\u00e7\u00e3o. Se o espa\u00e7o livre no buffer ficar sob press\u00e3o, o LRU-Flush tem prioridade; por outro lado, se a dist\u00e2ncia do ponto de verifica\u00e7\u00e3o aumentar, o Cleaner aumenta a propor\u00e7\u00e3o retirada da Lista de Limpeza. Esta altern\u00e2ncia explica por que raz\u00e3o os perfis de lat\u00eancia variam com cargas de trabalho vari\u00e1veis: se a press\u00e3o de leitura aumentar, predominam as limpezas LRU; se a press\u00e3o de escrita aumentar, predominam as tarefas relacionadas com o ponto de verifica\u00e7\u00e3o. Analiso este padr\u00e3o na monitoriza\u00e7\u00e3o para decidir se devo otimizar mais a capacidade de E\/S ou a reserva do redo log.<\/p>\n\n<h2>Lavagem adaptativa: interpretar corretamente os valores-limite<\/h2>\n<p>O MariaDB recorre ao \u00abflushing\u00bb adaptativo para ajustar dinamicamente a taxa de escrita ao consumo de redo e \u00e0 percentagem de p\u00e1ginas sujas. Na pr\u00e1tica, observo tr\u00eas par\u00e2metros: o valor-alvo para as p\u00e1ginas sujas, o n\u00edvel m\u00ednimo e a taxa de escrita atual. Se a percentagem de p\u00e1ginas sujas estiver acima do valor-alvo, o \u00abCleaner\u00bb torna-se mais rigoroso; se estiver abaixo, torna-se mais cauteloso. Um limite m\u00ednimo demasiado baixo leva a que o flushing seja iniciado com frequ\u00eancia e pode gerar picos de lat\u00eancia curtos, mas percet\u00edveis. Um limite demasiado alto deixa demasiados dados sujos na mem\u00f3ria, o que mais tarde produz efeitos mais graves. Ajusto os valores-limite de forma a corresponderem \u00e0s caracter\u00edsticas do sistema de armazenamento: os SSDs NVMe r\u00e1pidos suportam taxas de limpeza cont\u00ednuas e moderadamente mais elevadas; os sistemas mais lentos beneficiam de lotes mais pequenos e uniformes.<\/p>\n\n<h2>Utilizar de forma adequada as op\u00e7\u00f5es espec\u00edficas de armazenamento<\/h2>\n<p>O Page Cleaner n\u00e3o funciona no v\u00e1cuo \u2013 a escolha do m\u00e9todo de limpeza e o comportamento do sistema de ficheiros determinam o resultado. Com <code>innodb_flush_method<\/code> controlo se o InnoDB grava as p\u00e1ginas diretamente (O_DIRECT) ou atrav\u00e9s da cache do sistema operativo. A grava\u00e7\u00e3o direta evita o duplo armazenamento em cache e estabiliza as lat\u00eancias no Linux com XFS\/EXT4. No entanto, sistemas de ficheiros como o ZFS lidam com o O_DIRECT de forma diferente; nesses casos, verifico se um m\u00e9todo sincronizado (<em>fsync<\/em>\/<em>O_DSYNC<\/em>) que apresenta o perfil mais consistente. Al\u00e9m disso, vale a pena dar uma olhadela na limpeza de vizinhan\u00e7as (<em>vizinhos alinhados<\/em>): Em matrizes de HDD, a grava\u00e7\u00e3o simult\u00e2nea de blocos adjacentes pode fazer sentido; em SSD\/NVMe, reduzo essa pr\u00e1tica para evitar uma amplifica\u00e7\u00e3o de grava\u00e7\u00e3o desnecess\u00e1ria. O essencial \u00e9 que a configura\u00e7\u00e3o se adapte ao suporte f\u00edsico \u2013 o melhor algoritmo de limpeza de pouco serve se o armazenamento subjacente ficar sobrecarregado.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o na pr\u00e1tica: consultas que me ajudam<\/h2>\n<p>Para ter uma vis\u00e3o geral r\u00e1pida, utilizo tr\u00eas perspetivas: valores de estado globais, m\u00e9tricas do InnoDB e o dump peri\u00f3dico.<\/p>\n<ul>\n  <li>Indicadores r\u00e1pidos: <code>SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';<\/code>, <code>... LIKE 'Innodb_os_log_written';<\/code>, <code>... LIKE 'Innodb_log_waits';<\/code>. Subir <em>esperas de registo<\/em>, o registo Redo \u00e9 demasiado pequeno ou o comando Flush \u00e9 demasiado lento.<\/li>\n  <li>N\u00edvel de detalhe: <code>SHOW ENGINE INNODB STATUS\\G<\/code> fornece posi\u00e7\u00f5es de pontos de verifica\u00e7\u00e3o (LSN), comprimentos das listas de limpeza e indica\u00e7\u00f5es de estrangulamentos. Comparo o \u201en\u00famero de sequ\u00eancia de registo\u201c e o \u201e\u00faltimo ponto de verifica\u00e7\u00e3o em\u201c para estimar a dist\u00e2ncia do ponto de verifica\u00e7\u00e3o.<\/li>\n  <li>Telemetria mais precisa: <code>SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%';<\/code> ou <code>... LIKE 'log_%';<\/code> revela tend\u00eancias que s\u00e3o facilmente ignoradas em testes r\u00e1pidos.<\/li>\n<\/ul>\n<p>O importante \u00e9 a correla\u00e7\u00e3o: se as lat\u00eancias de commit aumentarem em simult\u00e2neo com o aumento da taxa de Fsync, \u00e9 prov\u00e1vel que o \u00abCleaner\u00bb esteja configurado com um valor demasiado rigoroso. Se a propor\u00e7\u00e3o de p\u00e1ginas sujas e a dist\u00e2ncia entre pontos de verifica\u00e7\u00e3o aumentarem em simult\u00e2neo, significa que h\u00e1 falta de d\u00e9bito de flush ou que o Redo-Log tem uma capacidade insuficiente.<\/p>\n\n<h2>Perfis de carga de trabalho: OLTP, relat\u00f3rios, processamento em massa<\/h2>\n<p>Dependendo da carga de trabalho, dou \u00eanfase a aspetos diferentes. Em ambientes OLTP, procuro obter pequenos lotes de flush constantes e uma faixa de lat\u00eancia estreita \u2014 neste caso, com configura\u00e7\u00f5es moderadas <code>innodb_io_capacity<\/code> e um buffer de redo suficiente s\u00e3o fundamentais. Para janelas de reporting ou ETL, tolero temporariamente taxas de flush mais elevadas, mas tenho o cuidado de garantir que estas n\u00e3o se prolonguem at\u00e9 aos picos de utiliza\u00e7\u00e3o. No carregamento de dados em massa, prefiro registos de redo maiores e \u2014 caso os requisitos de durabilidade o permitam \u2014 uma disciplina de Fsync temporariamente reduzida (<code>innodb_flush_log_at_trx_commit=2<\/code>). O Page Cleaner pode ent\u00e3o continuar a \u201etrabalhar em segundo plano\u201c de forma cont\u00ednua, sem atrasar as transa\u00e7\u00f5es dos utilizadores. Ap\u00f3s a conclus\u00e3o, restabele\u00e7o os valores mais rigorosos, para que o funcionamento di\u00e1rio se mantenha est\u00e1vel.<\/p>\n\n<h2>Projetos de longo prazo, purga e efeitos indiretos<\/h2>\n<p>Embora o thread de limpeza tenha outros objetivos (limpar vers\u00f5es antigas), o seu ritmo influencia o panorama geral. Se as vers\u00f5es antigas permanecerem por muito tempo, o espa\u00e7o necess\u00e1rio aumenta e a carga de mem\u00f3ria e de E\/S distribui-se de forma menos favor\u00e1vel. Isso pode sobrecarregar indiretamente o Page Cleaner, porque mais p\u00e1ginas ficam retidas no pool e o LRU fica mais rapidamente sob press\u00e3o. Por isso, mantenho-me atento aos atrasos na purga e asseguro-me de que nenhuma transa\u00e7\u00e3o de longa dura\u00e7\u00e3o \u201ebloqueie\u201c o sistema. Progresso est\u00e1vel da purga, \u00abCleaner\u00bb cont\u00ednuo, cad\u00eancia equilibrada de grava\u00e7\u00e3o \u2014 estas tr\u00eas engrenagens t\u00eam de encaixar-se entre si.<\/p>\n\n<h2>Lista de verifica\u00e7\u00e3o para a dete\u00e7\u00e3o de falhas no percurso de escrita<\/h2>\n<ul>\n  <li>A dist\u00e2ncia do ponto de verifica\u00e7\u00e3o est\u00e1 elevada e a aumentar? Aumentar o Redo-Log e <code>innodb_io_capacity<\/code> Aumentar e, em seguida, verificar novamente o curso.<\/li>\n  <li>Picos de IOPS e picos de commits? <code>innodb_io_capacity<\/code> reduzir ligeiramente, uniformizar o tamanho do lote, ter em conta o efeito de dupla grava\u00e7\u00e3o.<\/li>\n  <li>A percentagem de p\u00e1ginas sujas mant\u00e9m-se elevada de forma persistente? Aumente o buffer pool ou torne a limpeza adaptativa mais rigorosa; verifique a carga de trabalho nos hotsets.<\/li>\n  <li>As esperas de registo est\u00e3o vis\u00edveis? Ou a reserva de Redo \u00e9 demasiado pequena ou o Flush est\u00e1 a ficar para tr\u00e1s. Primeiro, aumente a reserva de Redo e, depois, ajuste com precis\u00e3o o d\u00e9bito do Cleaner.<\/li>\n  <li>O progresso do LSN est\u00e1 inst\u00e1vel? Os pacotes \u00abflush\u00bb s\u00e3o inconsistentes. Altere os valores gradualmente at\u00e9 que se observe um progresso regular.<\/li>\n  <li>Existem gargalos relacionados com o armazenamento? Verifique o m\u00e9todo de flush, o agendador e as defini\u00e7\u00f5es de cache RAID\/SAN; utilize os IOPS sustent\u00e1veis, em vez dos IOPS de pico, como valor-alvo.<\/li>\n<\/ul>\n\n<h2>Exemplo: calibra\u00e7\u00e3o em tr\u00eas etapas<\/h2>\n<p>Numa inst\u00e2ncia OLTP com elevada carga de escrita, come\u00e7o por medir a carga na janela de produ\u00e7\u00e3o. 1.\u00aa ronda: Medei os n\u00edveis de preenchimento do Redo Log e a dist\u00e2ncia do checkpoint. O registo est\u00e1 frequentemente ocupado em 70\u201380 %, a dist\u00e2ncia varia muito \u2013 por isso, duplico o tamanho do Redo. Ronda 2: Ap\u00f3s um novo teste, as lat\u00eancias estabilizam, mas ocasionalmente ocorrem picos de Fsync. Reduzo <code>innodb_io_capacity<\/code> moderadamente, at\u00e9 que a distribui\u00e7\u00e3o de IOPS se estabilize. Ronda 3: A taxa de p\u00e1ginas sujas mant\u00e9m-se no limite superior. Atribuo mais RAM ao buffer pool, o que alivia a carga da LRU e torna o trabalho do limpador mais previs\u00edvel. Resultado: o Commit-P95 diminui sensivelmente, a curva de IOPS torna-se mais uniforme e o ponto de verifica\u00e7\u00e3o avan\u00e7a de forma constante \u2013 exatamente o padr\u00e3o que pretendo alcan\u00e7ar.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Um \u00fanico thread de limpeza organiza a liberta\u00e7\u00e3o das p\u00e1ginas sujas, mant\u00e9m o ponto de verifica\u00e7\u00e3o em movimento e protege as consultas contra picos intensos de grava\u00e7\u00e3o. Os par\u00e2metros relevantes continuam a ser o tamanho do buffer pool, a capacidade de E\/S, o layout do redo log e as caracter\u00edsticas do sistema de armazenamento. Par\u00e2metros obsoletos, como <strong>innodb_page_cleaners<\/strong> J\u00e1 n\u00e3o lhes dou aten\u00e7\u00e3o e concentro-me em indicadores que t\u00eam influ\u00eancia direta. Quem analisa m\u00e9tricas como a taxa de p\u00e1ginas sujas, o intervalo entre checkpoints e a dura\u00e7\u00e3o do commit identifica os estrangulamentos mais rapidamente. Altera\u00e7\u00f5es graduais com uma linha de base clara proporcionam resultados fi\u00e1veis, sem ocultar efeitos secund\u00e1rios. Assim, o Page Cleaner funciona discretamente em segundo plano, e o <strong>Tempo de resposta<\/strong> mant\u00e9m-se constante \u2013 mesmo sob carga.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explica\u00e7\u00e3o sobre os threads do Page Cleaner do MariaDB: O Page Cleaner do InnoDB do MariaDB influencia as p\u00e1ginas sujas e o desempenho da base de dados.<\/p>","protected":false},"author":1,"featured_media":21460,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21467","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":"101","_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":"Page Cleaner","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":"21460","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21467","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=21467"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21467\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21460"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}