{"id":16421,"date":"2025-12-31T18:20:15","date_gmt":"2025-12-31T17:20:15","guid":{"rendered":"https:\/\/webhosting.de\/filesystem-caching-linux-page-cache-cacheboost\/"},"modified":"2025-12-31T18:20:15","modified_gmt":"2025-12-31T17:20:15","slug":"systeme-de-fichiers-mise-en-cache-linux-cache-de-page-cacheboost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/fr\/filesystem-caching-linux-page-cache-cacheboost\/","title":{"rendered":"Mise en cache du syst\u00e8me de fichiers dans l'h\u00e9bergement Linux : bien comprendre le cache de page"},"content":{"rendered":"<p>Le cache de page Linux d\u00e9termine la vitesse \u00e0 laquelle les charges de travail d'h\u00e9bergement lisent et \u00e9crivent les fichiers, car il conserve les donn\u00e9es fr\u00e9quemment utilis\u00e9es dans la m\u00e9moire vive, \u00e9vitant ainsi les acc\u00e8s co\u00fbteux aux p\u00e9riph\u00e9riques. Je vais vous montrer comment. <strong>syst\u00e8me de fichiers<\/strong> Le cache fonctionne dans l'h\u00e9bergement Linux, quels sont les indicateurs qui comptent et comment puis-je contr\u00f4ler le cache au quotidien sans <strong>Serveur<\/strong>augmenter la charge.<\/p>\n\n<h2>Points centraux<\/h2>\n<ul>\n  <li><strong>Cache de la page<\/strong> conserve les blocs de fichiers dans la m\u00e9moire vive et r\u00e9duit les latences.<\/li>\n  <li><strong>Pages sales<\/strong> collectent les acc\u00e8s en \u00e9criture et les r\u00e9\u00e9crivent de mani\u00e8re group\u00e9e.<\/li>\n  <li><strong>LRU<\/strong>Les strat\u00e9gies suppriment les anciennes entr\u00e9es pour faire place aux nouvelles donn\u00e9es.<\/li>\n  <li><strong>Suivi<\/strong> avec free, \/proc\/meminfo, vmstat, iostat apporte plus de clart\u00e9.<\/li>\n  <li><strong>Optimisation<\/strong> gr\u00e2ce \u00e0 RAM, Logrotate, Opcache et des limites raisonnables.<\/li>\n<\/ul>\n\n<h2>Qu'est-ce que le cache de page Linux ?<\/h2>\n<p>Le cache de page Linux stocke les blocs de fichiers fr\u00e9quemment lus dans la m\u00e9moire vive, acc\u00e9l\u00e9rant ainsi chaque nouvel acc\u00e8s \u00e0 <strong>Fichiers<\/strong>. J'en profite imm\u00e9diatement, car les acc\u00e8s \u00e0 la RAM s'effectuent en quelques microsecondes, tandis que m\u00eame les SSD rapides ont besoin de quelques millisecondes et sont donc nettement plus lents que <strong>M\u00e9moire<\/strong> dans la RAM. Lorsqu'une application ouvre un fichier, le noyau stocke les blocs lus dans le cache et traite les requ\u00eates futures directement \u00e0 partir de la m\u00e9moire vive. Cela fonctionne de mani\u00e8re transparente pour les programmes, je n'ai rien \u00e0 ajuster ni \u00e0 reconfigurer. Les charges de travail d'h\u00e9bergement telles que les serveurs web, PHP-FPM, la livraison d'images ou les processus de lecture de journaux acc\u00e8dent constamment au cache et \u00e9conomisent des E\/S.<\/p>\n\n<h2>Voici comment fonctionne le cache lors de la lecture<\/h2>\n<p>Lors de la premi\u00e8re lecture d'un fichier, le syst\u00e8me charge des blocs dans le cache et les marque comme chauds afin qu'ils restent disponibles en cas d'acc\u00e8s r\u00e9p\u00e9t\u00e9s et que les <strong>Temps<\/strong> est extr\u00eamement court pour la deuxi\u00e8me exigence. Si je lis deux fois de suite un fichier de 100 Mo, le deuxi\u00e8me passage provient pratiquement enti\u00e8rement de la RAM. Le noyau utilise pour cela des strat\u00e9gies telles que LRU (Least Recently Used) et donne la priorit\u00e9 aux entr\u00e9es utilis\u00e9es en dernier, afin que les contenus Web actuels restent plus longtemps dans le cache et que les donn\u00e9es froides soient supprim\u00e9es. Cette logique correspond bien aux mod\u00e8les d'h\u00e9bergement, car de nombreux visiteurs acc\u00e8dent de mani\u00e8re r\u00e9p\u00e9t\u00e9e \u00e0 des images, des fichiers CSS et JavaScript identiques, que je peux <strong>Cache<\/strong> rapidement. Le taux de r\u00e9ussite augmente avec la taille du cache, c'est-\u00e0-dire avec la m\u00e9moire RAM disponible.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00c9criture et pages sales compr\u00e9hensibles<\/h2>\n<p>Lors de l'\u00e9criture, les donn\u00e9es sont d'abord enregistr\u00e9es dans le cache sous forme de \u00ab dirty pages \u00bb, c'est-\u00e0-dire de blocs modifi\u00e9s que le noyau n'a pas encore r\u00e9\u00e9crit sur le support de donn\u00e9es et que je peux consulter via <strong>Writeback<\/strong>-synchroniser les m\u00e9canismes en temps r\u00e9el. Je peux facilement observer ce comportement en direct : si je cr\u00e9e un fichier de 10 Mo avec dd, les valeurs Dirty augmentent jusqu'\u00e0 ce que le noyau les \u00e9crive en une seule fois sur le SSD. Une synchronisation manuelle force le syst\u00e8me \u00e0 rendre le cache coh\u00e9rent et remet la m\u00e9trique \u00ab dirty \u00bb \u00e0 z\u00e9ro. Ce regroupement pr\u00e9serve les E\/S, car il combine de nombreuses petites op\u00e9rations en transferts plus importants, r\u00e9duisant ainsi la <strong>Performance<\/strong> par op\u00e9ration d'\u00e9criture. L'approche moderne de r\u00e9\u00e9criture par p\u00e9riph\u00e9rique permet aux disques parall\u00e8les de fonctionner ind\u00e9pendamment et r\u00e9duit les temps d'attente.<\/p>\n\n<h2>Architecture du cache : Dentry\/Inode vs. Page Cache<\/h2>\n<p>Pour compl\u00e9ter le tableau, il faut savoir que Linux ne met pas seulement en cache les donn\u00e9es de fichiers. Outre le <strong>Cache de la page<\/strong> Pour les contenus, il existe des caches Dentry et Inode qui conservent les structures de r\u00e9pertoires, les noms de fichiers et les m\u00e9tadonn\u00e9es dans la m\u00e9moire vive. Ils permettent d'\u00e9conomiser des r\u00e9solutions de chemin d'acc\u00e8s et des recherches d'inodes co\u00fbteuses. Dans <em>free -m<\/em> ces parts apparaissent dans la valeur <strong>mis en cache<\/strong> \u00e9galement, tandis que <strong>tampons<\/strong> Je fais plut\u00f4t r\u00e9f\u00e9rence aux tampons li\u00e9s aux p\u00e9riph\u00e9riques bloc. Dans \/proc\/meminfo, je peux voir une ventilation plus d\u00e9taill\u00e9e (par exemple, dentries, inactive(file), active(file)). Pour les charges de travail d'h\u00e9bergement comportant de nombreux petits fichiers, ces caches de m\u00e9tadonn\u00e9es sont essentiels, car ils r\u00e9duisent encore davantage le nombre d'acc\u00e8s r\u00e9els aux p\u00e9riph\u00e9riques par requ\u00eate HTTP.<\/p>\n\n<h2>Bien lire les chiffres cl\u00e9s<\/h2>\n<p>Je v\u00e9rifie d'abord free -m et observe les colonnes pour cached ainsi que les lignes Mem et Swap afin d'\u00e9valuer avec certitude l'effet du cache et la m\u00e9moire r\u00e9elle. <strong>Utilisez<\/strong> Je lis dans \/proc\/meminfo des valeurs telles que Cached, Dirty, Writeback et Buffers, qui, ensemble, donnent une bonne image de l'\u00e9tat de la m\u00e9moire. vmstat 1 indique en permanence si le syst\u00e8me est en attente en raison d'E\/S, et iostat ajoute des d\u00e9tails pour chaque p\u00e9riph\u00e9rique. Point d\u00e9cisif : Linux utilise la RAM libre comme cache, mais la marque temporairement comme occup\u00e9e, m\u00eame si les applications peuvent la r\u00e9cup\u00e9rer imm\u00e9diatement en cas de besoin. J'\u00e9value donc toujours la situation globale, y compris <strong>Charge de travail<\/strong> et pas seulement un seul chiffre.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e9triques<\/th>\n      <th>Source\/Commande<\/th>\n      <th>Signification<\/th>\n      <th>Signal typique<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>En cache<\/td>\n      <td>free -m, \/proc\/meminfo<\/td>\n      <td>Part de RAM pour les donn\u00e9es de fichiers<\/td>\n      <td>Valeur \u00e9lev\u00e9e en cas d'acc\u00e8s fr\u00e9quents aux fichiers<\/td>\n    <\/tr>\n    <tr>\n      <td>Sale<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>Pages non encore r\u00e9\u00e9crites<\/td>\n      <td>Augmente lors d'\u00e9critures intensives, diminue apr\u00e8s la synchronisation<\/td>\n    <\/tr>\n    <tr>\n      <td>Writeback<\/td>\n      <td>\/proc\/meminfo<\/td>\n      <td>Op\u00e9rations de r\u00e9\u00e9criture actives<\/td>\n      <td>Valeurs diff\u00e9rentes de z\u00e9ro pendant la phase de vidange<\/td>\n    <\/tr>\n    <tr>\n      <td>bi\/bo (vmstat)<\/td>\n      <td>vmstat 1<\/td>\n      <td>E\/S bloc en entr\u00e9e\/sortie<\/td>\n      <td>Les pics indiquent des \u00e9checs de cache ou des vidages<\/td>\n    <\/tr>\n    <tr>\n      <td>r\/s, w\/s (iostat)<\/td>\n      <td>iostat -xz 1<\/td>\n      <td>Op\u00e9rations de lecture\/\u00e9criture par seconde<\/td>\n      <td>Sauts chez Misses, bruit de fond constant ok<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linuxcachemeeting2347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Avantages dans l'h\u00e9bergement au quotidien<\/h2>\n<p>Une m\u00e9moire cache bien remplie r\u00e9duit consid\u00e9rablement les temps d'attente d'E\/S et transf\u00e8re l'acc\u00e8s aux donn\u00e9es du support de donn\u00e9es vers la RAM, ce qui r\u00e9duit consid\u00e9rablement la latence des requ\u00eates individuelles et am\u00e9liore les performances globales. <strong>Temps de r\u00e9ponse<\/strong> des sites Web. Les images, fichiers CSS et HTML fr\u00e9quemment utilis\u00e9s restent dans le cache, de sorte que le serveur Web les sert sans passer par le SSD. En cas de trafic intense, c'est le taux de r\u00e9ussite qui compte : plus il y a de r\u00e9p\u00e9titions, plus l'avantage est grand. Dans les sc\u00e9narios \u00e0 haut degr\u00e9 de parall\u00e9lisme, le cache soulage le niveau de m\u00e9moire et lisse les pics de charge. Pour mieux comprendre les relations entre les caches m\u00e9moire, web et proxy, il est utile de consulter <a href=\"https:\/\/webhosting.de\/fr\/caching-hierarchies-technique-web-hebergement-boost\/\">Hi\u00e9rarchies de mise en cache<\/a>, afin que je puisse utiliser chaque niveau de mani\u00e8re judicieuse et <strong>Ressources<\/strong> Ne gaspille pas.<\/p>\n\n<h2>Influencer intelligemment la taille du cache<\/h2>\n<p>J'influence l'effet cache de deux mani\u00e8res : plus de RAM et moins d'acc\u00e8s inutiles aux fichiers, afin de lib\u00e9rer de l'espace pour les donn\u00e9es chaudes et que le noyau puisse placer les bons blocs dans le <strong>Cache<\/strong> Logrotate avec Gzip nettoie les fichiers journaux volumineux, r\u00e9duit la quantit\u00e9 de fichiers dans la m\u00e9moire vive et emp\u00eache les journaux de supplanter les ressources Web importantes. Dans la mesure du possible, je marque les transferts ponctuels volumineux, tels que les sauvegardes ou les sauvegardes SQL, comme moins pertinents en les traitant en dehors des heures de pointe. Je n'utilise le vidage manuel du cache du noyau avec echo 3 &gt; \/proc\/sys\/vm\/drop_caches qu'\u00e0 des fins de test, car cela d\u00e9truit le m\u00e9lange de cache productif et le <strong>Latence<\/strong> augmente bri\u00e8vement. Au final, c'est la quantit\u00e9 de travail qui est d\u00e9terminante : mieux elle s'adapte \u00e0 la RAM, plus les performances restent constantes.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2025\/12\/linux-page-cache-erklaert-7273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>E\/S directes, fsync et coh\u00e9rence<\/h2>\n<p>Tous les acc\u00e8s ne passent pas par le cache de page. Certaines charges de travail ouvrent des fichiers avec O_DIRECT ou O_SYNC, contournant ainsi d\u00e9lib\u00e9r\u00e9ment la mise en cache ou imposant une persistance imm\u00e9diate. Cela est utile lorsque l'on souhaite \u00e9viter la double mise en m\u00e9moire tampon (pool de tampons de base de donn\u00e9es plus cache de page) ou lorsque la coh\u00e9rence est plus importante que la latence. Pour les charges de travail Web et multim\u00e9dia, je m'en tiens g\u00e9n\u00e9ralement \u00e0 des E\/S tamponn\u00e9es normales, car le taux de r\u00e9ussite l'emporte la plupart du temps. Il est \u00e9galement important de comprendre fsync : les applications qui ex\u00e9cutent fr\u00e9quemment fsync sur les fichiers journaux entra\u00eenent des cycles de r\u00e9\u00e9criture et peuvent g\u00e9n\u00e9rer des pics d'E\/S. Je regroupe ces appels lorsque cela est possible ou je d\u00e9finis des intervalles de vidage d'application judicieux afin de r\u00e9duire le <strong>D\u00e9bit<\/strong> respecter.<\/p>\n\n<h2>Options de montage : relatime, noatime et autres.<\/h2>\n<p>Chaque acc\u00e8s au fichier peut actualiser l'Atime (Access Time) et ainsi d\u00e9clencher des \u00e9critures suppl\u00e9mentaires. Avec <strong>relatime<\/strong> (aujourd'hui standard), les atimes ne sont ajust\u00e9s qu'en cas de besoin, ce qui r\u00e9duit consid\u00e9rablement les E\/S. Dans les charges de travail purement web, o\u00f9 aucune logique bas\u00e9e sur les atimes n'est utilis\u00e9e, je d\u00e9finis souvent <strong>noatime<\/strong>, afin de provoquer encore moins d'acc\u00e8s en \u00e9criture. \u00c9galement pertinent dans la pratique : des tailles de blocs adapt\u00e9es, des barri\u00e8res par d\u00e9faut et, si n\u00e9cessaire, une compression au niveau du syst\u00e8me de fichiers, si le mod\u00e8le et la marge de man\u0153uvre du processeur le permettent. Ces options de montage contribuent directement \u00e0 un taux de r\u00e9ussite du cache plus \u00e9lev\u00e9, car moins de mises \u00e0 jour inutiles des m\u00e9tadonn\u00e9es affectent le <strong>M\u00e9moire<\/strong>-Les chemins sont encombr\u00e9s.<\/p>\n\n<h2>Conteneurs et cgroups : cache de page en mode multi-locataires<\/h2>\n<p>Dans l'h\u00e9bergement de conteneurs, plusieurs charges de travail se partagent le cache de page global. Les limites de m\u00e9moire via cgroups d\u00e9finissent la quantit\u00e9 de m\u00e9moire anonyme (heap\/stack) autoris\u00e9e par conteneur, mais le cache de fichiers est g\u00e9r\u00e9 par le noyau h\u00f4te. Si un conteneur est tr\u00e8s sollicit\u00e9 et lit beaucoup de nouveaux fichiers, il peut supplanter les pages de cache d'autres conteneurs. J'utilise donc des contr\u00f4les de m\u00e9moire et d'E\/S (memory.high, memory.max, io.max) pour lisser les pics de charge et augmenter l'\u00e9quit\u00e9. OverlayFS, qui est souvent utilis\u00e9 dans les conteneurs, apporte des couches de m\u00e9tadonn\u00e9es suppl\u00e9mentaires. Cela peut affecter la r\u00e9solution des chemins d'acc\u00e8s et les chemins d'\u00e9criture \u00ab copy-on-write \u00bb. Je mesure sp\u00e9cifiquement si les couches de superposition augmentent sensiblement la latence et j'envisage des montages li\u00e9s sans couches suppl\u00e9mentaires pour les actifs statiques.<\/p>\n\n<h2>Pr\u00e9chauffage et protection du cache<\/h2>\n<p>Apr\u00e8s un red\u00e9marrage ou apr\u00e8s des d\u00e9ploiements importants, le cache est vide. Je peux cibler des hotsets. <strong>pr\u00e9chauffer<\/strong>, en lisant une seule fois les ressources tr\u00e8s demand\u00e9es de mani\u00e8re s\u00e9quentielle. Cela r\u00e9duit consid\u00e9rablement la latence au d\u00e9marrage \u00e0 froid pendant les premi\u00e8res minutes. \u00c0 l'inverse, j'\u00e9vite la pollution du cache : je lis les outils de sauvegarde, d'analyse des logiciels malveillants ou de copie s\u00e9quentielle volumineuse avec une priorit\u00e9 faible (nice\/ionice) et, si possible, je les marque comme moins importants (DONTNEED) via Fadvise afin que les pages disparaissent apr\u00e8s le passage. Ainsi, le cache pour le trafic web reste concentr\u00e9 sur les \u00e9l\u00e9ments vraiment importants. <strong>Donn\u00e9es<\/strong>.<\/p>\n\n<h2>NUMA et grands h\u00f4tes<\/h2>\n<p>Sur les syst\u00e8mes NUMA, la localisation de la m\u00e9moire joue un r\u00f4le important. Le cache de page se trouve physiquement dans les n\u0153uds, et les acc\u00e8s \u00e0 distance augmentent la latence. Je veille \u00e0 ce que les services qui acc\u00e8dent fr\u00e9quemment aux fichiers aient une liaison CPU et m\u00e9moire coh\u00e9rente, et je v\u00e9rifie si zone_reclaim_mode est utile. Dans la pratique, il est souvent utile de regrouper les processus Web et PHP centraux par n\u0153ud NUMA, afin que la partie la plus active du cache reste locale. Dans le m\u00eame temps, je v\u00e9rifie si les processus Java ou de base de donn\u00e9es volumineux ne supplantent pas le cache de page en raison de leurs propres besoins en m\u00e9moire. Si c'est le cas, j'augmente la RAM ou je s\u00e9pare les charges 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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NFS et m\u00e9moire partag\u00e9e<\/h2>\n<p>Dans les configurations en cluster avec NFS ou des syst\u00e8mes de fichiers r\u00e9seau similaires, la mise en cache est plus d\u00e9licate. Le cache de page agit localement sur l'h\u00f4te consommateur, tandis que les modifications sur un autre n\u0153ud doivent \u00eatre invalid\u00e9es via des protocoles. Je calibre donc les caches d'attributs et les intervalles d'invalidation de mani\u00e8re \u00e0 pr\u00e9server la coh\u00e9rence sans g\u00e9n\u00e9rer trop d'E\/S. Pour les ressources Web statiques sur un stockage partag\u00e9, il est utile de limiter les revalidations et de concevoir des d\u00e9ploiements atomiques (par exemple, remplacement de r\u00e9pertoires) afin que le cache ne soit pas inutilement vid\u00e9. Dans la mesure du possible, je r\u00e9plique les hotsets sur les n\u0153uds Web individuels afin d'obtenir un maximum de <strong>Taux de r\u00e9ussite<\/strong> \u00e0 atteindre.<\/p>\n\n<h2>Tmpfs et donn\u00e9es \u00e9ph\u00e9m\u00e8res<\/h2>\n<p>Pour les donn\u00e9es temporaires fr\u00e9quemment consult\u00e9es, telles que les fichiers de session, les artefacts de compilation ou les files d'attente de t\u00e9l\u00e9chargement courtes, j'utilise <strong>tmpfs<\/strong> Cela me permet d'\u00e9conomiser compl\u00e8tement les acc\u00e8s aux p\u00e9riph\u00e9riques et de faire du cache de page le niveau de m\u00e9moire principal. Je dimensionne toutefois tmpfs avec prudence : il utilise la RAM (et \u00e9ventuellement le swap), et des montages tmpfs trop volumineux peuvent prendre la place d'autres caches. Un processus de nettoyage r\u00e9gulier (par exemple systemd-tmpfiles) emp\u00eache les donn\u00e9es de s'accumuler et de r\u00e9duire la m\u00e9moire vive.<\/p>\n\n<h2>Mod\u00e8les de charge de travail : petite vs grande, s\u00e9quentielle vs al\u00e9atoire<\/h2>\n<p>Le comportement id\u00e9al du cache d\u00e9pend fortement du mod\u00e8le. De nombreux petits fichiers r\u00e9currents tirent le meilleur parti du LRU et d'une proportion \u00e9lev\u00e9e. <strong>Actif (fichier)<\/strong>. En revanche, les fichiers volumineux lus une seule fois (sauvegardes, transcodages multim\u00e9dias) ne doivent pas occuper une place pr\u00e9pond\u00e9rante dans le cache. Je r\u00e8gle read_ahead_kb de mani\u00e8re mod\u00e9r\u00e9e afin d'acc\u00e9l\u00e9rer les lectures s\u00e9quentielles sans alourdir les acc\u00e8s al\u00e9atoires. Sur les serveurs web contenant de nombreux fichiers statiques, j'active les chemins d'acc\u00e8s z\u00e9ro copie (sendfile, splice) afin d'\u00e9viter les copies dans l'espace utilisateur. Le cache de page fournit alors directement dans le socket, ce qui \u00e9conomise du CPU et r\u00e9duit la latence.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Observation approfondie et sympt\u00f4mes<\/h2>\n<p>Outre vmstat et iostat, je consulte si n\u00e9cessaire les statistiques de r\u00e9cup\u00e9ration (par exemple Active\/Inactive, pgscan\/pgsteal via \/proc\/meminfo) afin de d\u00e9terminer si le syst\u00e8me r\u00e9cup\u00e8re agressivement page apr\u00e8s page. Des erreurs de page majeures fr\u00e9quentes, des valeurs IO-Wait en hausse et des temps de writeback \u00e9lev\u00e9s persistants indiquent que le cache est sous pression. Dans de telles phases, je v\u00e9rifie d'abord si je peux r\u00e9duire la charge de travail ou augmenter la RAM. Si les \u00e9checs restent \u00e9lev\u00e9s, je segmente les donn\u00e9es (par exemple, s\u00e9paration des archives rarement utilis\u00e9es et des ressources Web fr\u00e9quemment utilis\u00e9es) afin que le m\u00e9canisme LRU privil\u00e9gie les blocs appropri\u00e9s.<\/p>\n\n<h2>R\u00e8gles empiriques pratiques<\/h2>\n<ul>\n  <li>Je planifie le <strong>RAM<\/strong> de mani\u00e8re \u00e0 ce que les hotsets (ressources Web statiques + parties actives des bases de donn\u00e9es) puissent y \u00eatre int\u00e9gr\u00e9s 1 \u00e0 2 fois. Cela double les chances d'obtenir des cache hits lors des pics de trafic.<\/li>\n  <li>J'\u00e9vite syst\u00e9matiquement le swapping : d\u00e8s que des pages anonymes sont externalis\u00e9es, le pager entre en concurrence avec le cache de page pour les E\/S, ce qui entra\u00eene une augmentation des latences. Je maintiens le swappiness \u00e0 un niveau mod\u00e9r\u00e9.<\/li>\n  <li>Je r\u00e9duis la dur\u00e9e de conservation des fichiers journaux, je compresse les anciennes g\u00e9n\u00e9rations et je m'assure que les journaux bavards ne se disputent pas l'espace dans le cache avec les ressources Web.<\/li>\n  <li>Je regroupe les d\u00e9ploiements qui modifient de nombreux fichiers en quelques \u00e9tapes atomiques. Ainsi, j'invalide moins d'entr\u00e9es de cache \u00e0 la fois et je conserve la <strong>Taux de r\u00e9ussite<\/strong> haut.<\/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\/2025\/12\/linux-pagecache-server-7192.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Syst\u00e8mes de fichiers et acc\u00e8s au cache<\/h2>\n<p>Le syst\u00e8me de fichiers influence l'efficacit\u00e9 avec laquelle le noyau stocke et r\u00e9\u00e9crit les donn\u00e9es. C'est pourquoi je connais les propri\u00e9t\u00e9s d'Ext4, XFS et ZFS et que j'adapte mon choix \u00e0 mes charges de travail afin que le <strong>Cache<\/strong> fonctionne de mani\u00e8re optimale. Ext4 offre des performances globales solides, XFS excelle dans les charges d'\u00e9criture parall\u00e8les, ZFS apporte ses propres niveaux de mise en cache tels que ARC. Selon le mod\u00e8le \u2013 nombreux petits fichiers ou grands objets multim\u00e9dias \u2013, les m\u00e9tadonn\u00e9es et les chemins d'\u00e9criture se comportent diff\u00e9remment. Je mesure les charges de travail r\u00e9elles avant de d\u00e9terminer la plate-forme. Pour avoir un aper\u00e7u concis, je me r\u00e9f\u00e8re \u00e0 l'article <a href=\"https:\/\/webhosting.de\/fr\/ext4-xfs-zfs-hebergement-comparaison-des-performances-stockage\/\">Comparaison entre Ext4, XFS et ZFS<\/a> et alignez les param\u00e8tres tels que les options de montage afin que le noyau n'effectue pas de <strong>M\u00e9s<\/strong> produit.<\/p>\n\n<h2>Bases de donn\u00e9es, Opcache et Page Cache<\/h2>\n<p>Dans MySQL ou MariaDB, le pool de tampons InnoDB prend en charge la majeure partie des pages de donn\u00e9es et des index, tandis que le cache de page acc\u00e9l\u00e8re en plus les blocs du syst\u00e8me de fichiers, r\u00e9duisant ainsi le nombre total d'E\/S, ce qui am\u00e9liore les <strong>Requ\u00eate<\/strong>-R\u00e9duction des latences. Je configure le pool de tampons de mani\u00e8re \u00e0 ce qu'il puisse contenir les hotsets, sinon le moteur g\u00e9n\u00e8re des acc\u00e8s inutiles au disque dur. Pour les applications PHP, je combine Opcache pour le bytecode et APCu pour les donn\u00e9es proches de l'application, ce qui me permet de r\u00e9duire la pression sur le cache de page. Les ressources statiques restent candidates pour le cache du syst\u00e8me de fichiers et se chargent \u00e0 la vitesse de l'\u00e9clair. Cette stratification \u00e9vite le double travail et maintient la <strong>CPU<\/strong> libre pour les parties dynamiques.<\/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\/2025\/12\/linux_cache_office_4832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Surveillance et diagnostic<\/h2>\n<p>Je surveille vmstat 1 pour les indicateurs de m\u00e9moire et d'E\/S en temps r\u00e9el, je v\u00e9rifie iostat -xz 1 par p\u00e9riph\u00e9rique et je consulte \/proc\/meminfo pour les indicateurs Dirty, Cached, Writeback afin de pouvoir rapidement identifier les causes et agir de mani\u00e8re cibl\u00e9e. <strong>agissent<\/strong> Une valeur IO-Wait \u00e9lev\u00e9e et persistante indique des goulots d'\u00e9tranglement, que je commence par att\u00e9nuer \u00e0 l'aide de la mise en cache et de la RAM. Je v\u00e9rifie ensuite si le syst\u00e8me de fichiers, le RAID ou le micrologiciel SSD ralentissent le syst\u00e8me. Si la valeur IO-Wait reste critique, j'analyse les acc\u00e8s aux applications et les taux de r\u00e9ussite de la mise en cache. Pour m'aider \u00e0 d\u00e9marrer dans les chemins de diagnostic, j'utilise <a href=\"https:\/\/webhosting.de\/fr\/comprendre-lattente-de-s-resoudre-le-goulot-detranglement-de-la-memoire-optimisation\/\">Comprendre IO-Wait<\/a>, pour distinguer les sympt\u00f4mes des causes et proposer des traitements cibl\u00e9s. <strong>\u00c9tapes<\/strong> d\u00e9duire.<\/p>\n\n<h2>Param\u00e8tres de r\u00e9glage sans risque<\/h2>\n<p>Je ne modifie que quelques param\u00e8tres du noyau et je teste les changements de mani\u00e8re contr\u00f4l\u00e9e, car il existe de bons param\u00e8tres par d\u00e9faut et de petites corrections suffisent souvent pour <strong>Efficacit\u00e9<\/strong> . vm.dirty_background_bytes d\u00e9termine \u00e0 partir de quel seuil le syst\u00e8me commence \u00e0 \u00e9crire de mani\u00e8re asynchrone, tandis que vm.dirty_bytes d\u00e9finit la limite sup\u00e9rieure pour les pages sales. En d\u00e9finissant ces valeurs en octets plut\u00f4t qu'en pourcentage, vous obtenez une base stable ind\u00e9pendante de la configuration RAM. De plus, read_ahead_kb influence le pr\u00e9chargement des donn\u00e9es par p\u00e9riph\u00e9rique bloc, ce qui acc\u00e9l\u00e8re la lecture s\u00e9quentielle, mais reste neutre en cas d'acc\u00e8s al\u00e9atoires. Je documente toutes les \u00e9tapes et, en cas d'effets secondaires, je reviens rapidement aux param\u00e8tres d'origine. <strong>Valeurs<\/strong> de retour.<\/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\/2025\/12\/linux_pagecache_schreibtisch4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Les fonctionnalit\u00e9s modernes en bref<\/h2>\n<p>Les pages transparentes volumineuses (THP) peuvent regrouper les pages soutenues par des fichiers en unit\u00e9s plus grandes, ce qui r\u00e9duit les co\u00fbts de gestion par page et profite \u00e0 la TLB lorsque les charges de travail sont trop importantes et coh\u00e9rentes. <strong>quantit\u00e9s<\/strong> adapt\u00e9es. Dans les environnements d'h\u00e9bergement avec des acc\u00e8s tr\u00e8s al\u00e9atoires, je v\u00e9rifie soigneusement l'effet, car les avantages ne sont pas garantis. La m\u00e9moire persistante, quant \u00e0 elle, promet des latences tr\u00e8s faibles et ouvre de nouveaux chemins de donn\u00e9es qui contournent en partie le flux classique du cache de page. J'observe ici les benchmarks et j'\u00e9value si l'application b\u00e9n\u00e9ficie r\u00e9ellement des nouvelles classes de m\u00e9moire. Je r\u00e9alise les premi\u00e8res exp\u00e9riences s\u00e9par\u00e9ment du <strong>En direct<\/strong>-Trafic.<\/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\/2025\/12\/linux-hosting-cache-9481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>R\u00e9sum\u00e9 : ce que je retiens<\/h2>\n<p>Le cache de page Linux acc\u00e9l\u00e8re les charges de travail d'h\u00e9bergement en transf\u00e9rant les op\u00e9rations fr\u00e9quentes sur les fichiers vers la m\u00e9moire RAM, ce qui r\u00e9duit les latences, diminue la charge d'E\/S et am\u00e9liore les performances. <strong>Mise \u00e0 l'\u00e9chelle<\/strong> am\u00e9lior\u00e9. Je mesure des valeurs significatives, d\u00e9tecte les erreurs d'interpr\u00e9tation avec free -m et utilise \/proc\/meminfo, vmstat, iostat pour obtenir une image compl\u00e8te. Gr\u00e2ce \u00e0 Logrotate, une m\u00e9moire RAM suffisante, des limites de noyau raisonnables et PHP-Opcache, j'augmente les performances sans interventions risqu\u00e9es. Je choisis les syst\u00e8mes de fichiers en tenant compte des profils d'acc\u00e8s et j'observe l'attente IO afin de d\u00e9samorcer les goulots d'\u00e9tranglement \u00e0 temps. Je conserve ainsi les acc\u00e8s Web r\u00e9currents dans le cache, je soulage le <strong>M\u00e9moire<\/strong>et livre rapidement les pages.<\/p>","protected":false},"excerpt":{"rendered":"<p>Mise en cache du syst\u00e8me de fichiers dans l'h\u00e9bergement Linux : bien comprendre le cache de page Linux et optimiser les performances du serveur.<\/p>","protected":false},"author":1,"featured_media":16414,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-16421","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":"1607","_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":null,"_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 Page 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":"16414","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16421","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=16421"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/posts\/16421\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media\/16414"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/media?parent=16421"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/categories?post=16421"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/fr\/wp-json\/wp\/v2\/tags?post=16421"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}