Si vous voulez démarrer une dispute avec un utilisateur Linux, posez des questions sur swap Mémoire. Certains le louent comme un coussin ou comme un filet de sécurité tandis que d'autres le dénigrent comme une béquille et un destructeur des performances du système. Née dans les années 1960, la mémoire d'échange a évolué au fil des années sous Linux pour remplir deux fonctions essentielles :
- Mémoire d'urgence lorsqu'un système consomme toute sa RAM et en a encore besoin
- Un parking pour les pages de mémoire rarement utilisées qui occupent une précieuse RAM système
De nombreuses distributions Linux, y compris Red Hat, recommandent la mémoire d'échange pour tous les systèmes. Cependant, si vous examinez la plupart des instances cloud de différentes distributions, vous constatez qu'il n'y a pas de mémoire d'échange.
[ Vous pourriez également aimer : Dépannage Linux 101 :Performances du système ]
Présentation de l'échange
Swap existe sur la plupart des systèmes en tant que partition sur un disque. Après le partitionnement, les administrateurs formatent la partition avec mkswap , activez-le avec swapon , et le noyau voit instantanément la mémoire d'échange disponible. Les systèmes sans partition disponible peuvent utiliser un fichier d'échange, qui est juste un fichier sur un système de fichiers existant qui est formaté avec mkswap et activé.
Les deux méthodes fonctionnent bien, mais placer un swap sur une partition améliore les performances car vous évitez la surcharge d'un fichier d'échange sur une partition existante.
Lorsque la RAM du système est rare, Linux peut stocker des pages de mémoire dans le swap pour éviter de tuer des processus et de planter le système. Les disques sont beaucoup plus lents que la RAM système, ce qui réduit les performances du système jusqu'à ce que la RAM système se libère. Si l'utilisation de la mémoire continue d'augmenter au point où la RAM système et le swap sont complètement épuisés, le tueur de mémoire insuffisante (OOM) apparaît et commence à tuer les processus jusqu'à ce que suffisamment de RAM soit disponible.
Le conseil de longue date sur la taille du swap est le double de la taille de la RAM de votre système. Par exemple, allouez 2 Go de swap pour les systèmes avec 1 Go de RAM système. Bien que ce ratio fonctionne bien pour les petits systèmes, il n'est pas adapté aux systèmes dotés de centaines de gigaoctets de RAM système.
Le cas du swap sur le cloud
L'essor des microservices (petits services interconnectés qui forment une grande application) a conduit les entreprises à déployer un plus grand nombre d'instances plus petites. Les instances plus petites sont livrées avec moins de RAM système, ce qui augmente le risque que le redoutable tueur de MOO apparaisse pour tuer les processus jusqu'à ce que le système dispose de suffisamment de mémoire libre.
L'ajout d'un swap à ces systèmes aide de deux manières :
- Tout d'abord, les processus peuvent brièvement s'échapper de la RAM système pour passer à l'échange pendant les périodes de charge élevée. Les administrateurs prennent connaissance de ces événements à partir de leurs systèmes de surveillance et ils ont le temps d'enquêter sur la raison de la rafale pendant qu'elle se produit sur le système. En cas de fuites de mémoire, les développeurs peuvent inspecter le processus pour comprendre ce qui n'a pas fonctionné pendant qu'il est encore en vie. Cela peut également indiquer que les administrateurs ont besoin de types d'instances plus volumineux pour leur application à mesure qu'elle se développe.
- Deuxièmement, le noyau Linux surveille les pages de mémoire rarement utilisées et les envoie pour échanger afin de préserver la précieuse RAM du système. Le
sysctlréglagevm.swappinesscontrôle le désir du noyau de pousser les pages mémoire à permuter. Cela pourrait aider une instance cloud en conservant les pages les plus actives dans la RAM système tout en poussant les pages rarement utilisées vers la mémoire d'échange.
Le cas contre le swap sur le cloud
L'analogie "animaux de compagnie contre bétail" revient fréquemment lorsque l'on parle d'instances cloud et les administrateurs bannissent l'échange puisqu'ils peuvent automatiquement remplacer une instance qui se comporte mal par une nouvelle. Au fil du temps, leurs métriques de surveillance montrent une augmentation du nombre d'instances nécessitant un remplacement en raison du tueur d'OOM qui met leur application hors ligne. La solution pourrait être des instances plus grandes ou une enquête plus approfondie sur les fuites de mémoire sous charge. Systemd redémarrera également ces processus rapidement lorsque cela sera possible.
Le choix d'un emplacement de mémoire d'échange sur des instances cloud nécessite plus de réflexion et de planification. Sur les serveurs physiques, l'échange sur un disque NVMe (Non-Volatile Memory Express) attaché localement est assez rapide, mais qu'en est-il d'une instance cloud avec stockage externe monté, comme Elastic Block Storage (EBS) d'AWS ? Les performances sur EBS varient en fonction du type d'EBS que vous choisissez et de vos voisins sur le système. L'échange sur un système de stockage distant peut entraîner de mauvaises performances de l'instance lorsque le système déborde de sa RAM. Les administrateurs peuvent choisir d'omettre l'échange et de remplacer ces instances lorsqu'elles débordent de leur RAM au lieu de se débattre avec des demandes de traitement de serveur peu performantes.
Enfin, de nombreuses instances cloud font partie des clusters Kubernetes et OpenShift, et elles ont un défi lorsqu'elles traitent de la mémoire d'échange. Il existe un problème GitHub de longue date concernant la gestion appropriée de la mémoire d'échange, car il supprime la comptabilisation de la mémoire pour les conteneurs. Des solutions de contournement existent, mais la mémoire d'échange est généralement ignorée sur ces systèmes.
Déploiement d'instances cloud avec swap
Si vous décidez que le provisionnement de la mémoire d'échange profite à vos applications, cloud-init vous donne la possibilité de provisionner la mémoire d'échange au premier démarrage à l'aide des mounts module. Ajoutez simplement quelques lignes à vos données utilisateur cloud-config existantes :
swap:
filename: /swapfile
size: auto
maxsize: 4294967296
Cette configuration indique à cloud-init de créer un fichier d'échange dans /swapfile avec une taille automatique égale ou inférieure à 4 Go. La formule pour le dimensionnement automatique du swap se trouve dans le code source de cloud-init :
formulas = [
# < 1G: swap = double memory
(1 * GB, lambda x: x * 2),
# < 2G: swap = 2G
(2 * GB, lambda x: 2 * GB),
# < 4G: swap = memory
(4 * GB, lambda x: x),
# < 16G: 4G
(16 * GB, lambda x: 4 * GB),
# < 64G: 1/2 M up to max
(64 * GB, lambda x: x / 2),
] La taille d'échange recommandée par Red Hat diffère légèrement :
- 2 Go ou moins de RAM système :2x RAM
- Plus de 2 Go à 8 Go : 1x RAM
- Plus de 8 Go à 64 Go : 4 Go minimum
- Plus de 64 Go : 4 Go minimum
Vous pouvez spécifier manuellement la mémoire d'échange (en octets) avec la size: paramètre
dans le cloud-config :
swap:
filename: /swapfile
size: 2147483648 # 2 GiB Échange de provisionnement sur une instance cloud existante
Pour les instances existantes, un fichier d'échange est souvent la méthode la plus simple pour activer la mémoire d'échange. Dans cet exemple, placez un fichier d'échange de 2 Go dans /swapfile :
# BTRFS only #################################################################
# We must disable copy-on-write updates for swap files on btrfs file systems.
# The 'swapon' step fails if you skip these steps.
truncate -s 0 /swapfile
chattr +C /swapfile
# BTRFS only #################################################################
# A 2 GiB swap file.
dd if=/dev/zero of=/swapfile bs=1MiB count=2048
# Set the correct permissions on the swap file.
chmod 0600 /swapfile
# Format the swapfile.
mkswap /swapfile
# Enable the swapfile.
swapon /swapfile
# Add it to /etc/fstab to enable it after reboot.
echo "/swapfile none swap defaults 0 0" >> /etc/fstab Vérifiez si votre mémoire d'échange est prête :
$ cat /proc/swaps
Filename Type Size Used Priority
/swapfile file 2097148 0 -2 [ Cours en ligne gratuit :Présentation technique de Red Hat Enterprise Linux. ]
Conclusion
La mémoire d'échange offre deux avantages précieux :
- Un coussin de sécurité lorsque l'utilisation de la RAM du système atteint des niveaux dangereux
- Un parking pour les pages de mémoire rarement utilisées qui occupent un espace précieux dans la RAM système
Ce coussin de sécurité entraîne une baisse des performances, car la pagination de la mémoire sur les disques est incroyablement lente par rapport à la mémoire système.
Les déploiements dans le cloud voient rarement la mémoire d'échange déployée, mais l'échange présente toujours des avantages. Le choix de déployer le swap permet un coussin de sécurité lorsque les applications se comportent mal, mais cela peut ralentir l'exécution d'une application jusqu'à ce que les problèmes de consommation de mémoire soient résolus. Ignorer l'échange supprime le coussin mais garantit qu'une application qui se comporte mal s'arrête immédiatement. Les administrateurs de cloud doivent avoir un plan en place pour gérer ces situations.
Heureusement, cloud-init apparaît sur la grande majorité des instances cloud et permet la création de fichiers d'échange avec seulement quelques lignes de YAML. La mémoire d'échange est également facile à configurer après le déploiement à l'aide de commandes ou de scripts shell simples.
Que vous choisissiez de déployer de la mémoire d'échange ou de vous en passer, assurez-vous d'avoir un plan lorsque le pire se produit. Surveillez les systèmes de manière appropriée et gardez une vue globale de l'application qu'ils desservent.