Virtualisation KSM réduit les besoins physiques en mémoire vive (RAM) en permettant au noyau Linux de regrouper les pages mémoire identiques entre les machines virtuelles et de les partager efficacement via le mécanisme « copy-on-write ». Cela me permet d'augmenter la densité des machines virtuelles, d'atténuer les goulots d'étranglement au niveau de la mémoire vive et de maintenir la Performance en équilibre.
Points centraux
Les points clés suivants m'aident à cerner rapidement le KSM et à l'utiliser de manière ciblée :
- Déduplication La mise en cache des pages de mémoire identiques réduit considérablement la consommation de RAM.
- Copie à l'écriture permet de consulter les pages ensemble et ne les sépare qu'en cas de modifications.
- Réglage fin Les paramètres ksmd permettent d'équilibrer la charge du processeur et les économies réalisées.
- Localité de la NUMA évite les latences inutiles sur les hôtes à plusieurs sockets.
- Sécurité nécessite un partage sélectif dans les environnements multi-locataires.
Qu'est-ce que le KSM ? Principes fondamentaux et déroulement
Avec Fusion des pages identiques du noyau Le thread du noyau ksmd parcourt régulièrement les pages privées anonymes marquées comme „ fusionnables “ et regroupe les contenus bit à bit identiques. Je tire parti du fait que, souvent, de nombreuses machines virtuelles conservent en mémoire des bibliothèques, des codes de programme ou des composants du système d'exploitation identiques. KSM marque les pages fusionnées comme Copy-on-Write, ce qui fait que tous les utilisateurs lisent la même page physique jusqu’à ce que l’un d’entre eux effectue une opération d’écriture. Ce n’est qu’au moment de l’accès en écriture que le noyau crée une page distincte pour ce processus, tandis que la page d’origine continue d’être partagée. Important : KSM ne déduplique pas les pages du système de fichiers ni celles du cache de pages, et je dois libérer explicitement de la mémoire pour la fusion.
Utilisation dans des environnements de virtualisation
Sur les hôtes comportant de nombreuses machines virtuelles similaires, cela se traduit par KSM l'effet le plus important, car les pages redondantes sont très fréquentes. Dans les configurations KVM et cloud, la fusion réduit considérablement la charge effective de la mémoire vive par invité et augmente ainsi la densité de machines virtuelles par serveur. Des témoignages issus de la pratique font état de jusqu’à 300 % systèmes invités supplémentaires avec un réglage optimisé, sans perte notable en termes de temps de réponse. Si je combine KSM avec Dépassement de la mémoire, j'optimise l'utilisation des hôtes et j'exploite la mémoire vive disponible de manière plus ciblée. En partageant des pages identiques, je réduis le risque de pics d'utilisation de la mémoire swap et j'obtiens un fonctionnement fluide Courbe de puissance à travers de nombreuses instances.
Configuration sous Linux et KVM
J'active KSM via CONFIG_KSM dans le noyau et je contrôle le comportement via sysfs sous /sys/kernel/mm/ksm/. C'est là que je lance l'analyse (run), que je définis l'intensité (pages_to_scan, sleep_millisecs) et que j'observe les gains de pages (pages_sharing). Dans les distributions d’entreprise, j’utilise des services tels que ksm et ksmtuned, qui ajustent automatiquement la puissance vers le haut ou vers le bas en fonction des seuils de RAM libre. Pour un contrôle plus fin, je marque de manière ciblée des zones de mémoire comme fusionnables à l’aide de madvise(MADV_MERGEABLE) ou prctl(PR_SET_MEMORY_MERGE). Dans les environnements dynamiques, j’aime bien combiner KSM avec Ballons à mémoireafin de pouvoir Allocation de mémoire vive tout en conservant une certaine souplesse.
Performances et tuning : le juste équilibre
C'est surtout là où la mémoire vive constitue le véritable goulot d'étranglement et où les cœurs du processeur resteraient inutilisés que j'en tire le meilleur parti – c'est là que KSM les performances globales, car j'exécute davantage de machines virtuelles en parallèle. Le thread ksmd consomme toutefois du temps CPU, c'est pourquoi des paramètres d'analyse trop agressifs peuvent réduire ces avantages. Je commence par une approche prudente, je mesure les valeurs de `pages_sharing` et `pages_scanned`, et j’observe les latences sous charge avant d’augmenter la fréquence d’analyse. Lorsque la mémoire vive libre est suffisante, je limite l’activité de ksmd et je ne passe à la vitesse supérieure que lorsque les hôtes se font rares. Je préserve ainsi un bon équilibre entre gain de mémoire et la surcharge du processeur.
La sécurité et l'isolement d'un point de vue objectif
Étant donné que plusieurs invités partagent un même espace physique, je tiens compte des risques potentiels Canaux latéraux, qui pourraient en déduire des informations sur la synchronisation ou les modèles d'accès. Dans les environnements multi-locataires sensibles, je désactive le partage de pages de manière sélective pour certaines instances ou certains hôtes. En revanche, pour les charges de travail moins sensibles comportant de nombreux invités similaires, le KSM constitue une méthode fiable pour réduire les coûts et augmenter la densité. Je documente cette décision pour chaque cluster et tiens à jour une liste d’exceptions pour les machines virtuelles particulièrement critiques. C’est ainsi que je préserve Transparence et réduire les points faibles sans compromettre le gain d'efficacité.
NUMA, les pages géantes et l'interaction
Sur les systèmes NUMA, je fais attention à Lieu de stockage et, dans l'idéal, je ne fusionne les KSM qu'au sein d'un même nœud, afin que les accès ne passent pas par des chemins lents. Cela réduit les latences et maintient une bande passante élevée par socket. En combinaison avec les Huge Pages, je réduis les échecs de TLB, mais je dois garder à l’esprit que les pages de grande taille modifient les probabilités de contenus bit à bit identiques. Certaines charges de travail tirent davantage parti des Huge Pages, d’autres de la déduplication ; je vérifie cela à l’aide de benchmarks. L’objectif reste de maximiser l’accès local et mémoire à distance d'éviter.
Comprendre le suivi et les indicateurs clés
J'évalue l'effet de KSM à l'aide de quelques indicateurs, mais pertinents : pages_sharing, pages_shared, pages_scanned, pages_unshared et full_scans. Si pages_sharing augmente de manière stable et que la charge CPU reste modérée, cela signifie que ma configuration évolue dans la bonne direction. Si les valeurs restent stables, je vérifie si les invités marquent réellement la mémoire comme « mergeable ». J’observe également les échanges entre hôtes, les latences des machines virtuelles et les temps d’attente d’E/S afin de détecter les effets secondaires à temps. Les tableaux de bord avec séries chronologiques me montrent les tendances, ce qui me permet de Adaptations je prends des décisions fondées sur des données.
Exemples concrets et potentiel d'économies
Dans des clusters de test comprenant des dizaines de machines virtuelles Linux similaires, j'ai pu constater, grâce à KSM des économies de RAM parfois à deux chiffres en points de pourcentage, et donc une densité nettement plus élevée. Les charges de travail Java comportant de nombreuses classes et bibliothèques identiques ont généré des gains particulièrement constants. Plus les instances sont homogènes, plus l’empreinte mémoire diminue ; les piles hétérogènes offrent des résultats moindres, mais néanmoins utiles. Associé à un overcommit correctement configuré, cela me permet de maintenir les coûts par instance à un faible niveau et d’exploiter davantage de services sur le même matériel. Il en résulte une impact économique avec une qualité prévisible.
KSM vs alternatives : distinctions et interactions
Je mise sur un Portefeuille des techniques de mémoire complémentaires dont les effets varient en fonction de l'objectif visé. KSM élimine la redondance dans le contenu de la RAM, tandis que le « ballooning » récupère dynamiquement de la mémoire au profit des machines virtuelles et que les « huge pages » améliorent l'efficacité du processeur. Aucune de ces techniques ne remplace l'autre ; je les combine de manière ciblée en fonction du profil de charge de travail et de l'objectif de densité. Pour les débutants, l’aperçu suivant aide à faire rapidement son choix. L’étape suivante consiste à jeter un œil à KVM et Xen en comparaison, afin de déterminer la Choix de la plateforme le classer correctement.
| Technique | Tâche | Avantage | Inconvénient | Convient pour |
|---|---|---|---|---|
| KSM | Déduplication des pages de mémoire vive identiques | Haute Économie de mémoire vive pour des machines virtuelles similaires | Charge supplémentaire sur le processeur due aux analyses | De nombreux clients similaires, des hôtes KVM |
| Ballons à mémoire | Récupération dynamique des capacités de stockage de gaz | Meilleur Taux d'occupation en cas de charges de travail variables | Un pilote de ballon par invité est nécessaire | Profils de charge mixte |
| Pages géantes | Des tailles de page plus importantes pour réduire les échecs de TLB | Plus haut Efficacité du processeur pour les applications gourmandes en mémoire | Risque de déduplication réduit | Bases de données, JVM, moteurs en mémoire |
| NUMA-Pinning | Liaison des machines virtuelles aux nœuds de stockage locaux | constante Latence et la bande passante | Moins de flexibilité dans la planification | Hôtes à plusieurs sockets, charges de travail sensibles à la latence |
Mise en œuvre pratique et guides d'administration
Au niveau de l'hôte, j'adopte une approche pragmatique : je lance ksm/ksmtuned et je définis des valeurs par défaut qui ont fait leurs preuves en production. Exemple :
Activer les services # (en fonction de la distribution)
systemctl enable --now ksm ksmtuned
Réglage manuel de # (prend effet immédiatement, jusqu'au redémarrage)
echo 1 > /sys/kernel/mm/ksm/run
echo 1000 > /sys/kernel/mm/ksm/pages_to_scan
echo 50 > /sys/kernel/mm/ksm/sleep_millisecs
Dans libvirt, je gère le partage pour chaque machine virtuelle. Par défaut, QEMU marque la mémoire RAM des machines invitées comme « fusionnable ». Pour les machines virtuelles particulièrement sensibles, je désactive explicitement le partage :
Je m'en tiens donc à une ligne claire : une activation à grande échelle sur les hôtes présentant des charges de travail homogènes, avec des exclusions ciblées pour les exceptions.
Réglage fin des paramètres KSM : détails
- run: 0 = désactivé, 1 = activé, 2 = désactivé et suppression des pages déjà fusionnées. Je n'utilise l'option „ 2 “ que pour des tests ciblés ou lorsque je souhaite désactiver le partage en toute sécurité avant les fenêtres de maintenance.
- pages_à_numériser: Nombre de pages vérifiées par cycle. Des valeurs plus élevées accélèrent la détection des pages identiques, mais augmentent la charge du processeur.
- sleep_millisecs: Pause entre les cycles. Des pauses plus longues réduisent la surcharge, mais il faut plus de temps pour atteindre le plateau d'économies.
- fusionner_entre_nœuds: Sur les hôtes NUMA, je règle ce paramètre sur 0 afin que le merging s'effectue uniquement au sein d'un nœud NUMA. Cela permet de préserver la localité.
- use_zero_pages: Lorsque cette option est activée, les processus partagent efficacement les pages nulles avec la page nulle du noyau. Cela permet de réaliser des économies „ sûres “ sans coûts liés au COW.
Avec ksmtuned, je régle la configuration de manière dynamique en fonction de seuils de RAM. Dès que la mémoire libre commence à manquer, ksmtuned augmente la vitesse de balayage (Npagen-Boost) ; lorsque la pression diminue, il réduit à nouveau cette intensité. Cela permet d'obtenir une configuration adaptative, „ respirante “, sans aucune intervention manuelle.
Interaction avec THP, les « Huge Pages » et le « ballooning » (approfondissement)
Transparent Huge Pages (THP) et Pages géantes optimisent l'efficacité du processeur, tandis que KSM réduit la redondance dans la mémoire vive. Je tiens compte des éléments suivants :
- KSM fonctionne avec des pages standard de 4 Ko. Les pages THP (généralement de 2 Mo) ne peuvent pas être dédupliquées. Plus THP est sollicité, moins KSM dispose de données à traiter.
- Pour les charges de travail où la latence est critique ou celles qui sollicitent fortement le processeur, je privilégie THP/Huge Pages. Pour les hôtes disposant de peu de mémoire vive et hébergeant des machines virtuelles homogènes, je privilégie KSM.
- Le « ballooning » complète le KSM : le pilote Balloon libère de l'espace de mémoire virtuelle pour l'hôte. Parallèlement, le KSM réduit les besoins en consolidant les pages identiques. Ensemble, nous lissons les pics de charge et évitons un swap prématuré.
Je prends ma décision sur la base de données empiriques : les tests de performance avec et sans THP/Huge Pages, ainsi qu’avec le KSM activé, me permettent de déterminer quelle combinaison offre le meilleur rapport coût-performance global.
Modèles de sécurité et fonctionnalités avancées des processeurs
Dans les environnements où séparation stricte des clients Je désactive systématiquement le partage par VM/hôte. Cela minimise les canaux d'information latéraux liés au partage de pages et simplifie les contrôles de conformité. Les solutions modernes Chiffrement du stockage Au niveau hôte/invité (par exemple, par clé de VM), cela empêche en pratique KSM de fusionner efficacement les données entre les invités, car les contenus identiques ne sont plus stockés bit à bit dans la mémoire RAM physique. Dans ce type de clusters, j’évite les analyses agressives et je maintiens ksmd plutôt en mode passif afin de ne pas gaspiller les ressources du processeur.
Pour les piles moins sensibles mais homogènes, je conserve KSM comme paramètre par défaut. Je documente la politique pour chaque cluster : „ Activé par défaut, exceptions via nosharepages “ ou „ Désactivé par défaut, partage uniquement pour les pools définis “ – les deux options sont valables, à condition qu’elles soient mises en œuvre de manière transparente et reproductible.
Adéquation aux charges de travail et anti-modèles
KSM excelle dans le traitement de charges de travail homogènes et riches en bibliothèques (par exemple, de nombreux serveurs d'applications identiques, des services basés sur la JVM, des agents). Les cas suivants en tirent moins profit :
- Allocations très variables et de courte durée (par exemple, de nombreux petits tampons modifiés rapidement), car la probabilité de COW est élevée.
- Données compressées, chiffrées ou pseudo-aléatoires – on ne trouve pratiquement jamais de pages identiques.
- Grandes bases de données en mémoire avec un recyclage agressif des pages lorsque les données évoluent rapidement. Dans ce cas, les avantages des Huge Pages/THP l'emportent souvent.
Dans les fermes de conteneurs, le KSM peut également fonctionner, à condition que les processus marquent les espaces de mémoire comme « mergeable ». Dans la pratique, je concentre toutefois principalement le KSM sur les machines virtuelles, car c’est là que QEMU définit déjà les indicateurs madvise nécessaires.
Résolution des problèmes et écueils typiques
- Le partage de pages stagne: Je vérifie si QEMU/les machines virtuelles créent bien de la mémoire fusionnable (absence de directive `nosharepages` dans le fichier XML de libvirt) et si ksmd est en cours d'exécution. Si le taux de fusion reste faible, la charge de travail est probablement trop hétérogène.
- Charge du processeur trop élevée: J'augmente la valeur de `sleep_millisecs` et/ou je réduis celle de `pages_to_scan`. Je peux également désactiver la fusion inter-NUMA afin de réduire l'espace de recherche.
- Pics de latence inattendus: Je vérifie si les événements COW sont corrélés à des pics de charge. Dans ce cas, je réduis la fréquence d'analyse ou j'exclue temporairement les machines virtuelles concernées du partage.
- L'overcommit se transforme en swap: KSM ne remplace pas la planification des capacités. Je garde toujours une réserve de mémoire vive libre et je ne règle ksmd qu’à titre de tampon, et non comme solution de secours.
Planification, dimensionnement et automatisation
Pour obtenir des résultats prévisibles, je définis des indicateurs par hôte :
- marge: Une marge fixe en pourcentage de RAM libre, en dessous de laquelle ksmtuned devient plus agressif. Cela me permet de limiter la déduplication aux moments où le besoin s'en fait réellement sentir.
- Équité: Lorsque les charges de travail sont inégales, je sépare les pools (par exemple par projet ou par environnement), afin que les machines virtuelles homogènes puissent bénéficier ensemble des ressources et que les machines hétérogènes ne „ diluent “ pas les performances.
- Valeurs limites: Je fixe des limites pour les fréquences d'analyse maximales et je vérifie régulièrement si les économies réalisées justifient la charge imposée au processeur.
En matière d'automatisation, je considère le KSM comme un guide de procédures reproductible et versionné (par exemple, des « drop-ins » Systemd ou des extraits de code Cloud Init). Cela me permet de m'assurer que les nouveaux hôtes sont mis en service avec un ensemble de paramètres identique et de repérer rapidement tout écart.
Résumé pour les admins
J'utilise KSM, lorsque les hôtes hébergent de nombreuses machines virtuelles similaires et que la mémoire vive est la ressource la plus limitée. Dans ce cas, la déduplication offre le meilleur rapport efficacité-coût, tandis que j’ajuste avec précision la charge CPU à l’aide de ksmtuned et des paramètres sysfs. Dans les configurations NUMA, je limite la fusion au niveau local, je combine KSM avec le ballooning et les Huge Pages, et je mesure l’impact à l’aide de pages_sharing ainsi que des métriques de latence. Pour les invités sensibles, je désactive le partage de manière ciblée et je documente les exceptions en toute transparence. C’est ainsi que j’augmente densité, garantir des temps de réponse fiables et réduire durablement le coût en euros par instance.
