Mise en cache du système de fichiers dans l'hébergement Linux : bien comprendre le cache de page

Le cache de page Linux détermine la vitesse à laquelle les charges de travail d'hébergement lisent et écrivent les fichiers, car il conserve les données fréquemment utilisées dans la mémoire vive, évitant ainsi les accès coûteux aux périphériques. Je vais vous montrer comment. système de fichiers Le cache fonctionne dans l'hébergement Linux, quels sont les indicateurs qui comptent et comment puis-je contrôler le cache au quotidien sans Serveuraugmenter la charge.

Points centraux

• Cache de la page conserve les blocs de fichiers dans la mémoire vive et réduit les latences.
• Pages sales collectent les accès en écriture et les réécrivent de manière groupée.
• LRULes stratégies suppriment les anciennes entrées pour faire place aux nouvelles données.
• Suivi avec free, /proc/meminfo, vmstat, iostat apporte plus de clarté.
• Optimisation grâce à RAM, Logrotate, Opcache et des limites raisonnables.

Qu'est-ce que le cache de page Linux ?

Le cache de page Linux stocke les blocs de fichiers fréquemment lus dans la mémoire vive, accélérant ainsi chaque nouvel accès à Fichiers. J'en profite immédiatement, car les accès à la RAM s'effectuent en quelques microsecondes, tandis que même les SSD rapides ont besoin de quelques millisecondes et sont donc nettement plus lents que Mémoire dans la RAM. Lorsqu'une application ouvre un fichier, le noyau stocke les blocs lus dans le cache et traite les requêtes futures directement à partir de la mémoire vive. Cela fonctionne de manière transparente pour les programmes, je n'ai rien à ajuster ni à reconfigurer. Les charges de travail d'hébergement telles que les serveurs web, PHP-FPM, la livraison d'images ou les processus de lecture de journaux accèdent constamment au cache et économisent des E/S.

Voici comment fonctionne le cache lors de la lecture

Lors de la première lecture d'un fichier, le système charge des blocs dans le cache et les marque comme chauds afin qu'ils restent disponibles en cas d'accès répétés et que les Temps est extrêmement court pour la deuxième exigence. Si je lis deux fois de suite un fichier de 100 Mo, le deuxième passage provient pratiquement entièrement de la RAM. Le noyau utilise pour cela des stratégies telles que LRU (Least Recently Used) et donne la priorité aux entrées utilisées en dernier, afin que les contenus Web actuels restent plus longtemps dans le cache et que les données froides soient supprimées. Cette logique correspond bien aux modèles d'hébergement, car de nombreux visiteurs accèdent de manière répétée à des images, des fichiers CSS et JavaScript identiques, que je peux Cache rapidement. Le taux de réussite augmente avec la taille du cache, c'est-à-dire avec la mémoire RAM disponible.

Écriture et pages sales compréhensibles

Lors de l'écriture, les données sont d'abord enregistrées dans le cache sous forme de « dirty pages », c'est-à-dire de blocs modifiés que le noyau n'a pas encore réécrit sur le support de données et que je peux consulter via Writeback-synchroniser les mécanismes en temps réel. Je peux facilement observer ce comportement en direct : si je crée un fichier de 10 Mo avec dd, les valeurs Dirty augmentent jusqu'à ce que le noyau les écrive en une seule fois sur le SSD. Une synchronisation manuelle force le système à rendre le cache cohérent et remet la métrique « dirty » à zéro. Ce regroupement préserve les E/S, car il combine de nombreuses petites opérations en transferts plus importants, réduisant ainsi la Performance par opération d'écriture. L'approche moderne de réécriture par périphérique permet aux disques parallèles de fonctionner indépendamment et réduit les temps d'attente.

Architecture du cache : Dentry/Inode vs. Page Cache

Pour compléter le tableau, il faut savoir que Linux ne met pas seulement en cache les données de fichiers. Outre le Cache de la page Pour les contenus, il existe des caches Dentry et Inode qui conservent les structures de répertoires, les noms de fichiers et les métadonnées dans la mémoire vive. Ils permettent d'économiser des résolutions de chemin d'accès et des recherches d'inodes coûteuses. Dans free -m ces parts apparaissent dans la valeur mis en cache également, tandis que tampons Je fais plutôt référence aux tampons liés aux périphériques bloc. Dans /proc/meminfo, je peux voir une ventilation plus détaillée (par exemple, dentries, inactive(file), active(file)). Pour les charges de travail d'hébergement comportant de nombreux petits fichiers, ces caches de métadonnées sont essentiels, car ils réduisent encore davantage le nombre d'accès réels aux périphériques par requête HTTP.

Bien lire les chiffres clés

Je vérifie d'abord free -m et observe les colonnes pour cached ainsi que les lignes Mem et Swap afin d'évaluer avec certitude l'effet du cache et la mémoire réelle. Utilisez Je lis dans /proc/meminfo des valeurs telles que Cached, Dirty, Writeback et Buffers, qui, ensemble, donnent une bonne image de l'état de la mémoire. vmstat 1 indique en permanence si le système est en attente en raison d'E/S, et iostat ajoute des détails pour chaque périphérique. Point décisif : Linux utilise la RAM libre comme cache, mais la marque temporairement comme occupée, même si les applications peuvent la récupérer immédiatement en cas de besoin. J'évalue donc toujours la situation globale, y compris Charge de travail et pas seulement un seul chiffre.

Métriques	Source/Commande	Signification	Signal typique
En cache	free -m, /proc/meminfo	Part de RAM pour les données de fichiers	Valeur élevée en cas d'accès fréquents aux fichiers
Sale	/proc/meminfo	Pages non encore réécrites	Augmente lors d'écritures intensives, diminue après la synchronisation
Writeback	/proc/meminfo	Opérations de réécriture actives	Valeurs différentes de zéro pendant la phase de vidange
bi/bo (vmstat)	vmstat 1	E/S bloc en entrée/sortie	Les pics indiquent des échecs de cache ou des vidages
r/s, w/s (iostat)	iostat -xz 1	Opérations de lecture/écriture par seconde	Sauts chez Misses, bruit de fond constant ok

Avantages dans l'hébergement au quotidien

Une mémoire cache bien remplie réduit considérablement les temps d'attente d'E/S et transfère l'accès aux données du support de données vers la RAM, ce qui réduit considérablement la latence des requêtes individuelles et améliore les performances globales. Temps de réponse des sites Web. Les images, fichiers CSS et HTML fréquemment utilisés 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éussite qui compte : plus il y a de répétitions, plus l'avantage est grand. Dans les scénarios à haut degré de parallélisme, le cache soulage le niveau de mémoire et lisse les pics de charge. Pour mieux comprendre les relations entre les caches mémoire, web et proxy, il est utile de consulter Hiérarchies de mise en cache, afin que je puisse utiliser chaque niveau de manière judicieuse et Ressources Ne gaspille pas.

Influencer intelligemment la taille du cache

J'influence l'effet cache de deux manières : plus de RAM et moins d'accès inutiles aux fichiers, afin de libérer de l'espace pour les données chaudes et que le noyau puisse placer les bons blocs dans le Cache Logrotate avec Gzip nettoie les fichiers journaux volumineux, réduit la quantité de fichiers dans la mémoire vive et empêche 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 > /proc/sys/vm/drop_caches qu'à des fins de test, car cela détruit le mélange de cache productif et le Latence augmente brièvement. Au final, c'est la quantité de travail qui est déterminante : mieux elle s'adapte à la RAM, plus les performances restent constantes.

E/S directes, fsync et cohérence

Tous les accès ne passent pas par le cache de page. Certaines charges de travail ouvrent des fichiers avec O_DIRECT ou O_SYNC, contournant ainsi délibérément la mise en cache ou imposant une persistance immédiate. Cela est utile lorsque l'on souhaite éviter la double mise en mémoire tampon (pool de tampons de base de données plus cache de page) ou lorsque la cohérence est plus importante que la latence. Pour les charges de travail Web et multimédia, je m'en tiens généralement à des E/S tamponnées normales, car le taux de réussite l'emporte la plupart du temps. Il est également important de comprendre fsync : les applications qui exécutent fréquemment fsync sur les fichiers journaux entraînent des cycles de réécriture et peuvent générer des pics d'E/S. Je regroupe ces appels lorsque cela est possible ou je définis des intervalles de vidage d'application judicieux afin de réduire le Débit respecter.

Options de montage : relatime, noatime et autres.

Chaque accès au fichier peut actualiser l'Atime (Access Time) et ainsi déclencher des écritures supplémentaires. Avec relatime (aujourd'hui standard), les atimes ne sont ajustés qu'en cas de besoin, ce qui réduit considérablement les E/S. Dans les charges de travail purement web, où aucune logique basée sur les atimes n'est utilisée, je définis souvent noatime, afin de provoquer encore moins d'accès en écriture. Également pertinent dans la pratique : des tailles de blocs adaptées, des barrières par défaut et, si nécessaire, une compression au niveau du système de fichiers, si le modèle et la marge de manœuvre du processeur le permettent. Ces options de montage contribuent directement à un taux de réussite du cache plus élevé, car moins de mises à jour inutiles des métadonnées affectent le Mémoire-Les chemins sont encombrés.

Conteneurs et cgroups : cache de page en mode multi-locataires

Dans l'hébergement de conteneurs, plusieurs charges de travail se partagent le cache de page global. Les limites de mémoire via cgroups définissent la quantité de mémoire anonyme (heap/stack) autorisée par conteneur, mais le cache de fichiers est géré par le noyau hôte. Si un conteneur est très sollicité et lit beaucoup de nouveaux fichiers, il peut supplanter les pages de cache d'autres conteneurs. J'utilise donc des contrôles de mémoire et d'E/S (memory.high, memory.max, io.max) pour lisser les pics de charge et augmenter l'équité. OverlayFS, qui est souvent utilisé dans les conteneurs, apporte des couches de métadonnées supplémentaires. Cela peut affecter la résolution des chemins d'accès et les chemins d'écriture « copy-on-write ». Je mesure spécifiquement si les couches de superposition augmentent sensiblement la latence et j'envisage des montages liés sans couches supplémentaires pour les actifs statiques.

Préchauffage et protection du cache

Après un redémarrage ou après des déploiements importants, le cache est vide. Je peux cibler des hotsets. préchauffer, en lisant une seule fois les ressources très demandées de manière séquentielle. Cela réduit considérablement la latence au démarrage à froid pendant les premières minutes. À l'inverse, j'évite la pollution du cache : je lis les outils de sauvegarde, d'analyse des logiciels malveillants ou de copie séquentielle volumineuse avec une priorité faible (nice/ionice) et, si possible, je les marque comme moins importants (DONTNEED) via Fadvise afin que les pages disparaissent après le passage. Ainsi, le cache pour le trafic web reste concentré sur les éléments vraiment importants. Données.

NUMA et grands hôtes

Sur les systèmes NUMA, la localisation de la mémoire joue un rôle important. Le cache de page se trouve physiquement dans les nœuds, et les accès à distance augmentent la latence. Je veille à ce que les services qui accèdent fréquemment aux fichiers aient une liaison CPU et mémoire cohérente, et je vérifie si zone_reclaim_mode est utile. Dans la pratique, il est souvent utile de regrouper les processus Web et PHP centraux par nœud NUMA, afin que la partie la plus active du cache reste locale. Dans le même temps, je vérifie si les processus Java ou de base de données volumineux ne supplantent pas le cache de page en raison de leurs propres besoins en mémoire. Si c'est le cas, j'augmente la RAM ou je sépare les charges de travail.

NFS et mémoire partagée

Dans les configurations en cluster avec NFS ou des systèmes de fichiers réseau similaires, la mise en cache est plus délicate. Le cache de page agit localement sur l'hôte consommateur, tandis que les modifications sur un autre nœud doivent être invalidées via des protocoles. Je calibre donc les caches d'attributs et les intervalles d'invalidation de manière à préserver la cohérence sans générer trop d'E/S. Pour les ressources Web statiques sur un stockage partagé, il est utile de limiter les revalidations et de concevoir des déploiements atomiques (par exemple, remplacement de répertoires) afin que le cache ne soit pas inutilement vidé. Dans la mesure du possible, je réplique les hotsets sur les nœuds Web individuels afin d'obtenir un maximum de Taux de réussite à atteindre.

Tmpfs et données éphémères

Pour les données temporaires fréquemment consultées, telles que les fichiers de session, les artefacts de compilation ou les files d'attente de téléchargement courtes, j'utilise tmpfs Cela me permet d'économiser complètement les accès aux périphériques et de faire du cache de page le niveau de mémoire principal. Je dimensionne toutefois tmpfs avec prudence : il utilise la RAM (et éventuellement le swap), et des montages tmpfs trop volumineux peuvent prendre la place d'autres caches. Un processus de nettoyage régulier (par exemple systemd-tmpfiles) empêche les données de s'accumuler et de réduire la mémoire vive.

Modèles de charge de travail : petite vs grande, séquentielle vs aléatoire

Le comportement idéal du cache dépend fortement du modèle. De nombreux petits fichiers récurrents tirent le meilleur parti du LRU et d'une proportion élevée. Actif (fichier). En revanche, les fichiers volumineux lus une seule fois (sauvegardes, transcodages multimédias) ne doivent pas occuper une place prépondérante dans le cache. Je règle read_ahead_kb de manière modérée afin d'accélérer les lectures séquentielles sans alourdir les accès aléatoires. Sur les serveurs web contenant de nombreux fichiers statiques, j'active les chemins d'accès zéro copie (sendfile, splice) afin d'éviter les copies dans l'espace utilisateur. Le cache de page fournit alors directement dans le socket, ce qui économise du CPU et réduit la latence.

Observation approfondie et symptômes

Outre vmstat et iostat, je consulte si nécessaire les statistiques de récupération (par exemple Active/Inactive, pgscan/pgsteal via /proc/meminfo) afin de déterminer si le système récupère agressivement page après page. Des erreurs de page majeures fréquentes, des valeurs IO-Wait en hausse et des temps de writeback élevés persistants indiquent que le cache est sous pression. Dans de telles phases, je vérifie d'abord si je peux réduire la charge de travail ou augmenter la RAM. Si les échecs restent élevés, je segmente les données (par exemple, séparation des archives rarement utilisées et des ressources Web fréquemment utilisées) afin que le mécanisme LRU privilégie les blocs appropriés.

Règles empiriques pratiques

• Je planifie le RAM de manière à ce que les hotsets (ressources Web statiques + parties actives des bases de données) puissent y être intégrés 1 à 2 fois. Cela double les chances d'obtenir des cache hits lors des pics de trafic.
• J'évite systématiquement le swapping : dès que des pages anonymes sont externalisées, le pager entre en concurrence avec le cache de page pour les E/S, ce qui entraîne une augmentation des latences. Je maintiens le swappiness à un niveau modéré.
• Je réduis la durée de conservation des fichiers journaux, je compresse les anciennes générations et je m'assure que les journaux bavards ne se disputent pas l'espace dans le cache avec les ressources Web.
• Je regroupe les déploiements qui modifient de nombreux fichiers en quelques étapes atomiques. Ainsi, j'invalide moins d'entrées de cache à la fois et je conserve la Taux de réussite haut.

Systèmes de fichiers et accès au cache

Le système de fichiers influence l'efficacité avec laquelle le noyau stocke et réécrit les données. C'est pourquoi je connais les propriétés d'Ext4, XFS et ZFS et que j'adapte mon choix à mes charges de travail afin que le Cache fonctionne de manière optimale. Ext4 offre des performances globales solides, XFS excelle dans les charges d'écriture parallèles, ZFS apporte ses propres niveaux de mise en cache tels que ARC. Selon le modèle – nombreux petits fichiers ou grands objets multimédias –, les métadonnées et les chemins d'écriture se comportent différemment. Je mesure les charges de travail réelles avant de déterminer la plate-forme. Pour avoir un aperçu concis, je me réfère à l'article Comparaison entre Ext4, XFS et ZFS et alignez les paramètres tels que les options de montage afin que le noyau n'effectue pas de Més produit.

Bases de données, Opcache et Page Cache

Dans MySQL ou MariaDB, le pool de tampons InnoDB prend en charge la majeure partie des pages de données et des index, tandis que le cache de page accélère en plus les blocs du système de fichiers, réduisant ainsi le nombre total d'E/S, ce qui améliore les Requête-Réduction des latences. Je configure le pool de tampons de manière à ce qu'il puisse contenir les hotsets, sinon le moteur génère des accès inutiles au disque dur. Pour les applications PHP, je combine Opcache pour le bytecode et APCu pour les données proches de l'application, ce qui me permet de réduire la pression sur le cache de page. Les ressources statiques restent candidates pour le cache du système de fichiers et se chargent à la vitesse de l'éclair. Cette stratification évite le double travail et maintient la CPU libre pour les parties dynamiques.

Surveillance et diagnostic

Je surveille vmstat 1 pour les indicateurs de mémoire et d'E/S en temps réel, je vérifie iostat -xz 1 par périphérique et je consulte /proc/meminfo pour les indicateurs Dirty, Cached, Writeback afin de pouvoir rapidement identifier les causes et agir de manière ciblée. agissent Une valeur IO-Wait élevée et persistante indique des goulots d'étranglement, que je commence par atténuer à l'aide de la mise en cache et de la RAM. Je vérifie ensuite si le système de fichiers, le RAID ou le micrologiciel SSD ralentissent le système. Si la valeur IO-Wait reste critique, j'analyse les accès aux applications et les taux de réussite de la mise en cache. Pour m'aider à démarrer dans les chemins de diagnostic, j'utilise Comprendre IO-Wait, pour distinguer les symptômes des causes et proposer des traitements ciblés. Étapes déduire.

Paramètres de réglage sans risque

Je ne modifie que quelques paramètres du noyau et je teste les changements de manière contrôlée, car il existe de bons paramètres par défaut et de petites corrections suffisent souvent pour Efficacité . vm.dirty_background_bytes détermine à partir de quel seuil le système commence à écrire de manière asynchrone, tandis que vm.dirty_bytes définit la limite supérieure pour les pages sales. En définissant ces valeurs en octets plutôt qu'en pourcentage, vous obtenez une base stable indépendante de la configuration RAM. De plus, read_ahead_kb influence le préchargement des données par périphérique bloc, ce qui accélère la lecture séquentielle, mais reste neutre en cas d'accès aléatoires. Je documente toutes les étapes et, en cas d'effets secondaires, je reviens rapidement aux paramètres d'origine. Valeurs de retour.

Les fonctionnalités modernes en bref

Les pages transparentes volumineuses (THP) peuvent regrouper les pages soutenues par des fichiers en unités plus grandes, ce qui réduit les coûts de gestion par page et profite à la TLB lorsque les charges de travail sont trop importantes et cohérentes. quantités adaptées. Dans les environnements d'hébergement avec des accès très aléatoires, je vérifie soigneusement l'effet, car les avantages ne sont pas garantis. La mémoire persistante, quant à elle, promet des latences très faibles et ouvre de nouveaux chemins de données qui contournent en partie le flux classique du cache de page. J'observe ici les benchmarks et j'évalue si l'application bénéficie réellement des nouvelles classes de mémoire. Je réalise les premières expériences séparément du En direct-Trafic.

Résumé : ce que je retiens

Le cache de page Linux accélère les charges de travail d'hébergement en transférant les opérations fréquentes sur les fichiers vers la mémoire RAM, ce qui réduit les latences, diminue la charge d'E/S et améliore les performances. Mise à l'échelle amélioré. Je mesure des valeurs significatives, détecte les erreurs d'interprétation avec free -m et utilise /proc/meminfo, vmstat, iostat pour obtenir une image complète. Grâce à Logrotate, une mémoire RAM suffisante, des limites de noyau raisonnables et PHP-Opcache, j'augmente les performances sans interventions risquées. Je choisis les systèmes de fichiers en tenant compte des profils d'accès et j'observe l'attente IO afin de désamorcer les goulots d'étranglement à temps. Je conserve ainsi les accès Web récurrents dans le cache, je soulage le Mémoireet livre rapidement les pages.