{"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-page-cleaner-thread-database","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/mariadb-page-cleaner-threads-datenbank\/","title":{"rendered":"Capire i thread di MariaDB Page Cleaner: come influenzano le prestazioni"},"content":{"rendered":"<p><strong>Page Cleaner<\/strong> I thread in MariaDB controllano il modo in cui InnoDB scrive le pagine modificate dal buffer pool sul disco, livellando cos\u00ec i tempi di risposta sotto carico di scrittura. Chi comprende l'architettura attuale, caratterizzata da un unico thread di pulizia, evita i colli di bottiglia nel percorso di scrittura e mantiene la <strong>database<\/strong> prestazioni costanti.<\/p>\n\n<h2>Punti centrali<\/h2>\n\n<ul>\n  <li><strong>Architettura<\/strong>: Un thread di pulizia svuota le pagine sporche indipendentemente dalle istanze del buffer pool.<\/li>\n  <li><strong>Versioni<\/strong>: La variabile <code>innodb_page_cleaners<\/code> \u00c8 stato eliminato a partire da MariaDB 10.6.<\/li>\n  <li><strong>Focus LRU<\/strong>: La selezione dei flush si basa sulla fine dell'LRU e sull'avanzamento dei checkpoint.<\/li>\n  <li><strong>Mito<\/strong>: Un numero maggiore di thread non garantisce automaticamente prestazioni migliori.<\/li>\n  <li><strong>Pratica<\/strong>: Le dimensioni del buffer pool, la capacit\u00e0 di I\/O e il checkpointing influenzano in modo determinante il risultato.<\/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>Cosa fa esattamente Page Cleaner<\/h2>\n\n<p>Il thread \"Page Cleaner\" riporta <strong>Sporco<\/strong> Recupera le pagine dal buffer pool di InnoDB prima che le operazioni degli utenti vengano registrate in modo definitivo sul supporto di memorizzazione. In questo modo disaccoppia le operazioni di scrittura dalle query e riduce sensibilmente la varianza dei tempi di risposta, soprattutto durante i picchi di carico. Considero il Cleaner come un regolatore di ritmo: suddivide le operazioni di scrittura in porzioni adeguate, invece di elaborare grandi ondate in modo incontrollato. Il thread attinge alle pagine che finiscono in fondo alla lista LRU, in modo che la cache rimanga rapidamente libera per i dati pi\u00f9 richiesti. Allo stesso tempo, accelera il checkpoint, in modo che non rimangano troppe modifiche non salvate in memoria. Chi comprende questo processo, capisce pi\u00f9 rapidamente se <strong>I\/O<\/strong> se il collo di bottiglia sia proprio quello o se il rallentamento derivi piuttosto da una cache troppo piccola e da un numero eccessivo di pagine sporche.<\/p>\n\n<h2>Stato della versione: da molte discussioni a una sola<\/h2>\n\n<p>In passato era possibile configurare pi\u00f9 \u201ccleaner\u201d, ma MariaDB 10.5.1 ha avviato la riorganizzazione e MariaDB 10.6 ha rimosso <strong>innodb_page_cleaners<\/strong> definitivamente. Da allora se ne occupa un solo <code>buf_flush_page_cleaner<\/code>-Un unico thread gestisce il lavoro per tutte le istanze del buffer pool. Ci\u00f2 riduce i costi di coordinamento, semplifica l\u2019ottimizzazione e riflette la consapevolezza che un buon algoritmo \u00e8 pi\u00f9 importante della molteplicit\u00e0 dei thread. Chi segue le istruzioni tratte da articoli su MySQL o da fonti obsolete si imbatte rapidamente in parametri che oggi sono inefficaci. Io verifico innanzitutto la versione esatta di MariaDB prima di intervenire su presunte impostazioni. In questo modo evito perdite di tempo e mi concentro sulle variabili che influenzano il <strong>Percorso di scrittura<\/strong> influenzare davvero.<\/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>Pool di buffer, pagine sporche e LRU<\/h2>\n\n<p>Il buffer pool mantiene i dati pi\u00f9 utilizzati nella RAM e consente di risparmiare costose <strong>Disco<\/strong>-Accessi. Non appena le transazioni effettuano operazioni di scrittura, si generano le \u201cDirty Pages\u201d, che inizialmente esistono solo in memoria. Il Cleaner le scrive tempestivamente, in modo che la LRU venga liberata e le pagine lette di frequente rimangano in cima alla cache. Presto attenzione a quante istanze del buffer pool sono attive e a come si distribuiscono gli accessi, poich\u00e9 il parallelismo pu\u00f2 alleggerire le code. Chi desidera approfondire l\u2019argomento trover\u00e0 consigli pratici su <a href=\"https:\/\/webhosting.de\/it\/mariadb-buffer-pool-istanze-sistemi-multicore-ottimizzazione-delle-prestazioni-database\/\">Istanze del buffer pool<\/a>, ad esempio per gli host multicore. Alla fine, la percentuale di pagine sporche indica se la frequenza di svuotamento tiene il passo con la velocit\u00e0 di scrittura e se la cache svolge la sua <strong>Colpi<\/strong> forniture.<\/p>\n\n<h2>Progresso del checkpoint e latenza<\/h2>\n\n<p>Il checkpoint imposta un indicatore che segna il punto fino al quale le modifiche sono salvate in modo sicuro sul supporto dati, mentre il Page Cleaner sposta in avanti tale indicatore. Se il checkpoint rimane indietro, il livello di utilizzo del log e l\u2019amplificazione di scrittura aumentano, il che si riflette nella durata del commit e nel valore di n di picco durante le query. Controllo regolarmente l\u2019entit\u00e0 delle fluttuazioni della distanza del checkpoint e se il Cleaner genera oscillazioni troppo ampie. Se la livellatura non riesce, si rischia di incorrere in picchi di traffico in cui i thread degli utenti vengono bloccati. Per una comprensione di base, \u00e8 utile dare un\u2019occhiata a <a href=\"https:\/\/webhosting.de\/it\/database-checkpointing-write-amplification-hosting-guide-scaling\/\">Checkpointing e amplificazione di scrittura<\/a> nel contesto dell'hosting. Chi legge questi indicatori si rende subito conto se <strong>A filo<\/strong>-il lavoro venga portato a termine in tempo o se il sistema debba poi recuperare freneticamente nelle fasi successive.<\/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>Malintesi comuni nel tuning<\/h2>\n\n<p>Molti si aspettano che l'aggiunta di thread in background garantisca automaticamente un maggiore throughput, ma in questo caso non \u00e8 cos\u00ec. Ci\u00f2 che conta davvero \u00e8 la qualit\u00e0 dell'algoritmo di flush e il giusto dosaggio di <strong>I\/O<\/strong>-Lavoro per intervallo. Un cleaner troppo aggressivo genera brevi picchi di carico che fanno aumentare i tempi di risposta. Un cleaner troppo blando accumula troppe pagine sporche, causando in seguito ondate di flush pi\u00f9 consistenti. Entrambe le situazioni danno la sensazione di un effetto fisarmonica sulle latenze. Il mio obiettivo \u00e8 quindi quello di ottenere un andamento uniforme che si adatti al sottosistema di memoria e che influisca il meno possibile sui thread degli utenti <strong>bloccato<\/strong>.<\/p>\n\n<h2>Metriche e monitoraggio: cosa controllo<\/h2>\n\n<p>Per prendere decisioni mi affido ai numeri, non all'istinto. Osservo la percentuale di pagine sporche, lo stato di avanzamento dei checkpoint, i tassi di scrittura e di Fsync, nonch\u00e9 i tempi di attesa sui file di redo log e sui file di dati. Se i tempi di commit variano sotto carico, do un'occhiata ai backlog di flush e alle dimensioni dei file di redo log. Anche la percentuale di pagine alla fine della lista LRU fornisce indicazioni sulla pressione di espulsione e sulla necessit\u00e0 di operazioni di flush. I valori anomali degli IOPS indicano che il cleaner sta scrivendo pacchetti troppo grandi o che \u00e8 stato raggiunto il limite di spazio di archiviazione. Questi parametri rivelano se il collo di bottiglia \u00e8 piuttosto la dimensione della cache, <strong>Memoria<\/strong>- Riguarda la portata o la strategia di lavaggio.<\/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>Configurazione: scegliere correttamente le dimensioni e la capacit\u00e0 I\/O<\/h2>\n\n<p>I parametri di regolazione pi\u00f9 importanti rimangono la dimensione del buffer pool, la capacit\u00e0 di I\/O e il layout del log. Un buffer pool pi\u00f9 grande riduce la pressione di lettura, ma non deve far crescere senza freni la percentuale di pagine sporche. I parametri relativi alla capacit\u00e0 di I\/O controllano la quantit\u00e0 di dati che il cleaner cerca di scrivere in un'unit\u00e0 di tempo. Valori troppo bassi causano un accumulo di dati in coda, mentre valori troppo alti generano picchi nel profilo di latenza. Adatto queste dimensioni al sistema di archiviazione reale, invece di affidarmi a valori standard astratti. La tabella seguente riassume le impostazioni rilevanti che influenzano il comportamento del <strong>A filo<\/strong>-processo.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Impostazione\/Aspetto<\/th>\n      <th>Effetto su Page Cleaner<\/th>\n      <th>Nota per MariaDB<\/th>\n      <th>Indicazione pratica<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><code>innodb_buffer_pool_size<\/code><\/td>\n      <td>Influisce sulla quantit\u00e0 di pagine sporche e sulla pressione di espulsione<\/td>\n      <td>Una pool pi\u00f9 grande richiede una cadenza di flush costante<\/td>\n      <td>Utilizzare la RAM, ma lasciare una riserva per il sistema operativo e <strong>Query<\/strong>-Lasciare la cache<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_io_capacity<\/code> \/ <code>innodb_io_capacity_max<\/code><\/td>\n      <td>Entit\u00e0 limitata dei lavori di lavaggio previsti<\/td>\n      <td>Adattare agli IOPS effettivi degli SSD\/NVMe<\/td>\n      <td>Iniziare con un valore prudente, poi aumentarlo gradualmente<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_flush_log_at_trx_commit<\/code><\/td>\n      <td>Controlla la frequenza di Commit-Fsync<\/td>\n      <td>La scelta influisce sulla latenza e sulla durata<\/td>\n      <td>\u201e1\u201c per la massima durata; \u201e2\/0\u201c per una durata inferiore <strong>Latenza<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Dimensione del log di redo<\/td>\n      <td>Agisce sulle onde di distanza e di flush del checkpoint<\/td>\n      <td>Se \u00e8 troppo piccolo, si rendono necessari frequenti checkpoint<\/td>\n      <td>Aumentare le dimensioni per livellare i picchi di scrittura<\/td>\n    <\/tr>\n    <tr>\n      <td><code>innodb_page_cleaners<\/code> (vecchio)<\/td>\n      <td>Oggi senza alcuna influenza<\/td>\n      <td>Rimosso a partire da MariaDB 10.6<\/td>\n      <td>Non toccarlo pi\u00f9, concentrati sulle attivit\u00e0 <strong>Parametri<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Guida pratica: testare passo dopo passo<\/h2>\n\n<p>Inizio con una linea di base chiara sotto carico, prima di modificare le impostazioni. Dopodich\u00e9 regolo <code>innodb_io_capacity<\/code> A piccoli passi, osservo se i picchi di latenza si verificano meno frequentemente. Se si manifestano ondate di flush pi\u00f9 lunghe, aumento la dimensione del redo log, in modo che il checkpoint disponga di maggiore spazio di buffer. Successivamente, verifico se il buffer pool disponga di spazio sufficiente affinch\u00e9 i dati pi\u00f9 utilizzati non vengano sostituiti troppo rapidamente. A ogni modifica viene concesso tempo sufficiente affinch\u00e9 gli effetti positivi e gli effetti collaterali si manifestino chiaramente. Solo quando gli indicatori chiave e l\u2019esperienza utente migliorano complessivamente, spunto la casella <strong>Passo<\/strong> da.<\/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>Influenza del buffer Doublewrite<\/h2>\n\n<p>Il buffer Doublewrite protegge le pagine da scritture parziali e blocchi corrotti, ma allo stesso tempo influisce sulla velocit\u00e0 di scrittura e sui modelli di flush. Soprattutto in presenza di un\u2019elevata percentuale di aggiornamenti, pu\u00f2 influire sulla larghezza di banda percepita del cleaner. I moderni sistemi di archiviazione con sequenza di scrittura persistente attenuano in parte questo effetto, ma esso rimane comunque misurabile. Pertanto, prima di intervenire su questo parametro, verifico il carico di lavoro, le aspettative di integrit\u00e0 dei dati e la latenza accettabile. Chi desidera maggiori dettagli al riguardo pu\u00f2 trovare ulteriori approfondimenti nell\u2019articolo su <a href=\"https:\/\/webhosting.de\/it\/innodb-buffer-di-doppia-scrittura-sicurezza-ottimizzazione-delle-prestazioni-focus\/\">Buffer a doppia scrittura<\/a>. In questo modo \u00e8 possibile stabilire se la durata e <strong>Protezione<\/strong> Ottenere la priorit\u00e0 rispetto alla latenza minima.<\/p>\n\n<h2>Sintomi comuni e misure da adottare<\/h2>\n\n<p>Se i tempi di commit aumentano nonostante la CPU sia libera, ci\u00f2 indica un ingorgo nel flush o uno storage poco performante. Elevate oscillazioni negli IOPS indicano pacchetti di flush troppo grandi; in tal caso, riduco la capacit\u00e0 di I\/O e aumento il redo log. Se la percentuale di pagine sporche rimane costantemente alta, significa che il cleaner opera in modo troppo difensivo oppure che il buffer pool \u00e8 troppo piccolo. Se le pagine pi\u00f9 utilizzate scivolano rapidamente verso la fine della lista LRU, significa che manca spazio nella cache oppure che il carico di scrittura sta sovraccaricando eccessivamente il pool. Negli ambienti di hosting, spesso \u00e8 lo storage condiviso a rallentare il sistema; in questo caso l\u2019unica soluzione \u00e8 misurare il carico nel corso della giornata e, se necessario, passare a supporti pi\u00f9 veloci. Documento ogni modifica, in modo che la causa e <strong>Effetto<\/strong> rimanga chiaro anche in seguito.<\/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>Come il Cleaner stabilisce le priorit\u00e0 tra la Flush-List e la LRU<\/h2>\n<p>Durante la scrittura, InnoDB distingue tra due fonti principali: la lista LRU (pagine che devono fare spazio a nuovi accessi) e la lista di flush (tutte le pagine sporche, ordinate in base al numero di sequenza del log pi\u00f9 vecchio). Il Page Cleaner bilancia questi due obiettivi: ripulisce la parte finale della lista LRU per evitare l'eviction e, parallelamente, preleva dalla lista di flush per far avanzare costantemente il checkpoint. Se lo spazio libero nel buffer \u00e8 sotto pressione, ha priorit\u00e0 l'LRU-Flush; se invece la distanza del checkpoint aumenta, il Cleaner aumenta la quota prelevata dalla Flush List. Questo cambiamento spiega perch\u00e9 i profili di latenza variano al variare dei carichi di lavoro: se aumenta la pressione di lettura, prevalgono gli LRU-Flush; se aumenta la pressione di scrittura, prevale il lavoro sul checkpoint. Analizzo questo andamento nel monitoraggio per decidere se devo ottimizzare maggiormente la capacit\u00e0 di I\/O o la riserva del redo log.<\/p>\n\n<h2>Flushing adattivo: interpretare correttamente i valori soglia<\/h2>\n<p>MariaDB si avvale del flushing adattivo per adeguare dinamicamente la velocit\u00e0 di scrittura al consumo di redo e alla percentuale di pagine sporche. In pratica, tengo d\u2019occhio tre parametri: il valore target per le pagine sporche, il livello minimo (low-water mark) e la velocit\u00e0 di scrittura attuale. Se la percentuale di pagine sporche supera il valore target, il Cleaner stringe le redini; se scende al di sotto, diventa pi\u00f9 cauto. Un livello minimo troppo basso porta ad avvii frequenti del flushing e pu\u00f2 generare picchi di latenza brevi ma percepibili. Una soglia troppo alta lascia troppi dati sporchi nella memoria, il che in seguito produce onde pi\u00f9 grandi. Regolo le soglie in modo che corrispondano alle caratteristiche del sistema di memoria: gli SSD NVMe veloci sopportano frequenze di flush continue e moderatamente pi\u00f9 elevate; i sistemi pi\u00f9 lenti traggono vantaggio da batch pi\u00f9 piccoli e regolari.<\/p>\n\n<h2>Utilizzare in modo mirato le opzioni specifiche per lo storage<\/h2>\n<p>Page Cleaner non opera nel vuoto: la scelta del metodo di flush e il comportamento del file system influenzano il risultato. Con <code>innodb_flush_method<\/code> Posso decidere se InnoDB scriva le pagine direttamente (O_DIRECT) o tramite la cache del sistema operativo. La scrittura diretta evita il doppio caching e stabilizza le latenze su Linux con XFS\/EXT4. Tuttavia, i file system come ZFS gestiscono O_DIRECT in modo diverso; in quel caso verifico se \u00e8 possibile utilizzare un metodo sincronizzato (<em>fsync<\/em>\/<em>O_DSYNC<\/em>) che offre il profilo pi\u00f9 coerente. Inoltre, vale la pena dare un\u2019occhiata al \u201cneighborhood flushing\u201d (<em>vicini flush<\/em>): Sugli array HDD pu\u00f2 essere utile la scrittura simultanea di blocchi adiacenti, mentre su SSD\/NVMe la riduco per evitare un\u2019amplificazione di scrittura superflua. \u00c8 fondamentale che la configurazione sia adeguata al supporto fisico: anche il miglior algoritmo di pulizia serve a poco se lo storage sottostante viene rallentato.<\/p>\n\n<h2>Il monitoraggio nella pratica: le domande che mi aiutano<\/h2>\n<p>Per avere una rapida panoramica, utilizzo tre punti di vista: i valori di stato globali, le metriche InnoDB e il dump periodico.<\/p>\n<ul>\n  <li>Dati chiave in sintesi: <code>SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';<\/code>, <code>... LIKE 'Innodb_os_log_written';<\/code>, <code>... LIKE 'Innodb_log_waits';<\/code>. Salire <em>attese di log<\/em>, il log di redo \u00e8 troppo piccolo oppure il comando flush \u00e8 troppo lento.<\/li>\n  <li>Livello di dettaglio: <code>SHOW ENGINE INNODB STATUS\\G<\/code> fornisce le posizioni dei checkpoint (LSN), le lunghezze delle liste di flush e indicazioni sui colli di bottiglia. Confronto il \u201eLog sequence number\u201c e il \u201eLast checkpoint at\u201c per stimare la distanza tra i checkpoint.<\/li>\n  <li>Telemetria pi\u00f9 precisa: <code>SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%';<\/code> oppure <code>... LIKE 'log_%';<\/code> mette in evidenza tendenze che nei test brevi possono facilmente sfuggire.<\/li>\n<\/ul>\n<p>La correlazione \u00e8 importante: se le latenze di commit aumentano in concomitanza con un aumento della frequenza Fsync, \u00e8 probabile che il cleaner sia impostato su un valore troppo basso. Se la percentuale di pagine sporche e la distanza tra i checkpoint aumentano contemporaneamente, significa che la velocit\u00e0 di flush \u00e8 insufficiente oppure che lo spazio del redo log \u00e8 insufficiente.<\/p>\n\n<h2>Profili di carico di lavoro: OLTP, reporting, elaborazione in blocco<\/h2>\n<p>A seconda del carico di lavoro, metto l'accento su aspetti diversi. Negli ambienti OLTP punto a batch di flush costanti e di piccole dimensioni e a una banda di latenza ridotta \u2013 in questo caso sono impostati in modo moderato <code>innodb_io_capacity<\/code> e un buffer redo sufficiente sono fondamentali. Per le finestre di reporting o ETL tollero temporaneamente frequenze di flush pi\u00f9 elevate, ma faccio attenzione che non si protraggano fino ai picchi di utenza. In caso di caricamento massivo di dati, preferisco log redo pi\u00f9 grandi e \u2013 se i requisiti di durabilit\u00e0 lo consentono \u2013 una disciplina Fsync temporaneamente ridotta (<code>innodb_flush_log_at_trx_commit=2<\/code>). Il Page Cleaner pu\u00f2 quindi continuare a \u201erecuperare il ritardo\u201c senza rallentare le transazioni degli utenti. Una volta completata l\u2019operazione, ripristino i valori pi\u00f9 rigorosi affinch\u00e9 l\u2019attivit\u00e0 quotidiana rimanga stabile.<\/p>\n\n<h2>Sciatori di fondo, Purge ed effetti indiretti<\/h2>\n<p>Anche se il thread di purge persegue altri obiettivi (la pulizia delle versioni storiche), la sua velocit\u00e0 influisce sul quadro generale. Se le vecchie versioni rimangono in memoria a lungo, aumenta lo spazio necessario e il carico di memoria e I\/O si distribuisce in modo meno efficiente. Ci\u00f2 pu\u00f2 sovraccaricare indirettamente il Page Cleaner, poich\u00e9 pi\u00f9 pagine rimangono vincolate nel pool e l\u2019LRU viene messo sotto pressione pi\u00f9 rapidamente. Per questo motivo tengo d\u2019occhio i ritardi di purge e mi assicuro che nessuna transazione di lunga durata \u201eblocchi\u201c il sistema. Progresso stabile della purge, Cleaner continuo, cadenza di scrittura equilibrata: questi tre ingranaggi devono incastrarsi perfettamente.<\/p>\n\n<h2>Lista di controllo per la ricerca dei guasti nel percorso di scrittura<\/h2>\n<ul>\n  <li>Distanza dal checkpoint elevata e in aumento? Aumentare la dimensione del redo log e <code>innodb_io_capacity<\/code> sollevare, quindi ricontrollare il percorso.<\/li>\n  <li>Picchi di IOPS e picchi di commit? <code>innodb_io_capacity<\/code> ridurre leggermente, uniformare la dimensione del batch, tenere conto dell'effetto \"doublewrite\".<\/li>\n  <li>La percentuale di pagine sporche rimane costantemente elevata? Aumentare la dimensione del buffer pool o impostare un flushing adattivo pi\u00f9 rigoroso; verificare il carico di lavoro sugli hotset.<\/li>\n  <li>I tempi di attesa del log sono visibili? O la riserva di redo \u00e8 troppo piccola oppure il flush \u00e8 in ritardo. Aumentare prima la riserva di redo, poi regolare con precisione la velocit\u00e0 di elaborazione del cleaner.<\/li>\n  <li>Progresso LSN instabile? I pacchetti flush sono incoerenti. Modificare i valori gradualmente fino a quando non si osserva un progresso regolare.<\/li>\n  <li>Colli di bottiglia legati allo storage? Verificare il metodo di flush, lo scheduler e le impostazioni della cache RAID\/SAN; utilizzare come parametro di riferimento gli IOPS sostenibili anzich\u00e9 quelli di picco.<\/li>\n<\/ul>\n\n<h2>Esempio: calibrazione in tre fasi<\/h2>\n<p>In un'istanza OLTP con elevato carico di scrittura, inizio con una misurazione del carico nella finestra di produzione. Fase 1: misuro i livelli di riempimento del redo log e la distanza di checkpoint. Il log \u00e8 spesso occupato al 70\u201380% in %, la distanza oscilla notevolmente \u2013 quindi raddoppio la dimensione del redo. Fase 2: dopo un nuovo test, le latenze si stabilizzano, ma occasionalmente si verificano picchi di Fsync. Riduco <code>innodb_io_capacity<\/code> moderato, finch\u00e9 la distribuzione degli IOPS non si stabilizza. Round 3: la percentuale di pagine sporche rimane al limite superiore. Assegno pi\u00f9 RAM al buffer pool, il che alleggerisce il carico sull\u2019LRU e rende pi\u00f9 prevedibile il lavoro del cleaner. Risultato: il Commit-P95 diminuisce sensibilmente, la curva degli IOPS diventa pi\u00f9 uniforme e il checkpoint procede in modo costante \u2013 esattamente il modello a cui aspiro.<\/p>\n\n<h2>Riassumendo brevemente<\/h2>\n\n<p>Un singolo thread di pulizia gestisce lo svuotamento delle pagine sporche, mantiene attivo il checkpoint e protegge le query dai picchi di scrittura intensi. I parametri rilevanti rimangono la dimensione del buffer pool, la capacit\u00e0 di I\/O, il layout del redo log e le caratteristiche del sistema di memoria. Parametri obsoleti come <strong>innodb_page_cleaners<\/strong> Non ne tengo pi\u00f9 conto e mi concentro sugli indicatori che hanno un impatto diretto. Chi analizza metriche quali la percentuale di pagine sporche, l\u2019intervallo tra i checkpoint e la durata del commit individua pi\u00f9 rapidamente i colli di bottiglia. Modifiche graduali con una baseline chiara forniscono risultati affidabili, senza nascondere effetti collaterali. In questo modo, il Page Cleaner opera silenziosamente in background e il <strong>Tempo di risposta<\/strong> rimane costante, anche sotto carico.<\/p>","protected":false},"excerpt":{"rendered":"<p>Spiegazione dei thread del Page Cleaner di MariaDB: il Page Cleaner di MariaDB InnoDB influisce sulle pagine sporche e sulle prestazioni del database.<\/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":"105","_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\/it\/wp-json\/wp\/v2\/posts\/21467","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21467"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21467\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21460"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21467"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21467"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21467"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}