Passer au contenu 
Je vais vous montrer comment configurer vm.swappiness afin que les services Web et les bases de données sur les serveurs d'hébergement réagissent plus rapidement et génèrent moins d'opérations d'E/S. Grâce à des étapes claires, des valeurs de départ judicieuses et un suivi efficace, vous tirerez le meilleur parti de la mémoire vive disponible et réduirez Latence et évite ainsi un échange de mémoire inutile.
Points centraux
Ces points te donnent un aperçu rapide des réglages que tu peux mettre en œuvre immédiatement.
- Comportement de Swappiness: Détermine à quel moment le noyau commence à déplacer la mémoire vive vers l'espace d'échange.
- En fonction de la charge de travail: Adapter les valeurs au type d'application, par exemple une base de données ou un site web.
- Tester temporairement: Vérifier d'abord en conditions réelles, puis valider définitivement.
- Disposition des swaps: Tenir compte de la taille, du contexte et des priorités.
- Suivi: Surveiller et ajuster les E/S, la mémoire vive et les temps de réponse.
Qu'est-ce que vm.swappiness et comment fonctionne-t-il ?
Le paramètre du noyau vm.swappiness détermine l’intensité avec laquelle Linux déplace les pages mémoire de la RAM vers l’espace d’échange. Vous trouverez la valeur actuelle dans le pseudo-système de fichiers sous /proc/sys/vm/swappiness et pouvez la modifier à la volée ou de manière permanente. Une valeur élevée entraîne un transfert plus précoce vers l'espace d'échange, tandis qu'une valeur faible conserve plus longtemps le contenu en RAM. L'objectif est de trouver un bon équilibre entre l'utilisation de la RAM, le cache de pages et un comportement contrôlé de l'espace d'échange. Je garde à l'esprit que la RAM est bien plus rapide que n'importe quel SSD, c'est pourquoi je privilégie Mémoire de travail clairement avant le swap.
Pourquoi la « swappiness » est importante sur les serveurs d'hébergement
Sur les serveurs Web et d'applications, le paramètre Swappiness concernant le temps de réponse et le débit. Un swap agressif génère une charge d'E/S supplémentaire et ralentit les requêtes, en particulier dans le cas de charges de travail fortement axées sur les bases de données. À l'inverse, des valeurs trop faibles comportent le risque d'événements OOM ultérieurs, qui mettent fin brusquement aux processus. C'est pourquoi j'évalue non seulement la mémoire vive et l'espace d'échange, mais aussi les pics de charge typiques, les caches et les modèles de requêtes. Réduire les latences permet d'éviter les saccades et de maintenir des transactions nettement plus fluides liquide.
Recommandations en fonction de la charge de travail
Une valeur unique convient rarement à tous les cas de figure ; c'est pourquoi je commence par des plages éprouvées dans la pratique, puis je les adapte en fonction des données de mesure. Les bases de données tirent profit de réglages très bas, tandis que les serveurs web purs supportent souvent des valeurs légèrement plus élevées. Les systèmes de test ou de développement peuvent fonctionner plus près des valeurs par défaut, car le confort y joue un rôle plus important. J'utilise le schéma suivant comme point de départ pragmatique pour Hébergement- les charges de travail. Ensuite, je surveille les opérations d'E/S, l'utilisation de l'espace d'échange et les temps de réponse, puis j'affine les réglages en fonction des besoins.
| Charge de travail | Swappiness recommandé | Objectif |
|---|---|---|
| Bases de données (MySQL, PostgreSQL) | 0–10 | Conserver les données en mémoire tampon dans la RAM, limiter les latences |
| Temps réel / Faible latence | 0–10 | Éviter les pics d'E/S grâce à la mémoire swap |
| Serveur web avec des caches | 10-20 (parfois 10-30) | Déplacer les pages inactives, conserver les requêtes actives en mémoire vive |
| Développement/Tests | 30-60 | Le confort et la stabilité avant la latence |
Vérifier la valeur actuelle
Avant de modifier des valeurs, je lis l'état et je consigne les Ligne de base. Pour cela, j'utilise soit la commande `cat /proc/sys/vm/swappiness`, soit `sysctl vm.swappiness` ; ces deux méthodes renvoient une valeur telle que 60. En parallèle, je vérifie l'utilisation de la mémoire vive et de l'espace d'échange à l'aide de la commande `free -h`. Avec `swapon –show`, j’identifie la taille, la priorité et le support des périphériques de swap actifs. Ces données de départ m’aident à évaluer les effets ultérieurement attribuer de pouvoir.
Tester temporairement plutôt que de modifier définitivement tout de suite
Je vais d'abord installer Swappiness à titre d'essai, afin de voir les réactions en conditions réelles Dernier à observer. La commande `sysctl vm.swappiness=10` prend effet immédiatement, mais ne dure que jusqu'au redémarrage. Pendant les tests, je surveille `top` ou `htop`, je vérifie `vmstat` et `iostat` et je mesure les temps de réponse des services. Si le taux d'utilisation de la mémoire swap diminue et que les latences restent stables, je procède par étapes raisonnables. Ce n'est que lorsque les indicateurs sont convaincants que j'enregistre la valeur durable fixe.
Configurer de manière permanente
Si la valeur testée convient, je l’ajoute dans un fichier de configuration sysctl et je recharge les paramètres. Dans /etc/sysctl.conf, j’ajoute la ligne vm.swappiness=10 et je l’active avec sysctl -p. Pour plus de clarté, je préfère utiliser un fichier dédié dans /etc/sysctl.d/, par exemple 99-swappiness.conf, et le charger via sysctl –system. Cela facilite la gestion des versions et l'intégration dans des processus automatisés. Cet article fournit un aperçu détaillé des paramètres associés : Réglage sysctl, qui m'aide à organiser les modifications et Clarté apporte.
Taille de la zone d'échange, disposition de la mémoire et supports de données
La « swappiness » n'agit jamais de manière isolée, c'est pourquoi j'évalue la taille et l'emplacement du Swap toujours à portée de main. Un espace d'échange insuffisant se remplit rapidement, tandis qu'un espace d'échange surdimensionné allonge les phases d'E/S en cas de charge importante. Sur un SSD ou un NVMe, l'espace d'échange est plus rapide que sur un disque dur, mais la mémoire vive reste bien plus rapide, de plusieurs ordres de grandeur. La mise en place de plusieurs périphériques d'échange avec des priorités permet d'utiliser en premier le support le plus rapide. Si vous souhaitez approfondir les avantages et les inconvénients, vous trouverez dans cet aperçu sur Swap dans l'hébergement des pistes de réflexion utiles pour les Cabinet médical.
Déroulement des opérations au cabinet : étape par étape
Je commence par faire le point : je note la valeur actuelle de Swappiness, l'utilisation de la RAM et de l'espace d'échange, ainsi que l'activité du processeur et des E/S, puis je les enregistre sous forme de Référence Sauvegarder. Ensuite, je classe la charge de travail : principalement base de données, Web avec cache, exploitation mixte ou en conteneurs. Puis je définis une valeur cible : de 0 à 10 pour les bases de données, généralement de 10 à 20 pour le Web, et je procède avec prudence pour les charges mixtes. Je définis cette valeur à titre temporaire, j’observe plusieurs phases de charge et je compare les métriques. Si les résultats concordent de manière répétée, je fixe la valeur, je documente la modification et je la vérifie après une mise à jour du noyau, du matériel ou Release-Changer à nouveau.
Scénarios spécifiques : conteneurs, machines virtuelles et cloud
Dans les conteneurs et les machines virtuelles, j'évalue le paramètre « swappiness » au niveau de l'hôte et de l'invité ensemble . Les orchestrateurs tels que Kubernetes tirent généralement parti de paramètres très bas sur les nœuds de travail afin de limiter les latences des pods. Dans les machines virtuelles, je définis en interne des valeurs adaptées, tout en veillant à ce que l’hyperviseur ne fonctionne pas à l’encontre de ces réglages. Dans les configurations cloud élastiques, des valeurs prudentes aident à lisser les pics jusqu’à ce que la mise à l’échelle prenne effet. J’évite qu’un seul conteneur, en raison d’une utilisation intensive de la mémoire virtuelle, ne monopolise l’ensemble de la Plate-forme freine.
Monitoring et recherche d'erreurs
Je considère qu’une charge d’E/S élevée alors que de la RAM est encore disponible, des temps de réponse irréguliers et des requêtes de base de données lentes sont des signes avant-coureurs typiques d’un paramètre « swappiness » inadapté. Je vérifie ces schémas à l’aide de vmstat, iostat, sar ainsi que des métriques issues de ma pile d’observabilité. Si le système utilise beaucoup d’espace d’échange malgré de la mémoire RAM libre, je réduis généralement le paramètre de swappiness. Si je constate des journaux OOM ou des interruptions en cas de mémoire RAM insuffisante, j’augmente modérément le paramètre de swappiness ou j’ajuste la configuration de l’espace d’échange. Le tableau suivant répertorie les symptômes d’un probable Cause et donne une première orientation.
| Symptôme | Cause probable | Prochaine étape |
|---|---|---|
| E/S élevées lorsque la mémoire vive est libre | Niveau de « swappiness » trop élevé | Réduire la valeur, mesurer l'impact |
| Événements OOM en charge | Swappiness trop faible ou espace d'échange insuffisant | Augmenter la valeur, vérifier la taille du swap |
| Requêtes lentes malgré la réserve de puissance du processeur | Mémoire tampon de la base de données transférée | Valeur comprise entre 0 et 10, analyser le tampon DB |
| Pics de charge sans goulot d'étranglement au niveau du processeur | Pics d'E/S induits par le swap | Réduire le taux de swappiness, vérifier les accès au cache |
Comprendre les indicateurs granulaires
Pour évaluer objectivement le paramètre « swappiness », j'examine de plus près les compteurs du noyau. Dans /proc/vmstat, les variables pswpin et pswpout indiquent respectivement le nombre de pages chargées et déchargées. Les variables pgscan_kswapd_* et pgsteal_* montrent le degré d’agressivité du récupérateur. Si les pgmajfault (erreurs de page majeures) se multiplient, cela indique des rechargements gourmands en E/S. Je consulte ces valeurs à plusieurs reprises ou à l'aide de sar -B et sar -W afin d'observer les taux, et pas seulement des instantanés. Avec `vmstat 1`, je détecte les `si/so` (Swap in/out) et je peux attribuer les pics à des événements réels. En complément, `/proc/pressure/memory` fournit une estimation de l'intensité avec laquelle les tâches sont affectées par la pression mémoire bloquer (PSI). Si ces valeurs augmentent légèrement ou fortement, j'ai là une indication claire d'un « reclaim » trop agressif ou d'un « swappiness » inadapté.
Swappiness 0 vs. 1 : ce que fait réellement le noyau
On pense souvent que Swappiness=0 désactive complètement la pagination. Ce n'est pas tout à fait exact. La valeur 0 indique au noyau d'éviter autant que possible la pagination et de ne l'utiliser qu'en cas de véritable pression sur la mémoire. En pratique, une valeur comprise entre 1 et 10 suffit pour obtenir un comportement très prudent, tandis que la valeur 0 peut, dans certaines versions, entraîner occasionnellement des phases de récupération tardives, mais d’autant plus intenses. Pour les services où la latence est critique, je règle généralement la valeur entre 1 et 5 et je vérifie si les valeurs pswpout/pswpin restent pratiquement à zéro. Si, avec une valeur de 0, des événements OOM surviennent lors de pics de charge, j'augmente légèrement la valeur afin que le noyau relâche la pression plus tôt et en douceur, plutôt que brutalement. faire irruption.
Utiliser Zswap et ZRAM à bon escient
Outre le swap classique sur disque, j'utilise Zswap ou ZRAM selon le profil. Zswap compresse les pages transférées en mémoire virtuelle et les conserve d'abord en RAM avant de les transférer sur le support de stockage si nécessaire. Cela réduit les opérations d'E/S et lisse les latences, mais sollicite davantage le processeur. Sur les hôtes disposant d'une importante réserve de puissance CPU, c'est une plus rentable Compromis. ZRAM met à disposition un espace d'échange compressé directement en RAM – idéal pour les charges en rafales ou les très petites machines virtuelles, dans lesquelles je préfère utiliser de la RAM compressée plutôt que des E/S lentes. Important : je choisis délibérément l’un des deux concepts et j’établis les priorités de manière à ce que le chemin le plus rapide soit servi en premier. Le paramètre « swappiness » reste un levier de contrôle : même avec Zswap/ZRAM, je souhaite éviter les vagues de récupération inutiles.
Cache de page, vfs_cache_pressure et accès au cache
Swappiness interagit avec le cache de pages, qui conserve les fichiers et les inodes en mémoire vive. Le paramètre vm.vfs_cache_pressure me permet de contrôler l'intensité avec laquelle le noyau libère ces caches au profit de pages anonymes. Des valeurs trop élevées entraînent la disparition trop rapide des caches de métadonnées, ce qui ralentit les serveurs web. Je commence généralement avec une valeur comprise entre 50 et 100, je mesure les taux de réussite du cache et j’observe l’évolution des latences au niveau des ressources statiques et des réponses API. L'objectif est de conserver en mémoire vive les contenus fréquemment utilisés, sans que les pages rarement consultées n'encombrent la mémoire. Si le taux de réussite reste bon et les E/S faibles, l'équilibre est satisfaisant ; dans le cas contraire, j’ajuste les paramètres « swappiness » et « vfs_cache_pressure » dans le Tandem.
Éviter les « dirty writebacks » et les pics d'E/S
Les chemins d'écriture influencent les latences tout autant que le swap. Avec les paramètres vm.dirty_background_ratio/bytes et vm.dirty_ratio/bytes, je détermine la quantité de cache « sale » qui s'accumule avant que le noyau ne procède à l'écriture. Je préfère utiliser les valeurs en *_bytes plutôt que les pourcentages pour définir des limites maximales, en particulier dans les configurations à grande mémoire vive où les pourcentages peuvent générer d’énormes vagues de réécriture. Objectif : une écriture continue et prévisible plutôt que des pics sporadiques qui, combinés à l’espace d’échange, génèrent des verrous d’E/S. Je surveille iostat et les files d’attente de réécriture, et je maintiens les valeurs de manière à ce que les SSD/NVMe soient constamment sollicités, mais sans écrasé être.
NUMA, « Zone Reclaim » et les hôtes de grande taille
Sur les systèmes NUMA, la localisation de la mémoire joue un rôle important. Si vm.zone_reclaim_mode est activé, le noyau peut récupérer de manière plus agressive de la mémoire sur le nœud NUMA local, ce qui peut déclencher des pics de récupération indésirables. Pour de nombreuses charges de travail d’hébergement, je désactive la récupération par zone et laisse le planificateur se charger du placement afin d’obtenir un comportement plus stable. De plus, je vérifie les pages géantes transparentes (THP) : les bases de données réagissent souvent mieux à THP=never ou madvise, car la défragmentation imprévue et les allocations THP peuvent provoquer des pics de latence. Le paramètre « swappiness » peut être parfait – mais si les politiques THP ou NUMA viennent perturber le fonctionnement, les saccades.
Les subtilités des conteneurs et des cgroups
Avec Cgroups v2, je dispose d’autres leviers en plus du paramètre « host-swappiness » : « memory.high » déclenche un « reclaim » progressif, « memory.max » fixe des limites strictes, et « memory.swap.max » limite l’utilisation de l’espace d’échange par charge de travail. Cela m’évite que certains conteneurs ne ralentissent l’hôte en recourant à l’espace d’échange. Je définis des valeurs de swappiness faibles sur le nœud et j’accorde la priorité aux charges de travail critiques via `memory.low`, afin que leurs hotsets restent plus longtemps en mémoire vive. Dans Kubernetes, je surveille la manière dont le nœud gère l’espace d’échange et je teste d’abord les modifications dans des pools hors production. Il est important d’avoir une vue d’ensemble : les paramètres de l’hôte, les limites des Cgroups et l’orchestrateur doivent être cohérents, sinon la pression ne fait que se déplacer d’un niveau à l’autre autres.
Déploiement, automatisation et retour en arrière
Je déploie les modifications apportées à Swappiness de manière contrôlée, comme pour toute optimisation des performances : d’abord sur un petit groupe de nœuds quasi identiques (Canary), puis progressivement à plus grande échelle. Systemd-sysctl ou la gestion de configuration permettent d’intégrer ces valeurs de manière reproductible. Je documente les valeurs initiales et finales, les dates et heures, les hôtes concernés et Métriques. En prévision d'une rechute, je planifie à l'avance la modification inverse (par exemple, sysctl vm.swappiness=60) et je conserve les fichiers sysctl précédents. Pendant les fenêtres de maintenance, je mesure délibérément des scénarios de charge typiques afin de ne pas confondre les changements avec les fluctuations liées à l’heure de la journée ou au trafic. C’est la seule façon de garantir que les décisions restent fiables et soient prises en équipe. compréhensible.
Idées reçues courantes et anti-modèles
- „ Swappiness=0 désactive la mémoire swap “: Non, le noyau continue d'utiliser la mémoire swap, mais de manière très modérée.
- „ Plus on fait de swap, plus c'est sûr “: Un espace d'échange trop important prolonge les phases de charge et masque les goulots d'étranglement de la mémoire vive, au lieu de les résoudre.
- „ Avec NVMe, le swapping n'a plus d'importance “: Le NVMe est rapide, mais nettement plus lent que la RAM. Les latences restent perceptibles.
- „ Une valeur pour tous les serveurs “: Les charges de travail varient considérablement. Sans mesure, l'optimisation relève du hasard.
- „ Swappiness résout tous les problèmes de latence “: Les problèmes proviennent souvent des accès au cache, du « writeback », du THP, des plans de requête ou des chemins réseau.
Résumé pour un démarrage rapide
Je règle généralement vm.swappiness entre 10 et 20 pour les serveurs web et entre 0 et 10 pour les bases de données, je teste l'effet obtenu et j'observe les E/S, les latences et Swap-pourcentage. Je définis la valeur finale via sysctl dans /etc/sysctl.d/ et je veille à ce que les modifications restent traçables. Parallèlement, je m’assure que la configuration de l’espace d’échange est cohérente : taille adaptée, support rapide, priorités pertinentes. En cas de pression sur la mémoire, je surveille également le cache de pages et son comportement ; cet aperçu fournit une bonne introduction à ce sujet : Éviction du cache de page, qui m'aide à analyser les causes et Contexte . Cette approche me permet d'obtenir des temps de réponse fiables, d'éviter les pics de pagination et d'utiliser efficacement la mémoire vive disponible.
