{"id":21539,"date":"2026-09-19T08:33:36","date_gmt":"2026-09-19T06:33:36","guid":{"rendered":"https:\/\/webhosting.de\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/"},"modified":"2026-09-19T08:33:36","modified_gmt":"2026-09-19T06:33:36","slug":"mariadb-metodos-de-flush-innodb-fsync-guia-de-desempenho-buffer","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/mariadb-flush-methoden-innodb-fsync-performance-guide-buffer\/","title":{"rendered":"Compara\u00e7\u00e3o dos m\u00e9todos de flush do MariaDB: configurar o flush do InnoDB de forma ideal"},"content":{"rendered":"<p>Comparo os m\u00e9todos mais importantes para <strong>MariaDB Flush<\/strong> e mostro como configurar o `innodb flush` de forma a reduzir a lat\u00eancia de escrita e garantir a seguran\u00e7a dos dados. O foco recai sobre as op\u00e7\u00f5es de `innodb_flush_method`, o controlador de durabilidade `innodb_flush_log_at_trx_commit`, bem como valores adequados para p\u00e1ginas sujas e capacidade de E\/S em HDD, SSD e NVMe.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>innodb_flush_method<\/strong> determina a forma como o InnoDB interage com a cache do sistema operativo e evita o duplo armazenamento em cache.<\/li>\n  <li><strong>innodb_flush_log_at_trx_commit<\/strong> define a durabilidade em rela\u00e7\u00e3o \u00e0 lat\u00eancia por commit.<\/li>\n  <li><strong>P\u00e1ginas sujas<\/strong> e a capacidade de E\/S uniformiza as taxas de grava\u00e7\u00e3o e evita picos de flush.<\/li>\n  <li><strong>Vizinhos de naipe<\/strong> distingue as estrat\u00e9gias otimizadas para HDD das otimizadas para SSD\/NVMe.<\/li>\n  <li><strong>Configura\u00e7\u00f5es na nuvem<\/strong> exigem O_DIRECT, um limite adequado de IOPS e uma monitoriza\u00e7\u00e3o rigorosa.<\/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-flush-0123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que significa, concretamente, \u00abinnodb_flush_method\u00bb?<\/h2>\n\n<p>Eu escolho o <strong>M\u00e9todo Flush<\/strong> depende da forma como o InnoDB interage com a cache do sistema operativo. Com <strong>fsync<\/strong> Os dados v\u00e3o primeiro para a cache do sistema operativo e s\u00f3 depois s\u00e3o gravados de forma permanente atrav\u00e9s do fsync; isto pode levar a um duplo armazenamento em cache. Se definir O_DIRECT, o InnoDB contorna em grande parte a cache de p\u00e1ginas, o que poupa RAM e \u00e9 quase sempre ben\u00e9fico em SSD\/NVMe. O_DSYNC utiliza o Write-Through e reduz o armazenamento em buffer, o que pode ser \u00fatil em combina\u00e7\u00f5es espec\u00edficas. O_DIRECT_NO_FSYNC baseia-se no O_DIRECT e ajusta o comportamento de sincroniza\u00e7\u00e3o, o que constitui uma op\u00e7\u00e3o s\u00f3lida em hardware fi\u00e1vel com o seu pr\u00f3prio mecanismo de prote\u00e7\u00e3o.<\/p>\n\n<h3>Valores e vers\u00f5es t\u00edpicas<\/h3>\n\n<p>A partir do MariaDB 10.6, <strong>O_DIRECTO<\/strong> \u00e9 frequentemente a configura\u00e7\u00e3o predefinida, porque evita o \u00abdouble-caching\u00bb. Nas vers\u00f5es mais antigas, predomina <strong>fsync<\/strong>, o que ainda pode ser aceit\u00e1vel para configura\u00e7\u00f5es com discos r\u00edgidos (HDD). A partir da vers\u00e3o 11.0, outras vari\u00e1veis, como innodb_data_file_buffering e innodb_log_file_buffering, controlam os detalhes do armazenamento em buffer. Na pr\u00e1tica, o `innodb_flush_method` continua a ser o par\u00e2metro principal que verifico em primeiro lugar. Depois, vou ajustando os par\u00e2metros de detalhe at\u00e9 que as lat\u00eancias diminuam e o d\u00e9bito se mantenha constante.<\/p>\n\n<h2>Utilizar a op\u00e7\u00e3o `innodb_flush_log_at_trx_commit` de forma seletiva<\/h2>\n\n<p>Considero <strong>Durabilidade<\/strong> e a lat\u00eancia separadamente, pois o par\u00e2metro `innodb_flush_log_at_trx_commit` determina ambos. O valor 1 grava e executa o `fsync` em cada `commit`, o que oferece a m\u00e1xima seguran\u00e7a, mas atrasa consideravelmente os discos lentos. O valor 2 grava no cache do SO no momento do commit e executa o fsync aproximadamente uma vez por segundo; isto reduz a lat\u00eancia, mas acarreta o risco de perda de dados de at\u00e9 um segundo em caso de falha de energia. O valor 0 adia completamente as opera\u00e7\u00f5es de grava\u00e7\u00e3o do registo para um intervalo de um segundo e proporciona o m\u00e1ximo desempenho de grava\u00e7\u00e3o com o maior risco. Quem prestar aten\u00e7\u00e3o adicional \u00e0 estrat\u00e9gia do binlog, poder\u00e1 ajustar de forma inteligente as lat\u00eancias de commit aos requisitos de replica\u00e7\u00e3o; explico aqui os detalhes desta intera\u00e7\u00e3o: <a href=\"https:\/\/webhosting.de\/pt\/logica-de-desempenho-dos-registos-binarios-do-mariadb\/\">Registos bin\u00e1rios<\/a>.<\/p>\n\n<h2>Gerir o esvaziamento da p\u00e1gina e as p\u00e1ginas sujas<\/h2>\n\n<p>Considero que a percentagem de <strong>P\u00e1ginas sujas<\/strong> de forma a que as taxas de grava\u00e7\u00e3o se mantenham est\u00e1veis. Para tal, defino o par\u00e2metro `innodb_max_dirty_pages_pct` num valor moderado, para evitar picos repentinos de flush. Os valores de innodb_io_capacity e innodb_io_capacity_max s\u00e3o ajustados de acordo com os IOPS reais do armazenamento: baixos para HDD, mais elevados para SSD\/NVMe. Um thread do Page Cleaner bem configurado grava atempadamente, do ponto de vista da LRU, antes que as p\u00e1ginas sejam substitu\u00eddas. Descrevo aqui mais informa\u00e7\u00f5es sobre o ajuste fino das threads e sobre m\u00e9tricas \u00fateis: <a href=\"https:\/\/webhosting.de\/pt\/mariadb-limpeza-de-paginas-threads-base-de-dados\/\">Threads do Page Cleaner<\/a>.<\/p>\n\n<h2>Vizinhos em linha: HDD vs. SSD\/NVMe<\/h2>\n\n<p>Com <strong>innodb_flush_neighbors<\/strong> Utilizo padr\u00f5es de grava\u00e7\u00e3o otimizados para discos r\u00edgidos (HDD) ou desativo-os. Nos discos r\u00edgidos (HDD), a grava\u00e7\u00e3o simult\u00e2nea de p\u00e1ginas adjacentes aumenta a efici\u00eancia, uma vez que a cabe\u00e7a tem de se deslocar menos. Em SSD\/NVMe, a localiza\u00e7\u00e3o no suporte \u00e9 praticamente irrelevante; nessas unidades, a grava\u00e7\u00e3o simult\u00e2nea gera opera\u00e7\u00f5es de grava\u00e7\u00e3o desnecess\u00e1rias. Para discos r\u00edgidos (HDD), defino normalmente o valor 1; para SSD\/NVMe, o valor 0. Desta forma, reduzo as opera\u00e7\u00f5es de grava\u00e7\u00e3o sup\u00e9rfluas e prolongo a vida \u00fatil das unidades mais r\u00e1pidas.<\/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_flush_vergleich_7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreender e limitar os custos do fsync<\/h2>\n\n<p>Eu me\u00e7o o <strong>fsync<\/strong>-Lat\u00eancia, porque cada mil\u00e9simo de segundo atrasa os commits. Caso contr\u00e1rio, as cargas de trabalho com muitas grava\u00e7\u00f5es passam grande parte do tempo \u00e0 espera da confirma\u00e7\u00e3o do suporte de dados. Com innodb_flush_log_at_trx_commit=2 ou 0, reduzo significativamente o n\u00famero de sincroniza\u00e7\u00f5es dispendiosas. O_DIRECT ou O_DIRECT_NO_FSYNC ajuda a evitar o duplo armazenamento em cache e a simplificar os percursos de E\/S. Em hardware lento, obtenho frequentemente ganhos percet\u00edveis quando analiso em conjunto a frequ\u00eancia de sincroniza\u00e7\u00e3o, o m\u00e9todo de flush e a quota de p\u00e1ginas sujas.<\/p>\n\n<h2>Valores iniciais recomendados consoante o suporte de armazenamento<\/h2>\n\n<p>Come\u00e7o com coisas que fazem sentido <strong>Linha de base<\/strong>-Defino os valores e, em seguida, ajusto-os com base nos valores medidos. A tabela fornece orienta\u00e7\u00f5es para configura\u00e7\u00f5es e cargas de trabalho t\u00edpicas. Os fatores decisivos s\u00e3o os IOPS reais, as lat\u00eancias e a percentagem de transa\u00e7\u00f5es de grava\u00e7\u00e3o. Ap\u00f3s a primeira execu\u00e7\u00e3o, verifico a taxa de p\u00e1ginas sujas, a lat\u00eancia de commit e o n\u00famero de chamadas fsync. Em seguida, fa\u00e7o ajustes graduais at\u00e9 que o perfil se mantenha limpo e constante.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e9dio<\/th>\n      <th>innodb_flush_method<\/th>\n      <th>innodb_flush_log_at_trx_commit<\/th>\n      <th>innodb_io_capacity<\/th>\n      <th>innodb_flush_neighbors<\/th>\n      <th>Notas<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>DISCO R\u00cdGIDO<\/td>\n      <td>fsync ou O_DIRECT<\/td>\n      <td>1 (cr\u00edtico) \/ 2 (equil\u00edbrio)<\/td>\n      <td>200\u2013400<\/td>\n      <td>1<\/td>\n      <td>Mais lat\u00eancia por <strong>Compromisso<\/strong>, \u00e9 importante a lavagem cont\u00ednua<\/td>\n    <\/tr>\n    <tr>\n      <td>SSD<\/td>\n      <td>O_DIRECTO<\/td>\n      <td>1 (cr\u00edtico) \/ 2 (equil\u00edbrio)<\/td>\n      <td>1000\u20132000<\/td>\n      <td>0<\/td>\n      <td>Evitar o duplo armazenamento em cache, manter o n\u00famero de p\u00e1ginas sujas a um n\u00edvel moderado<\/td>\n    <\/tr>\n    <tr>\n      <td>NVMe<\/td>\n      <td>O_DIRECT ou O_DIRECT_NO_FSYNC<\/td>\n      <td>1 (cr\u00edtico) \/ 2 (equil\u00edbrio) \/ 0 (caso especial)<\/td>\n      <td>2000\u20138000+<\/td>\n      <td>0<\/td>\n      <td>Muito baixo <strong>Lat\u00eancia<\/strong>, Escolher cuidadosamente a frequ\u00eancia de sincroniza\u00e7\u00e3o<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>A este respeito, tenho em conta o InnoDB <strong>Buffer de grava\u00e7\u00e3o dupla<\/strong>, que reduz a corrup\u00e7\u00e3o de dados em caso de falhas, mas gera grava\u00e7\u00f5es adicionais; resumo aqui de forma concisa os pormenores e as op\u00e7\u00f5es de ajuste: <a href=\"https:\/\/webhosting.de\/pt\/innodb-buffer-de-gravacao-dupla-seguranca-otimizacao-de-desempenho-foco\/\">Buffer de grava\u00e7\u00e3o dupla<\/a>. Em ambientes com grande volume de grava\u00e7\u00e3o, fa\u00e7o medi\u00e7\u00f5es com e sem os efeitos do \u00abdoublewrite\u00bb antes de tomar decis\u00f5es. Os sistemas cr\u00edticos d\u00e3o prioridade \u00e0 integridade em detrimento da velocidade m\u00e1xima de grava\u00e7\u00e3o. As configura\u00e7\u00f5es de teste ou de an\u00e1lise podem ser mais agressivas. As minhas decis\u00f5es s\u00e3o sempre fundamentadas em benchmarks repet\u00edveis.<\/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-flush-methoden-vergleich-5876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ambientes de nuvem e contentores<\/h2>\n\n<p>Evito a duplica\u00e7\u00e3o <strong>Cache de p\u00e1gina<\/strong>, porque a RAM \u00e9 escassa nesse ambiente; por isso, o O_DIRECT costuma ser uma boa op\u00e7\u00e3o. Ajusto o par\u00e2metro `innodb_io_capacity` de acordo com os limites de IOPS do volume, para n\u00e3o provocar qualquer limita\u00e7\u00e3o de desempenho. O buffer pool tem de se adequar ao limite do Cgroup, caso contr\u00e1rio, corre-se o risco de ocorrerem encerramentos por falta de mem\u00f3ria (OOM). Os volumes persistentes s\u00e3o obrigat\u00f3rios, uma vez que o armazenamento ef\u00e9mero n\u00e3o oferece durabilidade. Em configura\u00e7\u00f5es muito el\u00e1sticas, limito o n\u00famero excessivo de liga\u00e7\u00f5es simult\u00e2neas e utilizo o pool de threads de forma ponderada.<\/p>\n\n<h2>Defini\u00e7\u00f5es de c\u00f3pia de seguran\u00e7a e limpeza<\/h2>\n\n<p>Estou a verificar se as ferramentas de c\u00f3pia de seguran\u00e7a t\u00eam as suas pr\u00f3prias <strong>Descarga<\/strong>-Utilizar as defini\u00e7\u00f5es. O mariadb-backup pode definir o par\u00e2metro innodb_flush_method de forma diferente, para garantir uma vis\u00e3o consistente. Se os par\u00e2metros do backup e do servidor n\u00e3o estiverem alinhados, ocorrem picos de E\/S desnecess\u00e1rios. Durante os backups programados, regulo cuidadosamente a capacidade de E\/S para garantir que os caminhos de leitura\/grava\u00e7\u00e3o permane\u00e7am limpos. Ap\u00f3s a execu\u00e7\u00e3o, verifico as lat\u00eancias e as percentagens de p\u00e1ginas sujas para excluir efeitos secund\u00e1rios.<\/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-flush-optimal-3435.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Afina\u00e7\u00e3o passo a passo na pr\u00e1tica<\/h2>\n\n<p>Come\u00e7o com um <strong>Invent\u00e1rio<\/strong>: Tipo de armazenamento, IOPS reais, lat\u00eancias e d\u00e9bito. Em seguida, defino o tamanho do buffer pool, de acordo com a RAM dispon\u00edvel ou com o limite do Cgroup. Depois, seleciono o m\u00e9todo de flush (HDD: fsync\/O_DIRECT; SSD\/NVMe: O_DIRECT ou O_DIRECT_NO_FSYNC). Para garantir a durabilidade, defino innodb_flush_log_at_trx_commit como 1 para dados cr\u00edticos ou 2, caso seja aceit\u00e1vel uma perda de um segundo. Por fim, configuro o innodb_io_capacity e o innodb_max_dirty_pages_pct de forma a que o flushing decorra de maneira tranquila e constante, e verifico as m\u00e9tricas regularmente.<\/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-flush-vergleich-8243.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionar corretamente o tamanho do registo de repeti\u00e7\u00e3o e os pontos de verifica\u00e7\u00e3o<\/h2>\n\n<p>Evito picos de fluxo ao ajustar o <strong>Registos de repeti\u00e7\u00e3o<\/strong> dimensionar adequadamente. Os ficheiros de registo demasiado pequenos obrigam o InnoDB a efetuar checkpoints frequentes; o resultado \u00e9 contrapress\u00e3o e lat\u00eancias inst\u00e1veis. Com ficheiros de registo maiores, suavizo o fluxo dos checkpoints, porque \u00e9 poss\u00edvel armazenar em buffer mais dados de altera\u00e7\u00e3o antes de estes serem for\u00e7ados a migrar para os ficheiros de dados. Ao faz\u00ea-lo, tenho em conta dois limites: em primeiro lugar, a capacidade de E\/S dispon\u00edvel (um buffer grande n\u00e3o protege contra discos demasiado lentos); em segundo lugar, o tempo de recupera\u00e7\u00e3o ap\u00f3s falha, que aumenta com logs de redo muito grandes. Em cargas de trabalho intensivas em grava\u00e7\u00e3o, defino o tamanho do registo de forma a que os picos de carga t\u00edpicos sejam absorvidos dentro do or\u00e7amento de registo, sem que o tempo de recupera\u00e7\u00e3o aumente de forma desproporcionada.<\/p>\n\n<p>Para o ajuste fino, observo as m\u00e9tricas relativas \u00e0 \u201eidade do checkpoint\u201c e a rela\u00e7\u00e3o entre a taxa de grava\u00e7\u00e3o no registo e a taxa de esvaziamento das p\u00e1ginas de dados. Se os checkpoints atingirem repetidamente o limite m\u00e1ximo, aumento o tamanho do log ou aumentei cuidadosamente a capacidade de E\/S do \u00abpage cleaner\u00bb. O objetivo \u00e9 um avan\u00e7o suave e cont\u00ednuo dos checkpoints, sem a\u00e7\u00f5es for\u00e7adas.<\/p>\n\n<h2>Lavagem adaptativa e valores-limite<\/h2>\n\n<p>Os mecanismos adaptativos do InnoDB ajudam a otimizar o flushing do <strong>Velocidade de escrita<\/strong> ajustar. Tenho o cuidado de garantir que o limiar LWM (Low Watermark) para as p\u00e1ginas sujas n\u00e3o seja demasiado baixo, para que o Page-Cleaner n\u00e3o funcione constantemente \u201eno limite\u201c. Ao mesmo tempo, evito valores m\u00e1ximos que conduzam a limpezas em massa demasiado agressivas. Na pr\u00e1tica, verifico se a rela\u00e7\u00e3o entre \u201enovas p\u00e1ginas sujas por segundo\u201c e \u201eIOPS de limpeza\u201c se mant\u00e9m est\u00e1vel a longo prazo. Se o conjunto de buffers ficar constantemente sujo acima do valor-alvo, aumento gradualmente o par\u00e2metro innodb_io_capacity ou reduzo os valores-alvo das p\u00e1ginas sujas.<\/p>\n\n<p>Em configura\u00e7\u00f5es NVMe, posso dar mais margem ao Page-Cleaner, porque os dispositivos mant\u00eam lat\u00eancias curtas mesmo sob carga. Em discos r\u00edgidos (HDDs), trabalho com limiares mais conservadores e limito os picos acentuados, para evitar picos de lat\u00eancia decorrentes da busca. A intera\u00e7\u00e3o com <strong>innodb_flush_neighbors<\/strong> Utilizo-o de forma espec\u00edfica: o HDD beneficia da proximidade f\u00edsica, ao contr\u00e1rio do Flash.<\/p>\n\n<h2>Binlog e Group-Commit em conjunto<\/h2>\n\n<p>Quem utiliza a replica\u00e7\u00e3o tem isso em conta <strong>Registo de commit<\/strong> Sobre o Redo-Log e o Binary Log. Configurei as frequ\u00eancias de flush de forma a que o Group-Commit seja aplicado: muitas transa\u00e7\u00f5es pequenas devem ser flushadas em conjunto, em vez de sincronizar cada commit individualmente. Para tal, utilizo innodb_flush_log_at_trx_commit=1 para m\u00e1xima durabilidade ou 2 para menor lat\u00eancia. Paralelamente, configuro o mecanismo de sincroniza\u00e7\u00e3o do Binlog de forma a que se adapte ao sistema de destino. Uma frequ\u00eancia de sincroniza\u00e7\u00e3o baixa reduz os custos por commit, mas pode significar uma maior perda de binlog em caso de falhas. Em ambientes com elevada taxa de grava\u00e7\u00e3o e um atraso aceit\u00e1vel entre o mestre e a r\u00e9plica, aceito um desacoplamento moderado das sincroniza\u00e7\u00f5es do binlog para reduzir as lat\u00eancias. A l\u00f3gica geral e os compromissos s\u00e3o abordados no artigo sobre <a href=\"https:\/\/webhosting.de\/pt\/logica-de-desempenho-dos-registos-binarios-do-mariadb\/\">Registos bin\u00e1rios<\/a> e, em seguida, adapto-o ao perfil espec\u00edfico do lavat\u00f3rio.<\/p>\n\n<h2>Sistema de ficheiros, cache de grava\u00e7\u00e3o e prote\u00e7\u00e3o contra falhas de energia<\/h2>\n\n<p>Eu classifico o <strong>Caracter\u00edsticas da mem\u00f3ria e do controlador<\/strong> antes da afina\u00e7\u00e3o. Aparelhos com <em>Prote\u00e7\u00e3o contra perdas de energia<\/em> (PLP) podem utilizar caches de grava\u00e7\u00e3o com seguran\u00e7a; sem o PLP, existe o risco de que as grava\u00e7\u00f5es marcadas como confirmadas se percam em caso de falha de energia. Nesses casos, opto por uma abordagem mais conservadora: os caminhos fsync continuam a ser obrigat\u00f3rios, e s\u00f3 utilizo o O_DIRECT_NO_FSYNC em hardware com prote\u00e7\u00e3o fi\u00e1vel. Nos sistemas de ficheiros Linux, como o ext4 ou o XFS, estas barreiras est\u00e3o ativas por predefini\u00e7\u00e3o; n\u00e3o as desativo de \u00e2nimo leve, mas sim oriento o ajuste em torno das garantias existentes. No ZFS, tenho tamb\u00e9m em conta o seu pr\u00f3prio \u00abIntent Log\u00bb e as estrat\u00e9gias de cache; dependendo da configura\u00e7\u00e3o, vale a pena adotar uma estrat\u00e9gia ajustada separadamente, que tamb\u00e9m minimize o \u00abdouble-caching\u00bb.<\/p>\n\n<p>Para garantir um desempenho consistente, verifico tamb\u00e9m os alinhamentos (por exemplo, p\u00e1ginas de 4K em SSD) e a negocia\u00e7\u00e3o da profundidade da fila. Lat\u00eancias curtas e determin\u00edsticas s\u00e3o, muitas vezes, mais importantes para os percursos de commit do que o n\u00famero m\u00e1ximo de IOPS em benchmarks sint\u00e9ticos. Por isso, realizo os testes com blocos realistas e n\u00edveis de concorr\u00eancia, em vez de me limitar apenas a cargas de trabalho de pico.<\/p>\n\n<h2>Metodologia de medi\u00e7\u00e3o: m\u00e9tricas, estado e diagn\u00f3stico<\/h2>\n\n<p>Controlo a afina\u00e7\u00e3o atrav\u00e9s de <strong>valores de medi\u00e7\u00e3o concretos<\/strong> em vez de emo\u00e7\u00e3o. Entre os meus indicadores habituais contam-se:<\/p>\n<ul>\n  <li>Lat\u00eancia de commit (p50\/p95\/p99) durante os picos de carga<\/li>\n  <li>Lat\u00eancia e taxa de fsync para ficheiros de registo e de dados<\/li>\n  <li>Evolu\u00e7\u00e3o da percentagem de p\u00e1ginas com conte\u00fado impr\u00f3prio ao longo do tempo e a sua vari\u00e2ncia<\/li>\n  <li>Progresso do ponto de verifica\u00e7\u00e3o e rela\u00e7\u00e3o entre a taxa de grava\u00e7\u00e3o no registo e a taxa de esvaziamento<\/li>\n  <li>Atraso do Page Cleaner (h\u00e1 constantemente flushes pendentes?)<\/li>\n<\/ul>\n<p>Para tal, recorro \u00e0s sa\u00eddas de estado do InnoDB e correlaciono-as com m\u00e9tricas do sistema operativo (iostat, vmstat). Em particular, observo a lat\u00eancia do disco em milissegundos e a distribui\u00e7\u00e3o entre leituras e grava\u00e7\u00f5es, bem como a percentagem de opera\u00e7\u00f5es s\u00edncronas. Para garantir a reprodutibilidade dos testes, altero de forma seletiva apenas um par\u00e2metro por etapa e registo o resultado ao longo de intervalos mais prolongados, para que os valores at\u00edpicos n\u00e3o dominem os resultados.<\/p>\n\n<h2>Anti-padr\u00f5es frequentes e medidas corretivas<\/h2>\n\n<ul>\n  <li>Registos Redo demasiado pequenos: levam a pontos de verifica\u00e7\u00e3o frequentes. Medida corretiva: aumentar o tamanho dos registos e ajustar a capacidade de E\/S para o flushing.<\/li>\n  <li>A percentagem de p\u00e1ginas sujas est\u00e1 constantemente demasiado elevada: o Page-Cleaner est\u00e1 sobrecarregado e h\u00e1 risco de picos de flush. Medida corretiva: diminuir o valor de innodb_max_dirty_pages_pct e aumentar o valor de io_capacity.<\/li>\n  <li>O_DIRECT sem monitoriza\u00e7\u00e3o: embora evite o duplo armazenamento em cache, pode provocar picos de tr\u00e1fego se a capacidade de E\/S for incorreta. Medida correctiva: monitoriza\u00e7\u00e3o rigorosa e adapta\u00e7\u00e3o dos valores de capacidade aos IOPS reais.<\/li>\n  <li>Vizinhos de flush inadequados em SSD\/NVMe: geram trabalho adicional sem qualquer benef\u00edcio. Solu\u00e7\u00e3o: definir innodb_flush_neighbors=0.<\/li>\n  <li>Sincroniza\u00e7\u00f5es de commit em suportes lentos: cada transa\u00e7\u00e3o suporta o custo do fsync. Medida de preven\u00e7\u00e3o: promover o Group-Commit; se necess\u00e1rio, definir innodb_flush_log_at_trx_commit=2 (ap\u00f3s avaliar os riscos).<\/li>\n  <li>Container sem buffer de RAM: o buffer pool est\u00e1 demasiado grande, existe risco de OOM. Medida corretiva: ajustar rigorosamente o buffer pool aos limites do Cgroup e monitorizar a press\u00e3o.<\/li>\n<\/ul>\n\n<h2>Ter em conta os percursos de encerramento e recupera\u00e7\u00e3o<\/h2>\n\n<p>Estou a planear como as configura\u00e7\u00f5es afetam <strong>Desligamento<\/strong> e <strong>Recupera\u00e7\u00e3o ap\u00f3s falha<\/strong> ter impacto. Um encerramento r\u00e1pido e correto reduz os tempos de recupera\u00e7\u00e3o, uma vez que \u00e9 necess\u00e1rio aplicar menos redos. Registos de redo muito grandes favorecem checkpoints tranquilos, mas, em caso de erro, prolongam o processo de recupera\u00e7\u00e3o. Para sistemas produtivos, procuro encontrar um equil\u00edbrio de forma a, por um lado, n\u00e3o gerar picos de flush nas opera\u00e7\u00f5es di\u00e1rias e, por outro, n\u00e3o ter de aceitar uma recupera\u00e7\u00e3o excessivamente demorada no pior dos casos. Tenho em conta as janelas de manuten\u00e7\u00e3o e as c\u00f3pias de seguran\u00e7a desde o in\u00edcio.<\/p>\n\n<h2>Sugest\u00f5es pr\u00e1ticas para cargas de trabalho t\u00edpicas<\/h2>\n\n<ul>\n  <li>OLTP com muitos pequenos commits em SSD\/NVMe: O_DIRECT, innodb_flush_log_at_trx_commit=1 ou 2, dependendo da durabilidade, innodb_io_capacity relativamente elevado, Dirty-Pages moderado, Flush-Neighbors=0. Utilizar ativamente o Binlog Group Commit.<\/li>\n  <li>Importa\u00e7\u00e3o em lote com grande volume de escrita: aumentar temporariamente o valor do par\u00e2metro \u00abDirty Page Target\u00bb, aumentar a capacidade de E\/S e, ap\u00f3s a conclus\u00e3o, reverter as altera\u00e7\u00f5es. Se a durabilidade for aceit\u00e1vel, definir temporariamente \u00abinnodb_flush_log_at_trx_commit=2\u00bb.<\/li>\n  <li>Sistemas legados baseados em HDD: capacidade de E\/S conservadora, Flush-Neighbors=1, innodb_flush_method=fsync ou O_DIRECT, dependendo da press\u00e3o na RAM. Deve prestar-se especial aten\u00e7\u00e3o ao esvaziamento cont\u00ednuo, para evitar picos de acessos.<\/li>\n  <li>Volumes na nuvem com or\u00e7amento de IOPS: vincular o par\u00e2metro `innodb_io_capacity` estritamente ao limite garantido, evitar picos de tr\u00e1fego e utilizar `O_DIRECT` para poupar RAM. Em sistemas de cr\u00e9ditos (E\/S em picos), utilizo o `pacing` para que o or\u00e7amento n\u00e3o seja esgotado de forma repentina.<\/li>\n<\/ul>\n\n<h2>Lista de verifica\u00e7\u00e3o de resolu\u00e7\u00e3o de problemas<\/h2>\n\n<ul>\n  <li>Lat\u00eancias de commit do p95 prolongadas? Verifique a dura\u00e7\u00e3o do fsync, ative o Group-Commit e, se necess\u00e1rio, reduza a frequ\u00eancia de flush (avaliando os riscos).<\/li>\n  <li>Grande varia\u00e7\u00e3o na percentagem de p\u00e1ginas sujas? Ajustar com precis\u00e3o os par\u00e2metros io_capacity\/io_capacity_max e verificar os limiares de limpeza adaptativa.<\/li>\n  <li>Picos repentinos de lat\u00eancia durante as c\u00f3pias de seguran\u00e7a? Sincronize os par\u00e2metros da ferramenta de c\u00f3pia de seguran\u00e7a e os valores do servidor; ajuste temporariamente a limita\u00e7\u00e3o de E\/S.<\/li>\n  <li>A r\u00e9plica est\u00e1 a ficar para tr\u00e1s? Avaliar em conjunto a estrat\u00e9gia de limpeza do binlog, as frequ\u00eancias de sincroniza\u00e7\u00e3o e a lat\u00eancia da rede; sincroniza\u00e7\u00f5es demasiado agressivas abrandam o mestre.<\/li>\n  <li>Press\u00e3o na RAM ap\u00f3s a mudan\u00e7a para O_DIRECT? Reajustar o equil\u00edbrio entre o buffer pool e a cache do SO; o O_DIRECT reduz a cache do SO, mas pode afetar a cache de p\u00e1ginas da aplica\u00e7\u00e3o.<\/li>\n<\/ul>\n\n<h2>Breve resumo<\/h2>\n\n<p>Eu organizo a <strong>Estrat\u00e9gia de flush<\/strong> sempre em fun\u00e7\u00e3o do hardware e dos objetivos de durabilidade. O_DIRECT evita o duplo armazenamento em cache e, na maioria das vezes, proporciona os melhores resultados em SSD\/NVMe. O par\u00e2metro innodb_flush_log_at_trx_commit determina a velocidade por commit e o risco em caso de falha de energia. Valores bem selecionados para \u00abDirty Pages\u00bb, capacidade de E\/S e \u00abFlush-Neighbors\u00bb mant\u00eam as taxas de grava\u00e7\u00e3o est\u00e1veis. Quem, al\u00e9m disso, medir os custos do fsync e respeitar os limites da nuvem, consegue que o MariaDB atinja a velocidade desejada de forma fi\u00e1vel, sem sacrificar a seguran\u00e7a.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a configurar de forma otimizada os m\u00e9todos de flush do MariaDB e o innodb_flush com O_DIRECT, fsync e innodb_flush_log_at_trx_commit. Este guia apresenta-lhe t\u00e9cnicas pr\u00e1ticas de otimiza\u00e7\u00e3o de bases de dados para ambientes HDD, SSD e na nuvem, com foco no desempenho e na seguran\u00e7a dos dados.<\/p>","protected":false},"author":1,"featured_media":21532,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21539","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":"66","_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":"MariaDB Flush","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":"21532","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21539","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=21539"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21539\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21532"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21539"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21539"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21539"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}