{"id":20548,"date":"2026-08-11T15:09:51","date_gmt":"2026-08-11T13:09:51","guid":{"rendered":"https:\/\/webhosting.de\/writeback-cache-linux-kernel-cache\/"},"modified":"2026-08-11T15:09:51","modified_gmt":"2026-08-11T13:09:51","slug":"cache-de-reecriture-cache-du-noyau-linux","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/writeback-cache-linux-kernel-cache\/","title":{"rendered":"Comprendre le cache de r\u00e9\u00e9criture et les pages sales dans le noyau Linux"},"content":{"rendered":"<p>Le cache de r\u00e9\u00e9criture (Writeback Cache) du noyau Linux contr\u00f4le le moment o\u00f9 les donn\u00e9es modifi\u00e9es sont enregistr\u00e9es en tant que <strong>Pages sales<\/strong> restent en m\u00e9moire vive (RAM) et \u00e0 quel moment le noyau les \u00e9crit par lots sur le support de stockage. Je vais vous expliquer comment ce processus <strong>Performance<\/strong>, les latences et la s\u00e9curit\u00e9 des donn\u00e9es, et quels sont les param\u00e8tres qui comptent vraiment au quotidien.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Pages sales<\/strong> marquent les pages modifi\u00e9es en m\u00e9moire vive (RAM) qui ne sont pas encore enregistr\u00e9es sur le support de donn\u00e9es.<\/li>\n  <li><strong>Writeback<\/strong> regroupe les modifications et les enregistre efficacement par blocs plus importants.<\/li>\n  <li><strong>Valeurs seuils<\/strong> Tout comme vm.dirty_ratio, ces param\u00e8tres r\u00e9gulent la vitesse et la limitation.<\/li>\n  <li><strong>Synchronisation<\/strong> L'utilisation de fsync\/Flush permet d'\u00e9viter toute perte de donn\u00e9es.<\/li>\n  <li><strong>Suivi<\/strong> La section \/proc et les outils affichent la charge et les temps de latence.<\/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\/08\/linuxserver-writeback-3901.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fonctionnement du cache de pages<\/h2>\n\n<p>Je lis un fichier, le noyau place les donn\u00e9es dans le cache de pages, et les acc\u00e8s ult\u00e9rieurs s'effectuent \u00e0 partir du <strong>M\u00e9moire<\/strong> plut\u00f4t que depuis le disque. Lors de l'\u00e9criture, le syst\u00e8me marque les pages modifi\u00e9es comme <strong>Sale<\/strong> et acquitte souvent imm\u00e9diatement l'appel afin que l'application continue de fonctionner. Ce d\u00e9couplage r\u00e9duit les temps d'attente, car les acc\u00e8s E\/S lents ne ralentissent pas directement chaque application. Le cache met \u00e9galement \u00e0 disposition les blocs fr\u00e9quemment utilis\u00e9s et augmente le taux de r\u00e9ussite lors d'acc\u00e8s ult\u00e9rieurs. Si vous souhaitez approfondir le sujet, vous trouverez des informations compl\u00e9mentaires dans mon aper\u00e7u sur <a href=\"https:\/\/webhosting.de\/fr\/systeme-de-fichiers-mise-en-cache-linux-cache-de-page-cacheboost\/\">Mise en cache du syst\u00e8me de fichiers<\/a>, qui met en \u00e9vidence le r\u00f4le des chemins de lecture et d'\u00e9criture dans la vie quotidienne.<\/p>\n\n<h2>\u00ab Dirty Pages \u00bb : signification et cons\u00e9quences<\/h2>\n\n<p>Les \u00ab Dirty Pages \u00bb sont des pages m\u00e9moire modifi\u00e9es qui n'ont pas encore \u00e9t\u00e9 sauvegard\u00e9es de mani\u00e8re permanente et qui ne sont donc disponibles que dans le <strong>RAM<\/strong> existent. Tant qu'ils sont sales, je porte une certaine <strong>Risque<\/strong>: Une coupure de courant pourrait annuler ces modifications. N\u00e9anmoins, cela permet d'obtenir un taux d'\u00e9criture plus \u00e9lev\u00e9, car le noyau regroupe de nombreuses petites mises \u00e0 jour. Si la proportion de pages sales augmente, la pression sur les modules de r\u00e9\u00e9criture s'accro\u00eet. Le syst\u00e8me peut alors lib\u00e9rer de la m\u00e9moire en \u00e9crivant les pages concern\u00e9es sur le disque en leur accordant la priorit\u00e9.<\/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\/08\/linux_kernel_meeting_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9int\u00e9gration : d\u00e9clencheurs et d\u00e9roulement<\/h2>\n\n<p>La r\u00e9initialisation s'effectue de mani\u00e8re programm\u00e9e, en fonction d'un \u00e9v\u00e9nement ou sur demande <strong>Apps<\/strong>. Le noyau regroupe les pages sales, forme des s\u00e9quences d'E\/S appropri\u00e9es et les transmet via la couche de blocs vers le <strong>p\u00e9riph\u00e9rique de stockage<\/strong>. En cours de route, les syst\u00e8mes de fichiers, les m\u00e9canismes de r\u00e9cup\u00e9ration d'espace et les planificateurs d'E\/S interviennent pour contr\u00f4ler l'ordre et la taille des op\u00e9rations. Les appels de synchronisation tels que fsync garantissent que certaines donn\u00e9es soient correctement enregistr\u00e9es sur le support avant de poursuivre l'op\u00e9ration. Pendant les phases d'activit\u00e9 intense, j'observe dans les statistiques une part croissante de r\u00e9\u00e9criture diff\u00e9r\u00e9e, qui redescend apr\u00e8s le vidage.<\/p>\n\n<h2>M\u00e9canismes internes : balance_dirty_pages, BDI et Writeback-Worker<\/h2>\n\n<p>En coulisses, plusieurs composants s'imbriquent les uns dans les autres. Les threads d'\u00e9criture parcourent <strong>balance_dirty_pages()<\/strong>, qui tient compte de la charge \u00ab dirty \u00bb actuelle, de la vitesse du p\u00e9riph\u00e9rique et des limites d\u00e9finies. Il r\u00e9gule le d\u00e9bit d'\u00e9criture des processus (throttling) afin que la r\u00e9\u00e9criture en arri\u00e8re-plan puisse suivre. Chaque <strong>Dispositif de soutien<\/strong>-Contexte (bdi) \u2013 g\u00e9n\u00e9ralement un p\u00e9riph\u00e9rique bloc ou un backend de syst\u00e8me de fichiers \u2013 dispose de ses propres files d'attente de travail avec <strong>Fils de discussion \u00ab Flusher \u00bb<\/strong>, qui transforment les \u00ab Dirty Pages \u00bb en requ\u00eates d'E\/S ordonn\u00e9es. Cette r\u00e9partition emp\u00eache un p\u00e9riph\u00e9rique lent de ralentir tous les autres et am\u00e9liore l'\u00e9quit\u00e9 entre les charges de travail.<\/p>\n\n<p>La limitation est adaptative : lorsque je d\u00e9tecte des op\u00e9rations d'\u00e9criture plus rapides ou des blocs contigus plus volumineux, les quantit\u00e9s de donn\u00e9es \u00ab sales \u00bb autoris\u00e9es augmentent temporairement. En cas d'engorgements, de latences \u00e9lev\u00e9es ou de files d'attente satur\u00e9es, le noyau freine plus agressivement et impose des pauses aux \u00e9crivains jusqu'\u00e0 ce que le tampon soit \u00e0 nouveau d\u00e9gag\u00e9. C'est pr\u00e9cis\u00e9ment cette interaction qui explique pourquoi de l\u00e9g\u00e8res modifications des param\u00e8tres peuvent entra\u00eener des profils de latence sensiblement diff\u00e9rents.<\/p>\n\n<h2>Seuils : vm.dirty_background_ratio et vm.dirty_ratio<\/h2>\n\n<p>Je contr\u00f4le ce comportement \u00e0 l'aide de deux limites importantes qui r\u00e9gulent la proportion de pages pollu\u00e9es par rapport au <strong>RAM<\/strong> d\u00e9finir. Si je d\u00e9passe la valeur de fond, le noyau commence \u00e0 <strong>Contexte<\/strong> d'\u00e9criture. Si j'atteins la limite stricte, le syst\u00e8me ralentit les processus d'\u00e9criture jusqu'\u00e0 ce qu'une quantit\u00e9 suffisante de donn\u00e9es ait \u00e9t\u00e9 renvoy\u00e9e. Ainsi, la m\u00e9moire reste utilisable, m\u00eame si certains programmes g\u00e9n\u00e8rent de grandes quantit\u00e9s de modifications. Si vous travaillez avec des limites en octets, utilisez les param\u00e8tres *_bytes correspondants \u00e0 la place des valeurs de ratio.<\/p>\n\n<h2>Tableau : param\u00e8tres du noyau et indicateurs pertinents<\/h2>\n\n<p>J'utilise quelques commutateurs centraux pour contr\u00f4ler de mani\u00e8re cibl\u00e9e et rendre visibles le writeback, la latence et le d\u00e9bit ; l'aper\u00e7u suivant aide \u00e0 <strong>Classement<\/strong> et rapides <strong>Examen<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tre\/indicateur<\/th>\n      <th>Effet<\/th>\n      <th>Valeurs par d\u00e9faut \/ Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio \/ vm.dirty_background_bytes<\/td>\n      <td>Lance la r\u00e9\u00e9criture en arri\u00e8re-plan lorsque la proportion de pages corrompues d\u00e9passe ce seuil.<\/td>\n      <td>Pour les serveurs, optez pour un r\u00e9glage plut\u00f4t prudent afin que le flush se d\u00e9clenche plus t\u00f4t.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio \/ vm.dirty_bytes<\/td>\n      <td>Limite maximale pour les \u00ab dirty pages \u00bb ; \u00e0 partir de ce seuil, les \u00e9critures sont limit\u00e9es.<\/td>\n      <td>Si elle est trop \u00e9lev\u00e9e, elle augmente les risques li\u00e9s \u00e0 la latence ; si elle est trop faible, elle r\u00e9duit le d\u00e9bit.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_writeback_centisec<\/td>\n      <td>Intervalle pendant lequel le noyau v\u00e9rifie les pages sales en vue d'un vidage en arri\u00e8re-plan.<\/td>\n      <td>Des intervalles plus courts att\u00e9nuent les pics de charge, mais g\u00e9n\u00e8rent davantage de r\u00e9veils.<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_expire_centisecs<\/td>\n      <td>\u00c2ge \u00e0 partir duquel les \u201e Dirty Pages \u201c sont consid\u00e9r\u00e9es comme \u00ab m\u00fbres \u00bb et font l'objet d'une attention particuli\u00e8re lors de la r\u00e9daction.<\/td>\n      <td>Des valeurs plus \u00e9lev\u00e9es renforcent l'agr\u00e9gation, mais r\u00e9duisent les garanties de coh\u00e9rence en cas d'erreur.<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/meminfo : Dirty, Writeback<\/td>\n      <td>Nombre actuel de pages souill\u00e9es ou activement r\u00e9\u00e9crites.<\/td>\n      <td>Utile pour l'observation en temps r\u00e9el lors des tests de charge.<\/td>\n    <\/tr>\n    <tr>\n      <td>Options de montage\/FS (par exemple, barri\u00e8res, mode journal)<\/td>\n      <td>Influencent l'ordre, la persistance et le co\u00fbt des diff\u00e9rentes op\u00e9rations de vidage.<\/td>\n      <td>Faites votre choix en fonction du syst\u00e8me de fichiers et du p\u00e9riph\u00e9rique.<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Je rel\u00e8ve r\u00e9guli\u00e8rement ces valeurs et je les mets en corr\u00e9lation avec les temps d'attente d'E\/S dans Top, iostat ou d'autres outils similaires. <strong>Outils<\/strong>. Cela permet de d\u00e9terminer clairement si c'est Writeback lui-m\u00eame qui est \u00e0 l'origine de la limitation ou si c'est le <strong>Stockage<\/strong> est \u00e0 la limite.<\/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\/08\/linux-kernel-cache-dirty-pages-4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Suivi et diagnostic : ce que je mesure<\/h2>\n\n<p>Je commence par consulter le fichier \/proc\/meminfo et j'observe les champs \u00ab Dirty \u00bb et \u00ab Writeback \u00bb tout en effectuant de mani\u00e8re cibl\u00e9e <strong>Dernier<\/strong> g\u00e9n\u00e8re. Lorsque les \u00ab dirty \u00bb montent fortement et restent \u00e9lev\u00e9s, il manque souvent des \u00ab flushes \u00bb opportuns ou le <strong>Moyen<\/strong> est satur\u00e9. Si le \u00ab writeback \u00bb augmente mais que le \u00ab dirty \u00bb ne diminue que lentement, cela ralentit le p\u00e9riph\u00e9rique cible ou le chemin d'E\/S. Si les pics de latence co\u00efncident avec les pics de \u00ab writeback \u00bb, je lisse l'intervalle ou je r\u00e9duis les valeurs de ratio. Pour me familiariser avec les sch\u00e9mas typiques, un bref <a href=\"https:\/\/webhosting.de\/fr\/optimisation-des-performances-du-cache-de-pages-sous-linux\/\">Optimiseur de cache de page<\/a>, qui r\u00e9pertorie les vis de r\u00e9glage et les points de mesure.<\/p>\n\n<h2>Points de mesure avanc\u00e9s, vmstat et tra\u00e7age<\/h2>\n\n<p>Outre \/proc\/meminfo, j'utilise des compteurs tr\u00e8s pr\u00e9cis pour distinguer la cause de l'effet. Dans <strong>\/proc\/vmstat<\/strong> Des champs tels que nr_dirty, nr_writeback, nr_dirtied et nr_written fournissent des indications sur la dynamique : \u00e0 quelle vitesse les donn\u00e9es sont-elles \u00ab salies \u00bb, \u00e0 quelle vitesse sont-elles \u00ab nettoy\u00e9es \u00bb ? En compl\u00e9ment, j'observe la longueur des files d'attente d'E\/S et les taux d'\u00e9chec des op\u00e9rations de fusion dans la couche de blocs.<\/p>\n\n<ul>\n  <li>vmstat 1 : affiche par seconde la d\u00e9rive des op\u00e9rations \u00ab dirty\/writeback \u00bb et le temps d'attente d'E\/S (wa),<\/li>\n  <li>\/proc\/pressure\/memory : indique la pression m\u00e9moire qui d\u00e9clenche indirectement le \u00ab writeback \u00bb,<\/li>\n  <li>Points de trace (writeback:*) et \u00e9v\u00e9nements de bloc : r\u00e9v\u00e8lent l'ordre et la taille des vidages,<\/li>\n  <li>perf\/ftrace : identifie les points chauds dans balance_dirty_pages et les files d'attente de travail de Flusher.<\/li>\n<\/ul>\n\n<p>Si je constate que la valeur \u00ab nr_dirtied \u00bb reste syst\u00e9matiquement sup\u00e9rieure \u00e0 \u00ab nr_written \u00bb, c'est un signe clair d'un risque imminent de limitation de d\u00e9bit ou de vidages en arri\u00e8re-plan effectu\u00e9s trop tardivement. Si les pics observ\u00e9s au niveau des points de trace de r\u00e9\u00e9criture co\u00efncident avec des pics de latence, j'optimise l'intervalle et la taille des lots.<\/p>\n\n<h2>Disque dur (HDD) vs SSD : implications pour la conception du \u00ab writeback \u00bb<\/h2>\n\n<p>Sur les rouleaux, les grandes s\u00e9ries cons\u00e9cutives sont particuli\u00e8rement rentables, car elles \u00e9vitent les recherches co\u00fbteuses <strong>\u00e9viter<\/strong>. Les SSD en b\u00e9n\u00e9ficient \u00e9galement, mais ce qui compte ici, c'est la r\u00e9partition des \u00e9critures et l'interaction avec le <strong>Contr\u00f4leur<\/strong>. J'\u00e9vite les synchronisations trop fr\u00e9quentes afin que le micrologiciel puisse fonctionner efficacement. Parall\u00e8lement, je porte davantage attention aux barri\u00e8res de coh\u00e9rence et \u00e0 la s\u00e9mantique de vidage sur les SSD afin de tirer pleinement parti des garanties offertes par le p\u00e9riph\u00e9rique. Les charges de travail mixtes, comprenant des lectures et des \u00e9critures al\u00e9atoires, r\u00e9agissent de mani\u00e8re perceptible aux petits ajustements des seuils de donn\u00e9es sales et du timing de vidage.<\/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\/08\/tech_office_nacht_6342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cache de l'appareil, s\u00e9mantique de vidage et protection contre les coupures de courant (PLP)<\/h2>\n\n<p>La persistance effective d'un flush d\u00e9pend \u00e9galement de <strong>Cache de l'appareil<\/strong> . De nombreux disques durs mettent les donn\u00e9es en m\u00e9moire tampon dans leur propre DRAM. Sans <strong>Protection contre les pertes de puissance (PLP)<\/strong> Je risque une perte de donn\u00e9es si le cache n'est pas vid\u00e9 \u00e0 temps. Le \u00ab writeback \u00bb tire certes parti du cache du p\u00e9riph\u00e9rique, mais je m'assure que les barri\u00e8res et les commandes de vidage soient respect\u00e9es. Sur les syst\u00e8mes \u00e9quip\u00e9s de contr\u00f4leurs RAID, je v\u00e9rifie s\u2019il existe un cache aliment\u00e9 par batterie ou par m\u00e9moire flash ; dans ce cas, les \u00e9critures synchronis\u00e9es sont souvent plus avantageuses, sans compromettre la s\u00e9curit\u00e9.<\/p>\n\n<p>Je fais \u00e9galement la distinction suivante : le FUA (Force Unit Access) impose la persistance \u00e0 chaque op\u00e9ration d'E\/S, mais cela a un co\u00fbt en termes d'IOPS. Les barri\u00e8res de vidage peuvent s\u00e9curiser plusieurs \u00e9critures simultan\u00e9ment. Pour les chemins particuli\u00e8rement critiques (comme les journaux), j'accepte la surcharge li\u00e9e au FUA et au flush, tandis que je laisse les donn\u00e9es en masse dans le flux de r\u00e9\u00e9criture diff\u00e9r\u00e9e. Quiconque modifie les options de montage ou les param\u00e8tres du contr\u00f4leur doit ensuite v\u00e9rifier, \u00e0 l'aide de tests de charge, que la s\u00e9mantique de vidage pr\u00e9vue fonctionne correctement.<\/p>\n\n<h2>Coh\u00e9rence des donn\u00e9es : utiliser correctement fsync, Flush et FUA<\/h2>\n\n<p>J'utilise fsync de mani\u00e8re cibl\u00e9e pour les donn\u00e9es pr\u00e9sentant un volume \u00e9lev\u00e9 <strong>Valeur<\/strong>, qui ont besoin d'une garantie claire de durabilit\u00e9. Le noyau peut propager les op\u00e9rations de vidage jusqu'au support et, gr\u00e2ce \u00e0 la FUA, s'assurer qu'une \u00e9criture est bel et bien <strong>persiste<\/strong>, avant que la confirmation ne revienne. Cette approche prend du temps et consomme des IOPS, mais elle \u00e9vite la perte de donn\u00e9es en cas de plantage. Sans ces barri\u00e8res, le syst\u00e8me signale les op\u00e9rations comme r\u00e9ussies alors que les octets se trouvent encore dans le cache du SSD ou dans la m\u00e9moire vive. J'adapte ces choix en fonction de l'application : sauvegarde \u00ab dure \u00bb pour les journaux de transactions, \u00ab souple \u00bb pour les mises \u00e0 jour en masse.<\/p>\n\n<h2>Exemples d'optimisation pour les charges de travail li\u00e9es \u00e0 l'h\u00e9bergement et aux bases de donn\u00e9es<\/h2>\n\n<p>Pour les serveurs Web et les serveurs de bases de donn\u00e9es, je d\u00e9finis souvent une valeur mod\u00e9r\u00e9e pour `dirty_background_ratio` et je maintiens `dirty_ratio` nettement au-dessus afin d'assurer un vidage en arri\u00e8re-plan en temps voulu. <strong>d\u00e9marrer<\/strong>, sans que Schreiber ne soit trop t\u00f4t \u00e0 <strong>freins<\/strong>. Lors de pics d'\u00e9criture, je r\u00e9duis l'intervalle de r\u00e9\u00e9criture afin que les m\u00e9canismes de r\u00e9\u00e9criture se d\u00e9clenchent plus t\u00f4t. Sur les syst\u00e8mes dot\u00e9s d'une grande quantit\u00e9 de RAM, je privil\u00e9gie les valeurs *_bytes afin d'utiliser des quantit\u00e9s r\u00e9elles plut\u00f4t que des pourcentages. Je teste chaque modification \u00e0 l\u2019aide de benchmarks reproductibles et je mesure la latence, le d\u00e9bit ainsi que les 95e et 99e centiles. Cet aper\u00e7u pratique me fournit un guide concis sur l\u2019impact du cache de page : <a href=\"https:\/\/webhosting.de\/fr\/optimisation-des-performances-du-cache-de-pages-sous-linux\/\">Optimisation des performances du cache de pages sous Linux<\/a>.<\/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\/08\/devdesk_linux_cache_4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Direct I\/O et mmap : lorsque le cache de pages est contourn\u00e9<\/h2>\n\n<p>Toutes les applications n'utilisent pas le cache de page de la m\u00eame mani\u00e8re. Avec <strong>O_DIRECT<\/strong> elle peut contourner d\u00e9lib\u00e9r\u00e9ment le cache et \u00e9crire ou lire directement dans le p\u00e9riph\u00e9rique. Cela soulage la m\u00e9moire vive et raccourcit les chemins d'acc\u00e8s, mais me prive des avantages du traitement par lots et de la lecture anticip\u00e9e. Cela peut s'av\u00e9rer utile pour les transferts volumineux et ponctuels ; en revanche, pour de nombreuses petites \u00e9critures, je perds les avantages du \u00ab writeback \u00bb.<\/p>\n\n<p>Avec <strong>mmap<\/strong> et avec le \u00ab Copy-on-Write \u00bb, je marque les pages comme \u00ab sales \u00bb lorsqu'elles sont modifi\u00e9es ; la mise \u00e0 jour s'effectue via le chemin de r\u00e9\u00e9criture normal ou par <strong>msync<\/strong>. J'en tiens compte lorsque les applications s'appuient fortement sur les E\/S en m\u00e9moire : des pics de donn\u00e9es non valid\u00e9es peuvent survenir de mani\u00e8re inattendue, m\u00eame si l'application \u201e ne fait que \u201c modifier la m\u00e9moire. L\u00e0 encore, la d\u00e9finition de limites de ratio ou d'octets permet de contr\u00f4ler le moment de la r\u00e9\u00e9criture.<\/p>\n\n<h2>Environnements de conteneurs et \u00ab writeback \u00bb des cgroups<\/h2>\n\n<p>Dans les configurations multi-locataires, j'\u00e9vite les \u201e voisins bruyants \u201c gr\u00e2ce \u00e0 <strong>cgroups<\/strong>. Le noyau attribue les pages sales au groupe \u00e0 l'origine de leur modification (cgroup-Writeback), ce qui permet une r\u00e9partition plus \u00e9quitable du vidage en arri\u00e8re-plan et de la limitation du d\u00e9bit. Gr\u00e2ce \u00e0 des limites de m\u00e9moire (<strong>memory.high<\/strong>, memory.max), je limite les pics de m\u00e9moire \u00ab sale \u00bb par conteneur. De plus, je d\u00e9finis des quotas d'E\/S via le contr\u00f4leur d'E\/S afin d'emp\u00eacher que certaines charges de travail ne saturent la file d'attente du p\u00e9riph\u00e9rique.<\/p>\n\n<p>Dans la pratique, je d\u00e9finis des limites maximales r\u00e9alistes pour chaque classe de service : les t\u00e2ches batch gourmandes en \u00e9criture se voient attribuer des \u00ab dirty budgets \u00bb g\u00e9n\u00e9reux, tandis que les frontends sensibles \u00e0 la latence en ont des plus restreints. La latence globale reste ainsi plus stable, car le \u00ab writeback \u00bb ne limite pas brusquement le d\u00e9bit pour tous les conteneurs d\u00e8s qu\u2019un seul d\u2019entre eux d\u00e9raille.<\/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\/08\/linux-kernel-cache-8974.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Syst\u00e8mes de fichiers r\u00e9seau (NFS, SMB, syst\u00e8mes de fichiers distribu\u00e9s)<\/h2>\n\n<p>Dans le cas des syst\u00e8mes de fichiers en r\u00e9seau, un niveau de mise en m\u00e9moire tampon suppl\u00e9mentaire intervient. Les pages modifi\u00e9es locales indiquent simplement que des donn\u00e9es sont en cours de transfert ; quant \u00e0 savoir si elles <strong>\u00e0 distance<\/strong> C'est le protocole (s\u00e9mantique de validation) et le serveur qui d\u00e9cident si les donn\u00e9es ont \u00e9t\u00e9 valid\u00e9es. Je ne me fie pas aux vidages implicites : je synchronise explicitement les donn\u00e9es critiques. Dans le m\u00eame temps, je tiens compte des co\u00fbts li\u00e9s aux allers-retours : des synchronisations trop fr\u00e9quentes sur le r\u00e9seau aggravent sensiblement les latences.<\/p>\n\n<p>Dans les charges de travail mixtes, je s\u00e9pare les chemins d'acc\u00e8s : les fichiers locaux et temporaires tirent pleinement parti du cache de pages ; les montages r\u00e9seau b\u00e9n\u00e9ficient de points de synchronisation plus stricts. J'\u00e9vite ainsi que la r\u00e9\u00e9criture via le r\u00e9seau ne devienne un goulot d'\u00e9tranglement, alors que les t\u00e2ches locales disposeraient encore de r\u00e9serves.<\/p>\n\n<h2>Planificateur d'E\/S, blk-mq et profondeur de file d'attente<\/h2>\n\n<p>L'efficacit\u00e9 avec laquelle les lots de r\u00e9\u00e9criture sont transf\u00e9r\u00e9s vers l'appareil d\u00e9pend \u00e9galement de <strong>Blocklayer<\/strong> \u00e0 partir de. Avec <strong>blk-mq<\/strong> Les E\/S sont r\u00e9parties sur plusieurs files d'attente ; des planificateurs tels que mq-deadline ou kyber \u00e9tablissent des priorit\u00e9s et organisent les op\u00e9rations. Je choisis le planificateur en fonction du support : sur NVMe, \u201e none \u201c est souvent judicieux, tandis que sur SATA ou SAS, Deadline facilite l'organisation des \u00e9critures.<\/p>\n\n<p>Le <strong>Profondeur de la file d'attente<\/strong> Je le d\u00e9finis de mani\u00e8re \u00e0 ce que l'appareil soit sollicit\u00e9 \u00e0 pleine capacit\u00e9, mais sans \u00eatre surcharg\u00e9. Une profondeur trop faible r\u00e9duit le d\u00e9bit, tandis qu'une profondeur trop importante augmente la dispersion de la latence et rend la limitation de d\u00e9bit plus difficile. Le \u201e writeback \u201c tire profit de profondeurs mod\u00e9r\u00e9es et de requ\u00eates volumineuses et contigu\u00ebs. Je surveille les taux de fusion et les compteurs \u00ab inflight \u00bb ; une baisse des taux de fusion indique que les lots sont trop petits ou qu\u2019il y a des charges de travail al\u00e9atoires concurrentes.<\/p>\n\n<h2>Tests reproductibles et restauration en toute s\u00e9curit\u00e9<\/h2>\n\n<p>Avant de r\u00e9gler les commandes, je note l'\u00e9tat actuel, je v\u00e9rifie <strong>reproductible<\/strong> et je pr\u00e9vois des retours en arri\u00e8re. J'utilise des charges de travail identiques, des volumes de donn\u00e9es identiques, et je pr\u00e9chauffe le cache de mani\u00e8re cibl\u00e9e ou je le vide d\u00e9lib\u00e9r\u00e9ment afin de garantir la comparabilit\u00e9 des tests. Je d\u00e9finis d'abord les modifications de param\u00e8tres de mani\u00e8re temporaire, j'observe les m\u00e9triques, puis je ne les enregistre de mani\u00e8re d\u00e9finitive qu'ensuite.<\/p>\n\n<pre><code># Exemple : r\u00e9glages temporaires (Root)\nsysctl -w vm.dirty_background_bytes=$((512*1024*1024))\nsysctl -w vm.dirty_bytes=$((2*1024*1024*1024))\nsysctl -w vm.dirty_writeback_centisecs=100\nsysctl -w vm.dirty_expire_centisecs=3000\n\n# Test de charge court (exemple, en fonction de la charge de travail)\n# fio --name=wbtest --filename=\/data\/testfile --size=8G --ioengine=libaio \\\n#     --rw=randwrite --bs=128k --iodepth=32 --direct=0 --numjobs=4 --runtime=60 --time_based\n<\/code><\/pre>\n\n<p>Pendant ce temps, je lis en parall\u00e8le les fichiers \/proc\/meminfo, vmstat et iostat et je mets en corr\u00e9lation les pics. Une fois le test termin\u00e9, je r\u00e9initialise les valeurs ou je les int\u00e8gre de mani\u00e8re contr\u00f4l\u00e9e dans la configuration du syst\u00e8me. Pour cela, je documente <strong>Date<\/strong>, <strong>Noyau<\/strong>- la version, les informations relatives \u00e0 l'appareil et au syst\u00e8me de fichiers, afin que les comparaisons ult\u00e9rieures restent fiables.<\/p>\n\n<h2>Probl\u00e8mes courants et solutions<\/h2>\n\n<p>Si le syst\u00e8me semble fonctionner de mani\u00e8re fluide, mais que les op\u00e9rations d'\u00e9criture sont ralenties, je v\u00e9rifie s'il y a un ralentissement d\u00fb \u00e0 une valeur trop faible de <strong>dirty_ratio<\/strong>. Si le niveau de \u00ab dirty \u00bb reste \u00e9lev\u00e9, cela signifie qu'il y a un manque de bande passante ou que le <strong>Intervalle<\/strong> Le d\u00e9lai jusqu'au flush est trop long. Lorsque les latences explosent lors de br\u00e8ves rafales de synchronisation, je r\u00e9partis la charge en lots plus petits et j'optimise la planification des E\/S. Si le cache peine \u00e0 se mettre en route, une limite *_bytes trop faible emp\u00eache peut-\u00eatre un regroupement en lots efficace. Un examen plus approfondi de <a href=\"https:\/\/webhosting.de\/fr\/serveur-page-cache-eviction-linux-memory-impression-optimisation-insight\/\">\u00c9viction du cache lors de l'impression<\/a> cela aide lorsque le manque d'espace de stockage vient s'ajouter aux difficult\u00e9s.<\/p>\n\n<h2>Bonnes pratiques et petite liste de contr\u00f4le<\/h2>\n\n<p>Je fais une distinction stricte entre les donn\u00e9es qui doivent \u00eatre enregistr\u00e9es imm\u00e9diatement et celles dont la persistance peut \u00eatre diff\u00e9r\u00e9e, afin de <strong>Performance<\/strong> \u00e0 gagner. Pour les journaux et les journaux de transactions, j'impose des synchronisations ; pour les artefacts temporaires, je laisse le \u00ab writeback \u00bb fonctionner librement et je ne surveille que la limite de r\u00e9gulation. Avant chaque ajustement, je mesure l\u2019\u00e9tat actuel et je compare les r\u00e9sultats A\/B \u00e0 l\u2019aide de sc\u00e9narios d\u00e9finis. Je limite le nombre d\u2019\u00e9crivains simultan\u00e9s, car des flux non coordonn\u00e9s r\u00e9duisent l\u2019int\u00e9r\u00eat du traitement par lots. Et je documente imm\u00e9diatement les modifications afin que les analyses futures puissent s\u2019appuyer sur des donn\u00e9es claires <strong>Donn\u00e9es<\/strong> bas\u00e9e.<\/p>\n\n<h2>R\u00e9sum\u00e9 pratique pour une r\u00e9ussite rapide<\/h2>\n\n<p>Le cache de r\u00e9\u00e9criture regroupe les modifications apport\u00e9es au <strong>Page<\/strong> Le cache r\u00e9duit les co\u00fbts d'E\/S et all\u00e8ge la charge des applications. Les pages sales ne constituent pas une erreur, mais un moyen cibl\u00e9 de gagner en vitesse, \u00e0 condition de conna\u00eetre les limites et les exigences de coh\u00e9rence. Gr\u00e2ce aux param\u00e8tres vm.dirty_background_ratio et vm.dirty_ratio, je peux contr\u00f4ler quand le noyau travaille discr\u00e8tement en arri\u00e8re-plan et quand il freine les op\u00e9rations d'\u00e9criture. Les outils et le r\u00e9pertoire \/proc me fournissent la visibilit\u00e9 n\u00e9cessaire sur les pages sales et les r\u00e9\u00e9critures, afin que je ne sois pas dans le flou. Lorsque je ma\u00eetrise ces leviers, le Web, les bases de donn\u00e9es et les t\u00e2ches par lots fonctionnent nettement plus rapidement, sans que cela n\u2019affecte la <strong>Int\u00e9grit\u00e9<\/strong> de compromettre la s\u00e9curit\u00e9 de mes donn\u00e9es.<\/p>","protected":false},"excerpt":{"rendered":"<p>Le cache de r\u00e9\u00e9criture dans le noyau Linux : explications claires sur les pages sales, le cache de pages et la r\u00e9\u00e9criture.<\/p>","protected":false},"author":1,"featured_media":20541,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20548","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"153","_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":null,"_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":"Writeback Cache","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":"20541","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20548","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/comments?post=20548"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20548\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20541"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}