Comprendre les threads du « Page Cleaner » de MariaDB : leur impact sur les performances

Nettoyeur de pages Dans MariaDB, les threads déterminent la manière dont InnoDB écrit les pages modifiées du pool de mémoire tampon sur le support de stockage, ce qui permet de lisser les temps de réponse en cas de charge d'écriture. Comprendre l'architecture actuelle, qui repose sur un seul thread de nettoyage, permet d'éviter les goulots d'étranglement dans le chemin d'écriture et de maintenir la base de données performances constantes.

Points centraux

• Architecture: Un thread de nettoyage vide les pages sales indépendamment des instances du pool de tampons.
• Versions: La variable innodb_page_cleaners a été supprimé à partir de MariaDB 10.6.
• Focus sur les LRU: Le choix du « flush » dépend de la fin de la LRU et de la progression du point de contrôle.
• Le mythe: Un nombre plus élevé de threads ne signifie pas automatiquement de meilleures performances.
• Cabinet médical: La taille du pool de mémoire tampon, la capacité d'E/S et les points de contrôle sont les principaux facteurs qui influencent le résultat.

Ce que fait exactement Page Cleaner

Le thread « Page Cleaner » écrit Sale Il récupère les pages du pool de mémoire tampon InnoDB avant que les opérations utilisateur ne soient enregistrées de manière définitive sur le support de stockage. Il dissocie ainsi les opérations d'écriture des requêtes et réduit sensiblement la variance des temps de réponse, notamment pendant les pics de charge. Je considère le « Cleaner » comme un régulateur de rythme : il découpe les écritures en petits morceaux adaptés, au lieu de traiter de grandes vagues de manière incontrôlée. Le thread puise dans les pages qui se retrouvent en fin de liste LRU, afin que le cache reste rapidement disponible pour les données fréquemment consultées. Parallèlement, il accélère le point de contrôle, de sorte qu’il ne reste pas trop de modifications non écrites en mémoire. Quiconque comprend ce processus reconnaît plus rapidement si E/S s'il s'agit d'un goulot d'étranglement ou si le problème résulte plutôt d'un cache trop petit et d'un nombre trop élevé de pages sales.

Version : De nombreux fils de discussion en un seul

Auparavant, il était possible de configurer plusieurs « cleaners », mais MariaDB 10.5.1 a marqué le début de la refonte et MariaDB 10.6 a supprimé innodb_page_cleaners définitivement. Depuis lors, un seul buf_flush_page_cleaner-Un seul thread gère le travail pour toutes les instances du pool de tampons. Cela réduit les coûts de coordination, simplifie le réglage et reflète le constat selon lequel un bon algorithme est plus important que la multiplicité des threads. Quiconque suit des instructions tirées d’articles sur MySQL ou d’anciens articles se heurte rapidement à des paramètres qui sont aujourd’hui sans effet. Je vérifie d’abord la version exacte de MariaDB avant de régler ce que je pense être des paramètres de réglage. J’évite ainsi de perdre du temps et je me concentre sur les paramètres qui ont un impact sur le Chemin d'écriture influencer réellement.

Pool de mémoire tampon, pages modifiées et LRU

Le pool de mémoire tampon conserve les données fréquemment utilisées en mémoire vive (RAM) et permet d'économiser des disque-accès. Dès que des transactions effectuent des écritures, des « pages sales » sont créées, qui n'existent dans un premier temps qu'en mémoire. Le « Cleaner » les enregistre en temps voulu afin que la LRU soit libérée et que les pages fréquemment lues restent en haut du cache. Je surveille le nombre d’instances du pool de tampons actives et la répartition des accès, car le parallélisme peut réduire les files d’attente. Ceux qui souhaitent approfondir le sujet trouveront des conseils pratiques sur Instances du pool de mémoire tampon, par exemple pour les hôtes multicœurs. Au final, le taux de pages sales indique si la fréquence de vidage suit le rythme d'écriture et si le cache remplit sa Résultats fournit.

Progression des points de contrôle et latence

Le point de contrôle place un marqueur indiquant jusqu'où les modifications sont enregistrées en toute sécurité sur le support de stockage, et le « Page Cleaner » fait avancer ce marqueur. Si le point de contrôle reste à la traîne, le taux d'utilisation du journal et l'amplification d'écriture augmentent, ce qui se traduit par une durée de validation plus longue et un pic de n lors des requêtes. Je vérifie régulièrement l’ampleur des fluctuations de la distance de point de contrôle et si le nettoyeur de pages génère des pics trop importants. Si le lissage échoue, des pics de charge risquent de se produire, entraînant le blocage des threads utilisateur. Pour une compréhension de base, il est utile de jeter un œil à Checkpointing et amplification d'écriture dans le domaine de l'hébergement. En consultant ces indicateurs, on peut rapidement déterminer si Flush- si le travail est effectué dans les délais ou si le système doit rattraper son retard à la hâte lors des phases ultérieures.

Idées reçues courantes sur le tuning

Beaucoup s'attendent à ce que des threads d'arrière-plan supplémentaires améliorent automatiquement le débit, mais ce n'est pas le cas ici. Ce qui reste déterminant, c'est la qualité de l'algorithme de vidage et le dosage approprié de E/S-Travail par intervalle. Un nettoyeur trop agressif génère de brèves pointes de charge qui font grimper les temps de réponse. Un nettoyeur trop timide accumule trop de pages sales, ce qui entraîne par la suite des vagues de vidage plus importantes. Dans les deux cas, on observe un effet d’accordéon au niveau des latences. Je vise donc un schéma régulier, adapté au sous-système de mémoire, et qui perturbe le moins possible les threads utilisateur. bloque.

Indicateurs et suivi : ce que je vérifie

Pour prendre des décisions, je me fie aux chiffres, pas à mon intuition. Je surveille le pourcentage de pages sales, la progression des points de contrôle, les taux d’écriture et de Fsync, ainsi que les temps d’attente sur le redo log et les fichiers de données. Si les temps de validation varient sous charge, je jette un œil aux files d’attente de vidage et à la taille des fichiers redo log. Le pourcentage de pages en fin de liste LRU donne également une indication sur la pression d’éviction et le besoin de flushing. Les pics d’IOPS indiquent que le nettoyeur écrit des paquets trop volumineux ou que la limite de stockage est atteinte. Ces indicateurs permettent de déterminer si le goulot d’étranglement réside plutôt dans la taille du cache, Mémoire- en matière de débit ou de stratégie de purge.

Configuration : choisir correctement les tailles et la capacité d'E/S

Les principaux paramètres à ajuster restent la taille du pool de mémoire tampon, la capacité d'E/S et la structure du journal. Un pool de tampons plus grand réduit la charge de lecture, mais ne doit pas pour autant laisser la proportion de pages sales augmenter sans limite. Les paramètres relatifs à la capacité d’E/S déterminent la quantité de données que le nettoyeur tente d’écrire par unité de temps. Des valeurs trop faibles entraînent des bouchons, tandis que des valeurs trop élevées génèrent des pics dans le profil de latence. J’adapte ces paramètres au système de stockage réel, plutôt que de me fier à des valeurs standard abstraites. Le tableau suivant résume les paramètres pertinents qui influencent le comportement du Flush- marquer le déroulement du processus.

Réglage/Format	Effet sur Page Cleaner	Remarque concernant MariaDB	Conseil pratique
innodb_buffer_pool_size	Influence la quantité de pages sales et la pression d'éviction	Un pool plus important nécessite une cadence de flush régulière	Utiliser la RAM, mais garder une réserve pour le système d'exploitation et Requête- Conserver le cache
innodb_io_capacity / innodb_io_capacity_max	Portée limitée des travaux de purge prévus	S'adapter aux IOPS réels des SSD/NVMe	Commencer par une valeur prudente, puis l'augmenter progressivement
innodb_flush_log_at_trx_commit	Contrôle la fréquence des opérations « commit-Fsync »	Ce choix influe sur la latence et la durée de conservation	„ 1 “ pour une durée de conservation maximale ; „ 2/0 “ pour une durée de conservation plus courte Latence
Taille du journal de reprise	Agit à distance des points de contrôle et contre les vagues de flush	Une taille trop petite oblige à créer des points de contrôle fréquents	Choisir une dimension plus grande pour lisser les pics d'écriture
innodb_page_cleaners (ancien)	Sans incidence aujourd'hui	Supprimé à partir de MariaDB 10.6	Ne plus toucher, se concentrer sur les activités Paramètres

Guide pratique : tester étape par étape

Je commence par établir une référence claire en charge avant de modifier les réglages. Ensuite, j'ajuste innodb_io_capacity par petites étapes et j'observe si les pics de latence se produisent moins fréquemment. Si des vagues de flush plus longues apparaissent, j'augmente la taille du redo log afin que le point de contrôle dispose de plus d'espace tampon. Ensuite, je vérifie si le pool de tampons dispose de suffisamment d’espace pour que les données « chaudes » ne soient pas évincées trop rapidement. Je laisse suffisamment de temps à chaque modification pour que ses effets et ses effets secondaires se manifestent clairement. Ce n’est que lorsque les indicateurs et l’expérience utilisateur s’améliorent conjointement que je coche la case Étape à partir de

Influence du tampon « doublewrite »

Le tampon Doublewrite protège les pages contre les écritures partielles et les blocs corrompus, mais il a également un impact sur le débit d'écriture et les schémas de vidage. C'est notamment lorsque la proportion de mises à jour est élevée qu'il peut influencer le débit perçu du nettoyeur. Les systèmes de stockage modernes dotés d’un ordre d’écriture persistant atténuent quelque peu ce phénomène, mais l’effet reste mesurable. Je vérifie donc la charge de travail, les attentes en matière d’intégrité des données et la latence acceptable avant de modifier ce paramètre. Si vous souhaitez en savoir plus, vous trouverez des informations complémentaires dans l’article consacré au tampon à double écriture. Cela permet de déterminer si la durée de vie et Protection Obtenir la priorité sur une latence minimale.

Symptômes courants et mesures à prendre

Si les temps de commit augmentent alors que le processeur est disponible, cela indique un engorgement au niveau du flush ou un stockage insuffisant. Des fluctuations importantes des IOPS suggèrent que les paquets de flush sont trop volumineux ; dans ce cas, je réduis la capacité d’E/S et j’augmente la taille du redo log. Si la proportion de pages sales reste durablement élevée, cela signifie que le nettoyeur fonctionne de manière trop défensive ou que le pool de tampons est trop petit. Si les pages fréquemment utilisées glissent rapidement vers la fin de la liste LRU, cela signifie qu’il manque de place dans le cache ou que la charge d’écriture sollicite trop fortement le pool. Dans les environnements d’hébergement, c’est souvent le stockage partagé qui ralentit le système ; dans ce cas, seule une mesure de la charge tout au long de la journée et, le cas échéant, le passage à des supports plus rapides peuvent aider. Je documente chaque modification afin d’identifier la cause et Effet rester sans ambiguïté par la suite.

Comment le nettoyeur établit ses priorités entre la liste Flush et la LRU

Lors de l'écriture, InnoDB distingue deux sources principales : la liste LRU (les pages qui doivent céder la place à de nouveaux accès) et la liste de vidage (toutes les pages sales, triées par numéro de séquence de journal le plus ancien). Le « Page Cleaner » assure l’équilibre entre ces deux objectifs : il nettoie la fin de la liste LRU pour éviter les évictions, tout en puisant en parallèle dans la liste de vidage afin de faire progresser le point de contrôle de manière constante. Si l’espace libre dans la mémoire tampon est sous pression, le vidage LRU est prioritaire ; en revanche, si la distance du point de contrôle augmente, le nettoyeur augmente la proportion prélevée dans la liste de vidage. Ce basculement explique pourquoi les profils de latence varient en fonction de l'évolution des charges de travail : si la pression en lecture augmente, les vidages LRU dominent ; si la pression en écriture augmente, le travail sur les points de contrôle domine. J'analyse ce schéma dans les données de surveillance pour déterminer s'il faut plutôt renforcer la capacité d'E/S ou la réserve de journaux de reprise.

Rinçage adaptatif : bien interpréter les seuils

MariaDB s'appuie sur le « flushing adaptatif » pour ajuster dynamiquement le taux d'écriture en fonction de la consommation de redo et du pourcentage de pages sales. Dans la pratique, je surveille trois paramètres : la valeur cible pour les pages sales, le seuil minimal et le taux d'écriture actuel. Si le taux de pages sales dépasse la valeur cible, le « cleaner » resserre la vis ; s’il tombe en dessous, il se montre plus prudent. Un seuil de « low-water mark » trop bas entraîne des déclenchements fréquents du vidage et peut générer des pics de latence courts mais perceptibles. Un seuil trop élevé laisse trop de données sales dans la mémoire, ce qui provoque par la suite des fluctuations plus importantes. J'ajuste les seuils de manière à ce qu'ils correspondent aux caractéristiques du système de stockage : les SSD NVMe rapides supportent des taux de vidage continus et modérément plus élevés ; les systèmes plus lents tirent profit de lots plus petits et plus réguliers.

Utiliser à bon escient les options spécifiques au stockage

Le Page Cleaner ne fonctionne pas en vase clos : le choix de la méthode de vidage et le comportement du système de fichiers influencent le résultat. Avec innodb_flush_method Je contrôle si InnoDB écrit les pages directement (O_DIRECT) ou via le cache du système d'exploitation. L'écriture directe évite la mise en cache double et stabilise les latences sous Linux avec XFS/EXT4. Les systèmes de fichiers tels que ZFS gèrent toutefois O_DIRECT différemment ; dans ce cas, je vérifie si une méthode synchronisée (fsync/O_DSYNC) qui offre un profil plus cohérent. Il est également intéressant de se pencher sur le « neighborhood flushing » (voisins alignés) : Sur les baies de disques durs, l'écriture simultanée de blocs adjacents peut s'avérer utile ; sur les SSD/NVMe, je la limite afin d'éviter une amplification d'écriture inutile. L’essentiel est que la configuration soit adaptée au support physique : le meilleur algorithme de nettoyage ne sert pas à grand-chose si le stockage sous-jacent est ralenti.

Le suivi dans la pratique : les requêtes qui m'aident

Pour avoir une vue d'ensemble rapide, j'utilise trois angles d'approche : les valeurs d'état globales, les métriques InnoDB et le dump périodique.

• Chiffres clés en bref : SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_pages_dirty%';, ... LIKE 'Innodb_os_log_written' ;, ... LIKE 'Innodb_log_waits' ;. Monter temps d'attente du journal, soit le fichier Redo-Log est trop petit, soit la commande « flush » est trop lente.
• Niveau de détail : SHOW ENGINE INNODB STATUS\G fournit les positions des points de contrôle (LSN), les longueurs des listes de vidage et des indications sur les goulots d'étranglement. Je compare le „ numéro de séquence du journal “ et le „ dernier point de contrôle “ pour estimer la distance entre les points de contrôle.
• Télémétrie plus précise : SELECT NAME, COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME LIKE 'buffer_%dirty%' ; ou ... LIKE 'log_%' ; met en évidence des tendances qui passent facilement inaperçues lors de tests rapides.

Ce qui importe, c'est la corrélation : si les latences de commit augmentent parallèlement à une hausse du taux Fsync, le paramètre « Cleaner » est probablement réglé trop strictement. Si le taux de pages sales et la distance entre les points de contrôle augmentent simultanément, cela indique un débit de vidage insuffisant ou une taille insuffisante du journal de reprise (Redo-Log).

Profils de charge de travail : OLTP, reporting, traitement en masse

En fonction de la charge de travail, j'adopte des approches différentes. Dans les environnements OLTP, je privilégie des lots de vidage réguliers et de petite taille ainsi qu'une bande de latence étroite ; dans ce cas, des paramètres modérés innodb_io_capacity et disposer d’un tampon Redo suffisant est essentiel. Pour les fenêtres de reporting ou d’ETL, j’accepte parfois des taux de vidage plus élevés, mais je veille à ce qu’ils ne se prolongent pas jusqu’aux pics d’activité des utilisateurs. Lors de chargements de données en masse, je privilégie des journaux de reprise plus volumineux et, si les exigences de persistance le permettent, une discipline Fsync temporairement assouplie (innodb_flush_log_at_trx_commit=2). Le Page Cleaner peut alors „ rattraper son retard “ en continu, sans ralentir les transactions des utilisateurs. Une fois l'opération terminée, je rétablis les valeurs plus strictes afin de garantir la stabilité des opérations quotidiennes.

Effets à long terme, « purge » et effets indirects

Même si le thread de purge poursuit d'autres objectifs (nettoyage des versions historiques), sa vitesse a une incidence sur la situation globale. Si les anciennes versions restent longtemps en mémoire, l'espace requis augmente et la charge de mémoire ainsi que la charge d'E/S sont réparties de manière moins optimale. Cela peut indirectement solliciter le Page Cleaner, car davantage de pages sont bloquées dans le pool et le LRU est plus rapidement mis sous pression. Je surveille donc de près les retards de purge et veille à ce qu’aucune transaction de longue durée ne „ bloque “ le système. Une progression stable de la purge, un nettoyeur fonctionnant en continu, un rythme d’écriture équilibré : ces trois rouages doivent s’engrener parfaitement.

Liste de contrôle pour le dépannage du chemin d'écriture

• La distance des points de contrôle est élevée et ne cesse d'augmenter ? Augmentez la taille du redo log et innodb_io_capacity soulever, puis vérifier à nouveau le tracé.
• Des pics d'IOPS et des pics de commits ? innodb_io_capacity réduire légèrement, lisser la taille des lots, tenir compte de l'effet de double écriture.
• Le pourcentage de pages sales reste-t-il élevé ? Augmentez la taille du pool de mémoire tampon ou resserrez le vidage adaptatif ; vérifiez la charge de travail sur les hotsets.
• Les temps d'attente « Log-Waits » sont-ils visibles ? Soit la taille de la mémoire Redo est insuffisante, soit le processus de vidage (Flush) est à la traîne. Commencez par augmenter la réserve Redo, puis affinez le débit du nettoyeur (Cleaner).
• La progression du LSN est irrégulière ? Les paquets « flush » sont incohérents. Modifiez les valeurs progressivement jusqu’à ce qu’une progression régulière soit visible.
• Des goulots d'étranglement au niveau du stockage ? Vérifiez la méthode de vidage, le planificateur et les paramètres de cache RAID/SAN ; privilégiez les IOPS durables plutôt que les pics d'IOPS comme indicateur de performance.

Exemple : étalonnage en trois étapes

Dans une instance OLTP à forte charge d'écriture, je commence par mesurer la charge dans la fenêtre de production. 1er cycle : je mesure les niveaux de remplissage du redo log et la distance de checkpoint. Le journal est souvent occupé à 70–80 %, la distance varie fortement – je double donc la taille du redo. 2e étape : après un nouveau test, les latences se stabilisent, mais des pics Fsync apparaissent occasionnellement. Je réduis innodb_io_capacity modérément, jusqu’à ce que la répartition des IOPS se stabilise. 3e tour : le taux de pages sales reste proche du plafond. J’alloue davantage de mémoire vive au pool de tampons, ce qui soulage le LRU et rend le travail du nettoyeur plus prévisible. Résultat : le Commit-P95 diminue sensiblement, la courbe des IOPS s'uniformise et le point de contrôle progresse de manière constante – exactement le schéma que je recherche.

En bref

Un seul thread de nettoyage gère le vidage des pages sales, assure la mise à jour continue du point de contrôle et protège les requêtes contre les pics d'écriture intenses. Les paramètres pertinents restent la taille du pool de tampons, la capacité d’E/S, la structure du redo log et les caractéristiques du système de stockage. Les paramètres obsolètes tels que innodb_page_cleaners Je ne tiens plus compte de ces éléments et je me concentre sur les indicateurs ayant une influence directe. En analysant des indicateurs tels que le taux de pages sales, l’intervalle entre les points de contrôle et la durée de validation, on identifie plus rapidement les goulots d’étranglement. Des modifications progressives, associées à une base de référence claire, fournissent des résultats fiables sans masquer les effets secondaires. Ainsi, le Page Cleaner fonctionne discrètement en arrière-plan, et la Temps de réponse reste constant, même sous charge.