{"id":20858,"date":"2026-08-21T11:49:48","date_gmt":"2026-08-21T09:49:48","guid":{"rendered":"https:\/\/webhosting.de\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/"},"modified":"2026-08-21T11:49:48","modified_gmt":"2026-08-21T09:49:48","slug":"ratio-de-fichiers-dirty-sous-linux-ratio-de-fichiers-dirty-en-arriere-plan-optimisation-reecriture-differee","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/linux-dirty-ratio-dirty-background-ratio-optimierung-writeback\/","title":{"rendered":"Ratio \u00ab dirty \u00bb et ratio \u00ab dirty background \u00bb sous Linux : r\u00e9glage fin pour des performances d'\u00e9criture optimales"},"content":{"rendered":"<p>Je montre comment <strong>linux dirty<\/strong> et le \u00ab dirty background ratio \u00bb permettent de contr\u00f4ler le cache de page et, par l\u00e0 m\u00eame, d'influencer le d\u00e9bit d'\u00e9criture, la latence et la s\u00e9curit\u00e9 des donn\u00e9es. Vous pouvez ainsi d\u00e9finir des seuils pr\u00e9cis qui d\u00e9clenchent les op\u00e9rations de vidage du cache en temps opportun, \u00e9vitent les blocages et am\u00e9liorent les performances d'\u00e9criture de vos charges de travail.<\/p>\n\n<h2>Points centraux<\/h2>\n<p>Pour commencer, je vais bri\u00e8vement r\u00e9sumer les points essentiels avant d'approfondir le sujet.<\/p>\n<ul>\n  <li><strong>Pages os\u00e9es<\/strong> mise en m\u00e9moire tampon des \u00e9critures dans la RAM et regroupe de nombreux petits acc\u00e8s en op\u00e9rations d'E\/S plus efficaces.<\/li>\n  <li><strong>dirty_background_ratio<\/strong> lance des threads Flusher en arri\u00e8re-plan, ce qui permet de limiter discr\u00e8tement la quantit\u00e9 de donn\u00e9es ind\u00e9sirables.<\/li>\n  <li><strong>dirty_ratio<\/strong> ralentit les processus d'\u00e9criture lorsque la limite stricte est d\u00e9pass\u00e9e.<\/li>\n  <li><strong>Relation<\/strong> Ces deux valeurs d\u00e9terminent les pics de latence, le d\u00e9bit et la taille de la m\u00e9moire tampon.<\/li>\n  <li><strong>Variantes d'octets<\/strong> (dirty_bytes) permettent un contr\u00f4le plus pr\u00e9cis et absolu sur les gros serveurs.<\/li>\n<\/ul>\n\n<h2>Comprendre les \u00ab Dirty Pages \u00bb<\/h2>\n\n<p>Lorsqu'un processus \u00e9crit des donn\u00e9es, celles-ci sont d'abord stock\u00e9es dans le <strong>Cache de page<\/strong> et sont marqu\u00e9es comme \u201e sales \u201c jusqu\u2019\u00e0 ce que le noyau puisse les vider sur le support de stockage. Cette mise en m\u00e9moire tampon acc\u00e9l\u00e8re les applications, car la RAM r\u00e9agit plus rapidement que n\u2019importe quel SSD ou disque dur, et les petites \u00e9critures s\u2019agr\u00e8gent pour former de grands transferts s\u00e9quentiels. Je garde toujours \u00e0 l\u2019esprit la quantit\u00e9 de \u201e salet\u00e9 \u201c que j\u2019autorise, car un tampon trop important peut allonger les files d\u2019attente ou exposer davantage de donn\u00e9es non sauvegard\u00e9es en cas de plantage. Comprendre ce fonctionnement permet de prendre de meilleures d\u00e9cisions concernant le writeback, la latence et la pression sur la m\u00e9moire. Un bref article de fond sur le <a href=\"https:\/\/webhosting.de\/fr\/cache-de-reecriture-cache-du-noyau-linux\/\">Cache de r\u00e9\u00e9criture<\/a> permet de bien cerner ce m\u00e9canisme.<\/p>\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\/linux-schreibfeintuning-7492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e9curit\u00e9 des donn\u00e9es, fsync et fen\u00eatre de plantage<\/h2>\n<p>Ces limites n'influencent pas seulement les performances, mais aussi ta fen\u00eatre de risque. Je fais un calcul approximatif \u00e0 l'aide d'une r\u00e8gle empirique simple : la quantit\u00e9 maximale de donn\u00e9es non valid\u00e9es divis\u00e9e par le d\u00e9bit durable de l'appareil donne, en gros, le temps n\u00e9cessaire pour vider la m\u00e9moire tampon. Exemple : si j\u2019autorise 4 Go de donn\u00e9es \u00ab sales \u00bb et que le support cible atteint un d\u00e9bit de 500 Mo\/s, l\u2019\u00e9criture compl\u00e8te prendra environ 8 secondes. Pendant ce laps de temps, en cas de coupure de courant ou de \u00ab kernel panic \u00bb, les derni\u00e8res \u00e9critures risquent d\u2019\u00eatre perdues.<\/p>\n<p>Les applications peuvent fermer la fen\u00eatre en <code>fsync()<\/code> ou <code>fdatasync()<\/code> r\u00e9duire, car ces appels obligent le syst\u00e8me de fichiers \u00e0 \u00e9crire des donn\u00e9es (et, selon le mode de journalisation, \u00e9galement des m\u00e9tadonn\u00e9es) sur le support. C'est plus co\u00fbteux, mais essentiel pour les bases de donn\u00e9es ou les journaux. Je veille \u00e0 ce que mes limites de donn\u00e9es sales correspondent au comportement de synchronisation : fr\u00e9quentes <code>fsync()<\/code>-Les visites b\u00e9n\u00e9ficient d'un taux plus bas <em>dirty_ratio<\/em>, afin que le noyau n'applique pas de limitation suppl\u00e9mentaire alors que la persistance s'effectue de toute fa\u00e7on r\u00e9guli\u00e8rement. \u00c0 l'inverse, pour les journaux qui utilisent beaucoup l'ajout en fin de fichier et qui sont rarement vid\u00e9s, je peux autoriser des tampons plus importants \u2013 toujours en tenant compte du risque de perte accept\u00e9.<\/p>\n<p>Les barri\u00e8res et l'ordre d'\u00e9criture sont \u00e9galement importants : les syst\u00e8mes de fichiers modernes utilisent des commandes FUA\/Flush pour vider correctement les caches des contr\u00f4leurs. Sur les supports d\u00e9pourvus de protection contre les coupures de courant (PLP), des tampons de grande taille augmentent le risque ; avec la PLP ou une protection du cache d'\u00e9criture, des tampons plus volumineux sont souvent acceptables.<\/p>\n\n<h2>Dirty Background Ratio : le seuil flou<\/h2>\n\n<p>Avec <strong>dirty_background_ratio<\/strong> Je d\u00e9finis \u00e0 partir de quel pourcentage de l'espace de stockage disponible les threads de vidage commencent \u00e0 \u00e9crire en arri\u00e8re-plan. Cette valeur ne bloque pas les applications, mais lance discr\u00e8tement les op\u00e9rations de nettoyage afin d'\u00e9viter que la m\u00e9moire tampon ne d\u00e9borde. Des valeurs faibles entra\u00eenent des \u00e9critures en arri\u00e8re-plan plus fr\u00e9quentes mais plus r\u00e9guli\u00e8res et lissent les pics de latence. Des valeurs plus \u00e9lev\u00e9es permettent d\u2019accumuler davantage de donn\u00e9es dans le tampon, ce qui augmente le d\u00e9bit lors d\u2019\u00e9critures s\u00e9quentielles volumineuses, mais peut provoquer des pics d\u2019E\/S consid\u00e9rables en cas de vidage soudain. Les valeurs par d\u00e9faut se situent g\u00e9n\u00e9ralement autour de 10 %, mais j\u2019ajuste cette limite en fonction du support, de la charge de travail et des exigences de s\u00e9curit\u00e9.<\/p>\n\n<h2>Dirty Ratio : le freinage brutal<\/h2>\n\n<p>Le param\u00e8tre <strong>dirty_ratio<\/strong> indique le seuil \u00e0 partir duquel le noyau limite les processus en \u00e9criture jusqu\u2019\u00e0 ce qu\u2019un nombre suffisant de pages ait \u00e9t\u00e9 r\u00e9\u00e9crit. Cette limite stricte prot\u00e8ge la m\u00e9moire contre un afflux de donn\u00e9es non persistantes et a donc un impact direct sur les applications d\u00e8s qu\u2019elles tentent de poursuivre leur production. Pour les bases de donn\u00e9es, je r\u00e8gle cette valeur plut\u00f4t bas afin que les requ\u00eates conservent des temps de r\u00e9ponse constants et qu\u2019il n\u2019y ait pas de longues phases de vidage. Pour les t\u00e2ches de sauvegarde, en revanche, j\u2019utilise des tampons plus g\u00e9n\u00e9reux afin de transf\u00e9rer efficacement de grands blocs de donn\u00e9es. Les valeurs par d\u00e9faut habituelles varient entre 20 et 40 %, mais j\u2019adapte toujours cette plage \u00e0 la charge r\u00e9elle.<\/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_perf_neu_opt_3847.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Interactions et relations typiques<\/h2>\n\n<p>Ces deux valeurs limites fonctionnent comme <strong>Tandem<\/strong> et ne d\u00e9ploient leurs effets qu\u2019ensemble. Je maintiens toujours la valeur de `dirty_background_ratio` inf\u00e9rieure \u00e0 celle de `dirty_ratio`, afin que le noyau d\u00e9marre \u00e0 temps en arri\u00e8re-plan et que le freinage brutal ne se d\u00e9clenche que rarement. En r\u00e8gle g\u00e9n\u00e9rale, je choisis souvent entre un quart et la moiti\u00e9 de la limite stricte, soit par exemple 5\u201310 pour 20. Ainsi, le \u00ab writeback \u00bb d\u00e9marre suffisamment t\u00f4t sans r\u00e9duire inutilement le d\u00e9bit. Si l\u2019on ne respecte pas ce rapport, on constate soit une limitation trop pr\u00e9coce, soit un traitement en arri\u00e8re-plan trop tardif, accompagn\u00e9 de pics de latence perceptibles.<\/p>\n\n<h2>Contr\u00f4le par p\u00e9riph\u00e9rique et granularit\u00e9 de la couche de blocs<\/h2>\n<p>Outre les limites globales, il est int\u00e9ressant de se pencher sur le niveau des p\u00e9riph\u00e9riques. Linux r\u00e9partit la charge \u00ab sale \u00bb via ce qu'on appelle <em>Appareils pris en charge<\/em> (bdi). Dans <code>\/sys\/class\/block\/\/bdi\/<\/code> Je trouve que des param\u00e8tres tels que <code>max_ratio<\/code>, qui d\u00e9terminent la part du \u00ab Dirty Budget \u00bb global autoris\u00e9 qu'un p\u00e9riph\u00e9rique individuel peut utiliser. Sur les syst\u00e8mes \u00e9quip\u00e9s \u00e0 la fois de disques lents et rapides, je limite les disques lents afin qu'ils ne deviennent pas un goulot d'\u00e9tranglement.<\/p>\n<p>La limitation au niveau de la couche de blocs via <code>\/sys\/block\/\/queue\/wbt_lat_usec<\/code> (Writeback Throttling). Je d\u00e9finis ainsi une latence cible ; le noyau limite alors la charge d'\u00e9criture d\u00e8s que cette latence cible est d\u00e9pass\u00e9e. Avec les disques durs SATA, je pr\u00e9f\u00e8re d\u00e9finir des valeurs prudentes afin de pr\u00e9server l\u2019interactivit\u00e9. Sur les disques NVMe tr\u00e8s rapides, je d\u00e9sactive ou augmente la latence cible afin que le contr\u00f4leur puisse exploiter pleinement son parall\u00e9lisme. Je choisis le planificateur d'E\/S (mq-deadline, BFQ, none) en fonction des besoins : BFQ est utile pour les syst\u00e8mes interactifs \u00e0 charge mixte, tandis que <em>none<\/em> ou que mq-deadline donne souvent les meilleurs r\u00e9sultats pour les t\u00e2ches de d\u00e9bit pur sur NVMe.<\/p>\n<p>C'est l'interaction qui est d\u00e9terminante : est-ce que <em>dirty_background_ratio<\/em> m\u00eame si elle est faible, mais que l'appareil est limit\u00e9 de mani\u00e8re stricte par le WBT, des congestions visibles apparaissent tout de m\u00eame. Je calibre donc ces deux niveaux ensemble : les limites \u00ab dirty \u00bb globales pour la taille du tampon, et la couche de blocs pour la protection contre la latence.<\/p>\n\n<h2>Ratio vs. octets : valeurs par d\u00e9faut et variantes<\/h2>\n\n<p>Sur les syst\u00e8mes tr\u00e8s <strong>RAM<\/strong> Les pourcentages atteignent rapidement des ordres de grandeur absolus importants. Je pr\u00e9f\u00e8re alors d\u00e9finir des limites maximales absolues avec `dirty_bytes` et `dirty_background_bytes`, afin de limiter clairement la taille de la m\u00e9moire tampon \u00e0 environ 2 \u00e0 8 Go. Cela dissocie la gestion des niveaux de m\u00e9moire tr\u00e8s fluctuants et permet de maintenir la quantit\u00e9 de donn\u00e9es non persistantes \u00e0 un niveau pr\u00e9visible. Le choix reste dynamique : pour les petits serveurs disposant de peu de RAM, les pourcentages suffisent souvent amplement. Ceux qui disposent d\u2019une grande capacit\u00e9 ont souvent plus de facilit\u00e9 \u00e0 planifier avec des valeurs en octets.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Param\u00e8tres<\/th>\n      <th>Signification<\/th>\n      <th>D\u00e9fauts typiques<\/th>\n      <th>Quand faut-il changer ?<\/th>\n      <th>Remarque<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>vm.dirty_background_ratio<\/td>\n      <td>Lancement du <strong>Rafra\u00eechissement de l'arri\u00e8re-plan<\/strong> en pourcentage<\/td>\n      <td>\u2248 10%<\/td>\n      <td>En cas de fluctuations de latence ou de SSD\/NVMe tr\u00e8s rapides<\/td>\n      <td>Plus la valeur est faible, plus la latence est r\u00e9guli\u00e8re ; plus elle est \u00e9lev\u00e9e, plus la m\u00e9moire tampon est importante<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_ratio<\/td>\n      <td>Dur <strong>limite de r\u00e9gulation<\/strong> en pourcentage<\/td>\n      <td>\u2248 20\u201340%<\/td>\n      <td>Plus faible pour les bases de donn\u00e9es, plus \u00e9lev\u00e9 pour les sauvegardes<\/td>\n      <td>Trop \u00e9lev\u00e9 \u2192 risque de blocages lors du flush<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_background_bytes<\/td>\n      <td>Lancement du vidage en arri\u00e8re-plan dans <strong>Octets<\/strong><\/td>\n      <td>D\u00e9sactiv\u00e9 lorsque Ratio est utilis\u00e9<\/td>\n      <td>Grande m\u00e9moire vive, cibles de tampon fixes<\/td>\n      <td>Remplace les param\u00e8tres Ratio<\/td>\n    <\/tr>\n    <tr>\n      <td>vm.dirty_bytes<\/td>\n      <td>Limite stricte de la mod\u00e9ration dans <strong>Octets<\/strong><\/td>\n      <td>D\u00e9sactiv\u00e9 lorsque Ratio est utilis\u00e9<\/td>\n      <td>Grande m\u00e9moire vive, plafond pr\u00e9visible<\/td>\n      <td>Remplace les param\u00e8tres Ratio<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Sc\u00e9narios de charge de travail et recommandations<\/h2>\n\n<p>Les charges d'\u00e9criture s\u00e9quentielles telles que <strong>Sauvegardes<\/strong> b\u00e9n\u00e9ficient de tampons importants et d'une \u00e9criture en arri\u00e8re-plan mod\u00e9r\u00e9e, car le noyau peut, dans l'ensemble, \u00e9crire sur le support. Je r\u00e8gle souvent ici le param\u00e8tre `dirty_ratio` entre 30 et 40 % et le param\u00e8tre `dirty_background_ratio` entre 10 et 20 %. Les bases de donn\u00e9es et les petites applications \u00e0 E\/S al\u00e9atoires ont besoin d\u2019une latence pr\u00e9visible ; c\u2019est pourquoi j\u2019opte syst\u00e9matiquement pour 10 \u00e0 15 % de latence \u00ab dure \u00bb et 3 \u00e0 5 % de latence \u00ab souple \u00bb. Pour les serveurs mixtes (Web et applications), des valeurs comprises entre 15 et 20 % pour le \u00ab hard \u00bb et entre 5 et 10 % pour le \u00ab soft \u00bb s\u2019av\u00e8rent \u00eatre un bon compromis. Ces fourchettes servent de point de d\u00e9part ; ensuite, ce sont les mesures r\u00e9elles de votre syst\u00e8me qui priment.<\/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-schreibperformance-feintuning-5648.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspects li\u00e9s au syst\u00e8me de fichiers et options de montage<\/h2>\n<p>Le chemin de r\u00e9\u00e9criture aboutit au syst\u00e8me de fichiers \u2013 dont la strat\u00e9gie d\u00e9termine les latences et la s\u00e9curit\u00e9. Ext4 avec <em>data=ordonn\u00e9<\/em> (Par d\u00e9faut) \u00e9crit les donn\u00e9es utiles avant la validation du journal ; <em>data=retour \u00e0 l'\u00e9criture<\/em> r\u00e9duit la latence, mais expose les donn\u00e9es anciennes \u00e0 des risques en cas de plantage. Le param\u00e8tre <code>commit=<\/code> (secondes) d\u00e9termine la fr\u00e9quence \u00e0 laquelle le journal est valid\u00e9. Des intervalles plus courts r\u00e9duisent les pertes de donn\u00e9es, mais entra\u00eenent davantage d'op\u00e9rations d'E\/S. XFS utilise une architecture de journalisation \u00e9prouv\u00e9e ; les grands <em>logbsize<\/em> et un alignement ad\u00e9quat facilitent les t\u00e2ches de traitement en continu. Btrfs regroupe les \u00e9critures gr\u00e2ce \u00e0 la technologie \u00ab copy-on-write \u00bb : cela stabilise les latences, mais peut entra\u00eener une fragmentation en cas de petites \u00e9critures al\u00e9atoires et de SSD \u00e0 capacit\u00e9 limit\u00e9e. Des options telles que <em>nodatacow<\/em> peuvent aider \u00e0 d\u00e9fragmenter certains chemins ou de mani\u00e8re cibl\u00e9e lorsque des pics de latence se produisent.<\/p>\n<p>Je tiens \u00e9galement \u00e0 souligner <em>relatime<\/em>\/<em>noatime<\/em> (r\u00e9duit les \u00e9critures de m\u00e9tadonn\u00e9es), <em>lazytime<\/em> (mtime\/atime plus persistants), et les barri\u00e8res de journalisation. C'est justement sur les contr\u00f4leurs RAID ou dans les machines virtuelles que la s\u00e9mantique correcte du cache est d\u00e9terminante : des caches d'\u00e9criture mal configur\u00e9s r\u00e9duisent \u00e0 n\u00e9ant tout travail de \u00ab dirty tuning \u00bb.<\/p>\n\n<h2>E\/S directes, O_SYNC et comportement de l'application<\/h2>\n<p>Toutes les applications ne passent pas par le cache de pages. Avec <code>O_DIRECT<\/code> ou <code>O_SYNC<\/code>\/<code>O_DSYNC<\/code> Certains processus contournent certaines parties du cache ou exigent une persistance imm\u00e9diate. Les bases de donn\u00e9es \u00e9crivent g\u00e9n\u00e9ralement un WAL\/journal de reprise de mani\u00e8re synchrone et les zones de donn\u00e9es de mani\u00e8re asynchrone. Je calibre les seuils de \u00ab dirty \u00bb en particulier pour les chemins asynchrones, tandis que je garantis une latence faible aux chemins synchrones gr\u00e2ce \u00e0 des journaux rapides (NVMe, LUN d\u00e9di\u00e9s). Lorsque les applications effectuent tr\u00e8s fr\u00e9quemment <code>fsync()<\/code> lorsqu'on appelle cette fonction, les grandes m\u00e9moires tampons ne sont pas d'une grande utilit\u00e9 : la latence d\u00e9pend alors davantage du contr\u00f4leur, de la profondeur de la file d'attente et du planificateur d'E\/S que de <em>dirty_ratio<\/em>.<\/p>\n\n<h2>Des r\u00e9glages pratiques, \u00e9tape par \u00e9tape<\/h2>\n\n<p>Avant chaque modification, je v\u00e9rifie la <strong>valeurs r\u00e9elles<\/strong> avec <code>sysctl vm.dirty_ratio<\/code> et <code>sysctl vm.dirty_background_ratio<\/code>, afin de consigner la situation initiale. Pour les tests \u00e0 court terme, je note les valeurs directement apr\u00e8s <code>\/proc\/sys\/vm\/<\/code>par exemple <code>echo 15 &gt; \/proc\/sys\/vm\/dirty_ratio<\/code> et <code>echo 5 &gt; \/proc\/sys\/vm\/dirty_background_ratio<\/code>. Si l'ajustement est permanent, je le sauvegarde dans <code>\/etc\/sysctl.conf<\/code> ou <code>\/etc\/sysctl.d\/*.conf<\/code>. J'apporte les modifications \u00e0 l'aide de <code>sysctl -p<\/code> imm\u00e9diatement, afin que je puisse mesurer l'effet dans les plus brefs d\u00e9lais. Ceux qui souhaitent approfondir le sujet des r\u00e8gles du syst\u00e8me b\u00e9n\u00e9ficieront de conseils pratiques sur <a href=\"https:\/\/webhosting.de\/fr\/optimisation-des-performances-dun-serveur-dhebergement-web-via-sysctl\/\">R\u00e9glage des param\u00e8tres sysctl<\/a> sur des serveurs de production.<\/p>\n\n<h2>D\u00e9terminer des valeurs : exemples de calculs<\/h2>\n<p>J'aime bien commencer par des chiffres concrets. Exemple n\u00b0 1 : serveur web\/d'applications avec 64 Go de RAM, NVMe. L'objectif est d'obtenir une latence faible. Je configure <code>dirty_background_bytes=1073741824<\/code> (1 Go) et <code>dirty_bytes=3221225472<\/code> (3 Go). Avec un d\u00e9bit NVMe soutenu de 2 Go\/s, cela correspond \u00e0 environ 0,5 \u00e0 1,5 seconde pour vider le disque \u2013 ce qui est id\u00e9al pour les charges interactives. Exemple 2 : n\u0153ud de sauvegarde avec 128 Go de RAM, RAID SATA rapide \u00e0 800 Mo\/s. Je choisis <code>dirty_background_ratio=10<\/code>, <code>dirty_ratio=35<\/code>. En valeur absolue, cela repr\u00e9sente environ 12,8 Go et 44,8 Go ; le RAID met entre 16 et 56 secondes pour se vider. Ce n'est pas grave, car cette t\u00e2che n'est pas interactive.<\/p>\n<p>Exemple 3 : serveur de base de donn\u00e9es avec 256 Go de RAM, journal s\u00e9par\u00e9 sur NVMe, donn\u00e9es sur une baie de SSD. Je fixe des limites strictes pour \u00e9viter les valeurs aberrantes : <code>dirty_background_bytes=2147483648<\/code> (2 Go), <code>dirty_bytes=8589934592<\/code> (8 Go). Cela permet de pr\u00e9voir la taille de la fen\u00eatre de crash et de r\u00e9duire les ralentissements brutaux lors des points de contr\u00f4le.<\/p>\n\n<h2>Calendrier des r\u00e9\u00e9valuations et param\u00e8tres associ\u00e9s<\/h2>\n\n<p>Outre les valeurs limites, les facteurs suivants ont une influence <strong>Minuteur<\/strong> le comportement de r\u00e9\u00e9criture et, par cons\u00e9quent, la fluidit\u00e9 des applications. Avec <code>vm.dirty_writeback_centisec<\/code> je contr\u00f4le l'intervalle pendant lequel le \u00ab kernel flusher \u00bb est r\u00e9veill\u00e9, tandis que <code>vm.dirty_expire_centisecs<\/code> d\u00e9finit l\u2019\u00e2ge maximal autoris\u00e9 pour les pages sales. Des intervalles plus courts entra\u00eenent des vidages plus fr\u00e9quents mais de plus petite taille, tandis que des intervalles plus longs permettent d\u2019\u00e9conomiser des appels d\u2019E\/S, mais risquent de g\u00e9n\u00e9rer des lots plus volumineux. Je n'ajuste ces valeurs que lorsque les mesures r\u00e9v\u00e8lent de r\u00e9els inconv\u00e9nients, par exemple des vidages trop rares sur des disques NVMe rapides. En proc\u00e9dant de mani\u00e8re m\u00e9thodique, on \u00e9vite les fluctuations entre une activit\u00e9 de r\u00e9\u00e9criture trop intense et une activit\u00e9 trop lente.<\/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_performance_finetune_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Suivi et r\u00e9glage fin<\/h2>\n\n<p>Apr\u00e8s avoir effectu\u00e9 quelques ajustements, je constate que <strong>en continu<\/strong> les indicateurs permettant de mettre en \u00e9vidence les r\u00e9ussites et les effets secondaires. Dans <code>\/proc\/meminfo<\/code> Je v\u00e9rifie les param\u00e8tres \u201e Dirty \u201c et \u201e Writeback \u201c pour conna\u00eetre les niveaux de la m\u00e9moire tampon et les op\u00e9rations de vidage en cours. Des outils tels que iostat, sar ou atop me permettent de visualiser le d\u00e9bit, les files d'attente et les tendances en mati\u00e8re de latence. Cet article sur le sujet constitue une bonne introduction aux m\u00e9triques : <a href=\"https:\/\/webhosting.de\/fr\/serveur-io-wait-analyse-iostat-vmstat-metrics-disk\/\">Analyser l'attente d'E\/S<\/a>. Ce n'est qu'en me basant sur ces donn\u00e9es que je r\u00e9duis ou augmente les limites par petites \u00e9tapes, afin d'\u00e9viter tout effet secondaire inattendu.<\/p>\n\n<h2>Conteneurs, cgroups et r\u00e9partition \u00e9quitable<\/h2>\n<p>Dans les environnements de conteneurs, les charges de travail partagent les m\u00eames m\u00e9canismes du noyau. Le \u00ab Cgroup-Writeback \u00bb garantit que les pages sales soient attribu\u00e9es \u00e0 leur source. J'utilise les contr\u00f4leurs d'E\/S des cgroups (blkcg) pour limiter la bande passante ou les IOPS par conteneur lorsque certains locataires effectuent une mise en m\u00e9moire tampon trop intensive. Limites absolues en octets au niveau de l'h\u00f4te (<em>dirty_bytes<\/em>) pour \u00e9viter qu'un seul visiteur n'\u00e9puise tout le budget \u00ab dirty \u00bb. De plus, je limite l'espace de stockage via <code>memory.max<\/code>, afin que le writeback ne r\u00e9agisse pas seulement en cas de pression globale. L'objectif reste le m\u00eame : aucune charge d'invit\u00e9 ne doit entra\u00eener de limitations \u00e0 l'\u00e9chelle de l'h\u00f4te du <em>dirty_ratio<\/em> imposer.<\/p>\n\n<h2>Environnements d'h\u00e9bergement et machines virtuelles<\/h2>\n\n<p>Dans les configurations multi-clients et les machines virtuelles, je veille \u00e0 ce que <strong>Surr\u00e9servation<\/strong> de la m\u00e9moire vive (RAM) et des E\/S, car les limites en pourcentage y ont un impact diff\u00e9rent. Des limites absolues en octets peuvent emp\u00eacher certains invit\u00e9s d'accumuler trop de m\u00e9moire tampon et de ralentir leurs voisins. Je tiens compte de la d\u00e9duplication de la m\u00e9moire, du \u00ab ballooning \u00bb et des caches des contr\u00f4leurs, car ils viennent se superposer aux effets de mise en m\u00e9moire tampon. Pour les serveurs g\u00e9r\u00e9s, il est avantageux que le fournisseur d\u00e9finisse des valeurs par d\u00e9faut pertinentes afin que les clients b\u00e9n\u00e9ficient de temps de r\u00e9ponse constants. Ceux qui exploitent leurs propres n\u0153uds tirent profit de param\u00e8tres de profil clairement d\u00e9finis pour chaque classe de charge de travail.<\/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\/DirtyRatioTuning1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Id\u00e9es re\u00e7ues et obstacles courants<\/h2>\n<ul>\n  <li><strong>\u201e Plus de marge = un d\u00e9bit toujours plus \u00e9lev\u00e9. \u201c<\/strong> Ce n'est pas le cas pour les charges de travail \u00e0 caract\u00e8re al\u00e9atoire ou les p\u00e9riph\u00e9riques dont la profondeur de file d'attente est faible. Des tampons trop volumineux g\u00e9n\u00e8rent des pics de vidage et des files d'attente.<\/li>\n  <li><strong>\u201e dirty_ratio n'a pas d'incidence sur les lectures. \u201c<\/strong> Indirectement, si : les phases de r\u00e9\u00e9criture agressives \u00e9vincent les pages du cache et augmentent les latences de lecture.<\/li>\n  <li><strong>\u201e Les octets et la raison vont de pair. \u201c<\/strong> Non. Si tu utilises les variantes \u00ab Bytes \u00bb, elles annulent leurs \u00e9quivalents \u00ab Ratio \u00bb. Reste clair.<\/li>\n  <li><strong>\u201e fsync() rend les limites de donn\u00e9es modifi\u00e9es (Dirty Limits) sans importance. \u201c<\/strong> Non. M\u00eame si des synchronisations fr\u00e9quentes r\u00e9duisent la fen\u00eatre de risque, le reste de la charge reste soumis aux valeurs limites.<\/li>\n  <li><strong>\u201e Un support de donn\u00e9es rapide r\u00e9sout tous les probl\u00e8mes. \u201c<\/strong> Pas si la couche de bloc est ralentie (WBT) ou si le syst\u00e8me de fichiers est mont\u00e9 de mani\u00e8re non optimale.<\/li>\n  <li><strong>\u201e Drop_caches est un outil d'optimisation. \u201c<\/strong> Vider le cache fausse les mesures et aggrave les pics de latence. En production, j'\u00e9vite de le faire.<\/li>\n<\/ul>\n\n<h2>D\u00e9pannage : sympt\u00f4mes typiques et solutions<\/h2>\n\n<p>S'accumulent <strong>Pics de latence<\/strong>, je commence par abaisser le seuil d'arri\u00e8re-plan afin que les op\u00e9rations de vidage commencent plus t\u00f4t et que les pics d'\u00e9criture importants se produisent moins souvent. Si certaines applications se bloquent par intermittence, cela signifie g\u00e9n\u00e9ralement que la limite stricte est trop \u00e9lev\u00e9e ou que le support ne parvient pas \u00e0 g\u00e9rer les pics de vidage g\u00e9n\u00e9r\u00e9s. Dans de tels cas, je r\u00e9duis la valeur de `dirty_ratio`, je v\u00e9rifie les param\u00e8tres de lecture anticip\u00e9e et j\u2019examine les options de journalisation du syst\u00e8me de fichiers. Avec du mat\u00e9riel NVMe tr\u00e8s rapide, j\u2019augmente progressivement le seuil d\u2019arri\u00e8re-plan afin de ne pas limiter artificiellement le d\u00e9bit. Apr\u00e8s chaque modification, je me fie aux r\u00e9sultats des mesures, et non \u00e0 mon intuition.<\/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-schreibperformance-5712.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Bilan succinct pour la pratique<\/h2>\n\n<p>Avec peu de <strong>Vis de r\u00e9glage<\/strong> Je contr\u00f4le la mani\u00e8re dont Linux met en m\u00e9moire tampon les donn\u00e9es d'\u00e9criture, le moment o\u00f9 les flusher se lancent et celui o\u00f9 le noyau ralentit. Le \u00ab Dirty Background Ratio \u00bb assure un nettoyage en arri\u00e8re-plan discret, tandis que le \u00ab Dirty Ratio \u00bb limite plus strictement la consommation de RAM. Le rapport entre ces deux valeurs d\u00e9termine si votre syst\u00e8me privil\u00e9gie des latences r\u00e9guli\u00e8res ou un d\u00e9bit maximal. Je documente les valeurs par d\u00e9faut, j\u2019apporte des modifications par petites \u00e9tapes et j\u2019analyse syst\u00e9matiquement les mesures. Il en r\u00e9sulte une configuration qui \u00e9quilibre raisonnablement la charge de travail, le support et le risque, et qui se r\u00e9v\u00e8le sensiblement plus rapide dans la pratique.<\/p>","protected":false},"excerpt":{"rendered":"<p>D\u00e9couvrez comment optimiser de mani\u00e8re cibl\u00e9e les performances d'\u00e9criture et les performances du noyau de votre serveur \u00e0 l'aide des param\u00e8tres \u00ab dirty ratio \u00bb et \u00ab dirty background ratio \u00bb sous Linux, et comment g\u00e9rer efficacement les pages sales.<\/p>","protected":false},"author":1,"featured_media":20851,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20858","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":"135","_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":"linux dirty","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":"20851","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20858","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=20858"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/20858\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/20851"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=20858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=20858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=20858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}