Explication de vm.vfs_cache_pressure – Optimiser l'utilisation du cache du système de fichiers sous Linux

Je vais vous montrer comment le paramètre du noyau vm.vfs_cache_pressure la pondération du cache VFS par rapport au cache de page, et quelles valeurs permettent d'accélérer le système avec un profil de charge réel. En suivant des étapes claires, j'ajuste ce paramètre, je mesure les effets et j'exploite ainsi le Cache du système de fichiers optimal.

Points centraux

Pour vous permettre de démarrer rapidement, je vais résumer les points essentiels concernant le réglage du Caches VFS ensemble. Ainsi, lorsque je choisis une valeur, je garde à l'esprit son impact sur les requêtes de métadonnées, la charge d'E/S et la pression sur la mémoire vive. Ces points m'aident à optimiser les rôles de serveur courants de manière sûre et reproductible.

• Principe d'action: Détermine avec quelle fermeté le noyau libère les Dentries/Inodes par rapport au cache de pages.
• réglage par défaut: 100 correspond à un ajustement équilibré, sans favoritisme.
• Valeurs faibles: Une valeur comprise entre 50 et 80 permet de conserver plus longtemps les métadonnées en mémoire vive (RAM) et d'accélérer la recherche de fichiers.
• Valeurs élevées: Les caches VFS de 120 à 200 libèrent plus rapidement de l'espace et font de la place pour les processus.
• Cabinet médical: Modifier progressivement, mesurer, documenter – puis seulement ensuite poursuivre l'ajustement.

J'applique ces principes de manière cohérente afin de trouver le juste équilibre entre Taux de réussite de la cache et la mémoire RAM disponible. Ensuite, j'ajuste la valeur de vm.vfs_cache_pressure par petits paliers, j'observe les pics de charge et j'apporte des corrections si nécessaire. Cela me permet d'obtenir des temps de réponse stables sans goulots d'étranglement inattendus au niveau de la mémoire.

Qu'est-ce que vm.vfs_cache_pressure ?

Ce paramètre détermine le niveau de rigueur avec lequel le noyau traite le Cache VFS par rapport à d'autres mémoires, il libère de l'espace dès que la mémoire vive vient à manquer. Le cache VFS contient des dentries et des inodes, c'est-à-dire des entrées de répertoire et des métadonnées de fichiers, qui accélèrent sensiblement la recherche de fichiers. Une valeur de 100 traite le cache VFS et le cache de page de la même manière, tandis que des valeurs plus faibles privilégient le maintien des métadonnées en RAM. Des valeurs plus élevées incitent le noyau à rejeter plus tôt les entrées VFS et à libérer plus rapidement de la mémoire. J’utilise ce levier de manière ciblée pour maintenir un taux élevé de correspondances de métadonnées dans les charges de travail Web, de fichiers et de CMS, sans évincer de processus. Je contrôle ainsi l’équilibre entre Vitesse de recherche et la mémoire vive disponible de manière très directe.

Comment fonctionne le cache VFS en détail ?

Le système de fichiers virtuel constitue une couche commune pour ext4, XFS, Btrfs et autres, et stocke Dentries et les inodes en mémoire vive, afin que l'analyse des répertoires et les accès récurrents restent rapides. Le cache de pages, quant à lui, contient les blocs de fichiers proprement dits ; ces deux caches se complètent, mais se disputent la mémoire en cas de pression. Plus il y a de petits fichiers et d’accès répétitifs, plus l’application tire profit d’un taux de réussite élevé au niveau des métadonnées. C’est précisément là qu’intervient vm.vfs_cache_pressure : je contrôle si Linux conserve ces métadonnées ou les évince rapidement. Pour approfondir certains aspects du cache de pages, j’utilise en complément le compact Optimiseur de performances du cache de pages comme connaissances de base, afin de pouvoir évaluer le VFS et le cache de pages dans leur contexte.

Valeur par défaut et plages de valeurs typiques

Sur la plupart des systèmes, la valeur est définie sur 100 ce qui constitue ainsi une base équilibrée pour les premiers tests. Si je réduis cette valeur, je privilégie les métadonnées et optimise la rapidité des recherches, ce qui s’avère particulièrement utile en présence de nombreux petits fichiers. Si j’augmente cette valeur, Linux supprime plus rapidement les entrées VFS et libère davantage de mémoire tampon pour les applications ou le cache de pages. Je ne manipule les valeurs extrêmes telles que 0 ou celles supérieures à 500 qu’avec beaucoup de prudence, car elles peuvent entraîner un comportement inhabituel et provoquer des effets secondaires. Au quotidien, je commence à 100, j’avance par paliers de 20 à 40 points et je mesure l’impact sur Latence d'E/S et les délais de réponse.

Valeur	Signification	Quand utiliser	Risque/Remarque
< 100 (par exemple 50–80)	Le cache VFS reste plus longtemps dans la mémoire vive	De nombreux petits fichiers, des recherches fréquentes	Augmentation de l'utilisation de la mémoire vive (RAM) Métadonnées
100	Ajustement équilibré	Valeur de départ fiable pour les mesures	Bon Ligne de basevaleur -
> 100 (par exemple 120–200)	Le cache VFS est libéré de manière plus agressive	Mémoire vive insuffisante, bases de données disposant de leur propre cache	Latence potentielle de la recherche
Extrême (0, > 500)	Des changements majeurs	Cas particuliers : test rapide	Menace pour la stabilité et Performance

Grâce à cette grille, je repère rapidement la bonne direction sans m'égarer. J'évite les changements trop brusques et je consigne chaque modification en détail. Ainsi, le chemin parcouru reste toujours clair et je peux facilement comparer les résultats avec les points de mesure précédents.

Rôle dans le nettoyage de la mémoire

En cas de pression, le noyau doit libérer de la mémoire vive, et c'est précisément là que vm.vfs_cache_pressure définit la pondération entre Cache VFS, le cache de pages et la mémoire des processus. Des valeurs faibles permettent de conserver plus longtemps en mémoire les entrées de répertoires et d’inodes, ce qui accélère les accès aux répertoires et les ouvertures répétées de fichiers. Des valeurs élevées libèrent la mémoire plus tôt et libèrent davantage d’espace pour les processus ou le cache de pages, ce qui peut s’avérer utile lorsque la mémoire vive est limitée. Je surveille tout particulièrement les latences d’E/S, car un cache de métadonnées trop vide ralentit la recherche de fichiers. En ce qui concerne l’interaction avec les stratégies de libération du cache de pages, cela me fournit des informations sur Éviction du cache de pages des références pratiques utiles, afin que je puisse prendre des décisions fondées sur des faits.

Méthodologie de mesure : rendre le cache VFS transparent

Avant de modifier, je mets en évidence, où se trouve dans la mémoire et ce que est supplanté. Cela me permet de déterminer si les métadonnées constituent réellement le goulot d'étranglement, ou si ce sont plutôt le cache de page, les processus ou les pages sales qui prédominent.

• /proc/meminfo: Je vérifie les paramètres InodeCache, Cached, Buffers, SReclaimable et SUnreclaim afin d'évaluer leur proportion et leur récupérabilité.
• slabtop: Aperçu en temps réel des « slabs », notamment dentry, inode_cache, ext4_inode_cache et xfs_inode. Cela me permet de voir si les dentries et les inodes augmentent ou diminuent.
• Chemin d'accès IO: À l'aide de vmstat/iostat, je surveille les temps de latence en lecture et je vérifie si les accès au disque augmentent lors des recherches.

# Aperçu rapide
grep -E 'InodeCache|SReclaimable|SUnreclaim|Cached|Buffers' /proc/meminfo

# Répartition des slabs (triée par taille)
sudo slabtop -s c

# Filtrer uniquement les slabs de type dentry/inode
grep -Ei 'dentry|inode' /proc/slabinfo | sort -k3 -nr | head

# Tendances des E/S et de la mémoire toutes les secondes
vmstat 1
iostat -x 1

Je trouve cette interprétation claire : si SReclaimable augmente parallèlement aux blocs dentry/inode et que, dans le même temps, les latences d'E/S augmentent pas, cela confirme l'efficacité du cache de métadonnées. Si ces valeurs tombent fréquemment à zéro et remontent rapidement lors des accès au répertoire, cela signifie probablement que vm.vfs_cache_pressure est trop agressif.

Exemple pratique : lire et modifier la valeur actuelle

La vérification s'effectue en quelques secondes depuis la ligne de commande, sans Redémarrage. Je lis la valeur réelle et j'enregistre d'abord les valeurs de test de manière temporaire, afin de pouvoir immédiatement mettre en œuvre des retours en arrière dans la fenêtre de test. Pour les ajustements en production, je modifie le fichier /etc/sysctl.conf ou un fichier dans /etc/sysctl.d/, je recharge le système et je consigne la modification dans ma documentation. Je teste chaque niveau sous une charge réaliste, et pas seulement en veille, afin que les effets soient visibles. Je m’assure ainsi d’obtenir des comparaisons « avant-après » fiables et j’évalue la modification à l’aide d’indicateurs mesurables.

# Vérifier la valeur actuelle
cat /proc/sys/vm/vfs_cache_pressure
# ou
sysctl vm.vfs_cache_pressure

# Test temporaire (jusqu'au redémarrage)
sudo sysctl -w vm.vfs_cache_pressure=60
# Autre méthode
echo 60 | sudo tee /proc/sys/vm/vfs_cache_pressure

# Définir de manière permanente
echo "vm.vfs_cache_pressure = 60" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Optimisation du cache sous Linux : scénarios pertinents

Dans les plateformes d'hébergement comportant de nombreuses ressources statiques, des référentiels de fichiers ou des applications dotées de leur propre mémoire tampon, il est judicieux de mettre en place une pondération du cache VFS. Les serveurs web contenant de nombreux petits fichiers tirent grandement profit de valeurs plus faibles, car les recherches sur le SSD/HDD sont moins fréquentes. Les serveurs de fichiers contenant des fichiers de tailles variées peuvent utiliser des valeurs modérément réduites si la mémoire vive est suffisante. Les serveurs de bases de données soumis à une forte pression sur la mémoire vive et disposant d’un cache de base de données important privilégient des valeurs plus élevées afin de laisser de la place aux processus. J’évalue ces modèles à chaque fois à l’aide de données de surveillance afin que les paramètres correspondent à la composition réelle des accès.

Serveur web contenant de nombreux fichiers statiques

Pour les fichiers CSS, JS et les images, je préfère conserver les métadonnées plus longtemps dans le Cache. Des valeurs comprises entre 50 et 80 ont souvent fait leurs preuves, car la réouverture des fichiers s'effectue plus rapidement. J'examine de près les pics d'E/S lors des pics de trafic et je compare les temps de réponse avant et après la modification. Si les latences restent stables et que les coûts de recherche 404 diminuent, c’est que nous sommes sur la bonne voie. Je surveille l’utilisation de la mémoire vive afin que les processus disposent de suffisamment d’espace malgré un cache de métadonnées plus important.

Serveurs de fichiers ou systèmes NAS

Les accès fréquents des utilisateurs et les changements de répertoire bénéficient de plus bas jusqu’à obtenir des valeurs équilibrées. Si la mémoire vive est suffisante, je vise plutôt une valeur comprise entre 50 et 80 ; si la mémoire est plus limitée, je reste plus proche de 100. Je vérifie que l’affichage des répertoires reste fluide et que les instantanés/sauvegardes ne saturent pas trop les caches. Si la latence d’E/S augmente lors des pics d’activité, j’ajuste prudemment cette valeur à la hausse. Je préserve ainsi l’équilibre entre confort d’utilisation et mémoire disponible.

Serveurs de bases de données et systèmes à faible capacité de stockage

Les bases de données gèrent leur propre cache tampon, c'est pourquoi j'attribue au mémoire de processus a généralement la priorité. Des valeurs comprises entre 120 et 200 indiquent qu’il faut plutôt vider les caches VFS afin de libérer de la mémoire vive. Je surveille alors les latences des requêtes et les schémas de « page fault » de l’application. Si la base de données est ralentie parce que le système commence à recourir au swap, j’augmente légèrement cette valeur et réduis par la même occasion vm.swappiness. Cette approche empêche les métadonnées d’occuper inutilement de l’espace que la base de données pourrait mieux exploiter.

Exemples de charges de travail et valeurs indicatives

Je commence à 100, puis je réduis par paliers de 20 pour les valeurs proches de la valeur web Charges de travail et j'augmente par paliers de 20 pour les processus gourmands en mémoire. Je teste chaque palier au moins pendant une phase de pic afin de détecter les effets sur les latences, les coups de cache et l'activité de swap. Ceux qui souhaitent approfondir le sujet trouveront dans le guide concis Optimiseur de performances du cache de pages Informations complémentaires sur les stratégies de mise en cache des fichiers, que je prends en compte en parallèle. Lorsque les valeurs mesurées correspondent aux objectifs fixés, je fige la configuration et je consigne les indicateurs clés. L'optimisation reste ainsi reproductible et je peux procéder rapidement à des ajustements ultérieurs.

Risques et pièges

Si je définis une valeur trop faible, le noyau peut difficilement libérer les entrées VFS, ce qui, en cas de pics, peut entraîner OOM‑risques. Si je l’augmente trop, la latence augmente lors des recherches de fichiers et des changements de répertoire, car les métadonnées doivent être rechargées. Sans tests sous charge réelle, on risque de tirer des conclusions erronées à partir de périodes de faible activité. Les variations brusques compliquent l’évaluation, c’est pourquoi je procède par étapes. Je note chaque modification avec l’heure, le profil de charge et les valeurs mesurées, afin que les causes restent claires.

Suivi et indicateurs

Ce sont des données concrètes qui permettent de déterminer si un ajustement en vaut la peine Métriques. Je surveille l'utilisation de la mémoire vive (RAM), la répartition entre les caches et les processus, les latences d'E/S et l'activité de la mémoire swap. De plus, j’analyse les taux de réussite des caches et les tendances des erreurs de page afin d’identifier rapidement les effets secondaires. C’est notamment avec de nombreux petits fichiers que les améliorations du « Time-to-First-Byte » sont les plus perceptibles. Si la latence d’E/S reste faible et que le swap diminue, cela confirme que nous sommes sur la bonne voie.

Guide de réglage : de l'hypothèse au réglage fiable

Cette structure permet d'éviter d'avancer à l'aveuglette. Je suis une procédure bien définie afin que les résultats soient fiables et que mes collègues puissent comprendre les différentes étapes.

1. Saisir la valeur de référence: vm.vfs_cache_pressure=100, charge réaliste pendant 24 à 72 heures. Enregistrer les indicateurs clés (latences : médiane/95e/99e, temps d'attente IO, CPU Steal, activité de swap, taille des inodes/dentries).
2. Formuler une hypothèse: „ De nombreux petits fichiers, les recherches sont coûteuses – des valeurs plus basses accélèrent le système “ ou „ Mémoire vive insuffisante – des valeurs plus élevées permettent de libérer des processus “.
3. Modifier étape par étape: de ±20 à ±40 points. Mesurer au moins une phase de crête par niveau.
4. Comparer: Je vérifie si les SLO (par exemple, le 95e centile) s'améliorent de manière fiable, sans plus d'événements liés à la mémoire swap ou à l'épuisement de la mémoire (OOM).
5. Critère de retour en arrière: Si les latences 95e et 99e augmentent, si les temps d'attente des E/S s'allongent ou si les échecs de cache se multiplient, je fais un pas en arrière.
6. Freeze et documentation: Enregistrer la valeur finale, la date, la plage de charge et les indicateurs clés.

# Test rapide pour les fenêtres de mesure contrôlées (maintenance uniquement !)
# Avant : enregistrement des indicateurs clés
date ; free -h ; grep -E 'InodeCache|Cached' /proc/meminfo ; vmstat 1 5

sudo sysctl -w vm.vfs_cache_pressure=80
# Test de charge / attendre le pic, puis enregistrer à nouveau les métriques et les comparer

Systèmes de fichiers et options de montage : tout est une question de contexte

L'effet de la commande `vm.vfs_cache_pressure` dépend également du système de fichiers et des options de montage. J'évalue ces facteurs comme suit :

• relatime/noatime: Empêche les écritures atime fréquentes. L'option noatime réduit la charge d'E/S en cas de lectures nombreuses, ce qui rend les avantages liés aux métadonnées plus visibles.
• lazytime: Retarde les mises à jour des métadonnées en mémoire vive ; cela permet de lisser les pics, mais interagit avec les moments de vidage.
• ext4, XFS et Btrfs: Différentes structures d'inodes et comportements de Shrinker. Je mesure toujours sur le FS de destination, plutôt que de reprendre des hypothèses.
• NFS/Fichier de réseau: La mise en cache et l'invalidation des attributs peuvent limiter les avantages du VFS. Une libération agressive (valeurs élevées) entraîne alors une augmentation des recherches à distance.
• OverlayFS/FUSE: De nombreuses petites opérations liées aux métadonnées tirent largement parti du cache VFS ; je considère que ces valeurs sont plutôt modérées à faibles, à condition de disposer de mémoire vive suffisante.

Aspects liés aux conteneurs et aux cgroups

Dans les environnements de conteneurs, je garde à l'esprit que vm.vfs_cache_pressure est un à l'échelle de l'hébergeur Bouton. Les modifications concernent tous Pods/conteneurs sur le nœud. Je préfère donc adopter une approche prudente et coordonner l'optimisation au niveau du nœud.

• Limites de stockage: Les Memory-Cgroups limitent la mémoire des processus et le cache de pages ; la mémoire Slab peut être prise en compte proportionnellement. J'observe des événements Pod-OOM et Node-Pressure en lien avec cela.
• Composition de la charge de travail: Les nœuds qui hébergent à la fois des pods de base de données et des interfaces web n'enregistrent pas de valeurs extrêmes. Si nécessaire, je répartis les rôles sur différents nœuds.
• Déploiement: D'abord Canaries (un nœud), puis déploiement progressif. Je consigne les modifications dans la baseline des nœuds (sysctl.d) et je note les déploiements concernés.

Cas particuliers de la pratique

Il est possible de s'attaquer de manière ciblée à certains schémas lorsque j'en connais les causes :

• Tâches CI/Build: Les opérations impliquant de nombreux accès courts aux fichiers et les analyses de répertoires tirent parti de valeurs plus faibles. Je les augmente à nouveau une fois la tâche terminée, si les nœuds sont utilisés à des fins diverses.
• Fenêtre de sauvegarde/analyse: Les parcourus de répertoires de longue durée effacent les caches. Temporairement, un plus élevé Valeur (par exemple 180) pour empêcher, pendant la sauvegarde, que les dentries/inodes ne saturent la mémoire vive – je la réinitialise ensuite.
• Entrées négatives: Les fichiers inexistants (404) sont également mis en cache. Les charges de travail Web présentant de fréquents accès infructueux gagnent en performances de manière mesurable si le cache VFS n'est pas vidé de manière trop agressive.
• Streaming/E/S séquentielle: C'est le cache de pages qui prédomine ici ; des valeurs trop faibles n'apportent pas grand-chose et mobilisent inutilement de la mémoire vive. Je reste proche de 100 ou légèrement au-dessus.

# Exemple : adopter une approche un peu plus agressive pendant une sauvegarde complète
sudo sysctl -w vm.vfs_cache_pressure=180
# Revenir à la valeur optimale déterminée précédemment après la sauvegarde
sudo sysctl -w vm.vfs_cache_pressure=60

Automatisation et gouvernance

Une fois les tests réussis, j'intègre ce paramètre dans mes builds standard. Il est important que les équipes sachent que, pourquoi une valeur a été sélectionnée et quand qui doit être vérifié (par exemple, après un changement de version ou de charge de travail).

• Gestion de la configuration: Je définis des valeurs par défaut pour chaque rôle (Web, base de données, serveur de fichiers) dans /etc/sysctl.d/ et je les distribue de manière centralisée.
• Contrôle de la dérive: Des audits réguliers permettent de vérifier si les valeurs en production correspondent à celles du référentiel.
• Runbooks: Je consigne les étapes de mesure, les seuils de rollback et les procédures d'urgence (par exemple, le réinitialisation à 100).

# Rôle : serveur web (exemple)
cat <<'EOF' | sudo tee /etc/sysctl.d/50-web-vfs.conf
vm.vfs_cache_pressure = 60
EOF
sudo sysctl --system

vm.vfs_cache_pressure et autres paramètres du noyau

Un bon résultat ne peut être obtenu qu'en interaction avec vm.swappiness et les seuils de pages sales. Une valeur de swappiness plus faible (par exemple, 10 à 20) a tendance à maintenir les processus en mémoire vive et évite les transferts inutiles vers le disque. Avec vm.dirty_background_ratio et vm.dirty_ratio, je régle la rapidité avec laquelle le système écrit les pages modifiées, afin que les pics d’écriture ne bloquent pas tout le système. Je règle ces valeurs de manière à ce que les recherches de métadonnées restent rapides et que les opérations d’écriture se déroulent de manière prévisible. Je me sers ici d’un aperçu concis de l’interaction entre les caches de fichiers : Présentation de la mise en cache du système de fichiers.

Recommandations concernant les environnements d'hébergement et WordPress

De nombreux thèmes, plugins et fichiers multimédias génèrent d'innombrables petits fichiers, ce qui explique pourquoi un puissant Cache VFS Cela aide nettement. Je commence par 100, je descends à 80 si la mémoire vive est suffisante, puis à 60, et je vérifie les temps de réponse, le 95e centile des latences et le CPU-Steal. Si la mémoire reste suffisante, je teste la valeur 50 et je valide à nouveau les résultats pendant les pics du soir ou lors des campagnes. Si les latences diminuent sans que le swap ou l’OOM Killer ne se déclenchent, je conserve ce paramètre de manière permanente. En parallèle, je surveille le cache de page afin que les deux caches se complètent de manière optimale.

Résumé

La commande vm.vfs_cache_pressure me permet de contrôler la Balance de manière très ciblée, en fonction des recherches rapides de métadonnées et de la mémoire RAM disponible. Pour les charges de travail liées au Web, je réduis modérément cette valeur ; pour les applications gourmandes en mémoire, je l’augmente. Je justifie chaque modification par des mesures concernant les latences d’E/S, les coups au cache et l’activité d’échange. En combinaison avec vm.swappiness et les paramètres « dirty », j’obtiens une gestion stable de la mémoire. Je tire ainsi efficacement parti du cache du système de fichiers Linux et maintiens de manière fiable des temps de réponse bas même sous charge.