6.4 Gestion de la concurrence des accès au cache
6.4.3 Combinaison des deux approches
70 80 90 0 3 6 7 8 9 12131415 18 VM1 VM2 M é m o ir e ( % ) Temps (min) Actif
Inactif Actives (cache)Inactives (cache) Puma
(a) Mémoire de la VM2 100 1k 10k 37k 100k 0 3 6 7 8 9 12131415 18 VM1 VM2 IO /s Temps (min) Actif Inactif RéférenceVM2 VM1
(b) Performance des benchmarks de lectures aléatoires sur les 2 VMs
Figure6.6 – Comportement de Puma en présence de workloads concurrents sur plu-sieurs nœuds et en combinant les 2 approches
6.4.3 Combinaison des deux approches
Afin de bénéficier des avantages des deux approches, nous proposons de les combi-ner pour détecter l’activité d’une VM à la fois rapidement (1reapproche, shadow page cache) et de façon stable (2e approche, pression mémoire). Nous avons reproduit l’ex-périence précédente et nous présentons les résultats dans la figure 6.6. Comme nous pouvions nous y attendre, la combinaison des deux approches permet de détecter l’ac-tivité de la VM2rapidement, ce qui permet de désactiver Puma pour que celle-ci puisse utiliser son cache sans être pénalisé par la VM1.
6.5 Discussion
Ce chapitre a présenté plusieurs mécanismes permettant à Puma d’ajuster dynami-quement la quantité de mémoire qu’un nœud accepte de prêter à d’autres nœuds. Ces mécanismes reposent notamment sur l’intégration des pages distantes au sein du page cache du noyau Linux ce qui permet de les récupérer automatiquement en reposant sur l’algorithme de récupération de la mémoire existant. Nous nous reposons également sur cet algorithme pour détecter une reprise d’activité du nœud, ce qui lui permet de suspendre temporairement le service de cache qu’il offre à d’autres nœuds afin de ne pas dégrader ses propres performances. Couplé à une autre approche basée sur l’acti-vité du shadow page cache du noyau Linux, nous arrivons à détecter rapidement une reprise d’activité cache et à suspendre Puma de façon continue jusqu’à ce que l’activité ne s’arrête.
6.5. Discussion 87 VM reprend. En effet, une approche « naïve » et précise consisterait à désactiver Puma lors d’un accès disque ou d’une activation d’une page. Dans ce cas, Puma risquerai d’être désactivé en permanence, ne serait-ce que parce que certaines tâches du système telles que les journaux font régulièrement de courtes E/S, qui désactiveraient le service alors qu’elles ne nécessitent pas particulièrement de cache. Ainsi, si nos heuristiques permettent de détecter une reprise d’activité, elles nécessitent un certain temps avant que l’activité ne soit réellement détectée :
— pour le shadow page cache, un hit dans celui-ci ne peut se produire que lorsqu’une page, potentiellement chaude, a déjà été évincée ;
— pour le rééquilibrage des listes LRU, il faut attendre que :
1. le page cache soit entièrement rempli, sinon le PFRA ne s’active pas ; 2. la taille de la liste active atteigne 50% de la totalité du page cache.
Chapitre
7
Évaluation de l’automatisation de Puma
Sommaire
7.1 Plateforme expérimentale . . . 89 7.1.1 Benchmarks . . . 90 7.2 Récupération automatique du cache pour de la mémoire anonyme . . 91 7.2.1 Analyse de la récupération de la mémoire . . . 91 7.2.2 Efficacité de la récupération : vitesse des allocations . . . 93 7.2.3 Étude de cas : la consolidation sur un serveur unique . . . 94 7.3 Surcout du mécanisme de partage automatique . . . 97 7.4 Analyse du seuil de désactivation des pages . . . 100 7.5 Conclusion . . . 103
Ce chapitre présente une évaluation globale des mécanismes de gestion dynamique de la mémoire de Puma présentés dans le chapitre 6. Nous présentons dans un pre-mier temps la plateforme et les benchmarks que nous avons utilisé (section 7.1). La section 7.2 démontre l’efficacité de Puma à récupérer la mémoire prêtée par un nœud pour allouer de la mémoire anonyme. Nous présentons dans la section 7.3 le surcout des mécanismes de partage dynamique du cache de Puma. La section 7.4 présente quant à elle une analyse de sensibilité au seuil de désactivation des pages actives, puis la section 7.5 conclut ce chapitre.
7.1 Plateforme expérimentale
Les expérimentations présentées dans ce chapitre ont été effectuées sur une station de travail équipée d’un processeur Intel Core i7-2600 (3.4 GHz), de 8 Go de RAM et d’un
disque dur classique de 1 To avec une vitesse de rotation de 7200 rpm. L’environnement utilisé est similaire à celui présenté dans la section 5.1, que nous rappelons brièvement ici.
Les benchmarks sont déployés dans des machines virtuelles (VMs) en utilisant l’hy-perviseur KVM [56] avec la version 1.7.50 de QEMU. Les disques virtuels sont paramé-trés pour contourner le page cache du système hôte et nous utilisons l’ordonnanceur d’entrées/sorties (E/S) deadline et le système de fichiers ext4. Nous utilisons également le framework de paravirtualization VirtIO [84] pour accélérer les E/S. Les VMs utilisées sont identiques à celles utilisées dans les chapitres 5 et 6 et sont déployées à l’aide de notre plateforme d’expérimentations dérivée de Mosbench [19].
7.1.1 Benchmarks
Les évaluations de ce chapitre reposent essentiellement sur deux microbenchmarks, le premier a pour objectif de générer des E/S, le second permet de générer des alloca-tions de mémoire pour simuler une application gourmande en mémoire.
Lectures aléatoires. Nous utilisons Filebench [70], présenté dans la section 5.1.1, pour générer des lectures aléatoires simulant une activité intensive en E/S. Nous avons modifié le benchmark d’origine de façon à reporter en temps réel le nombre d’E/S par seconde, avec une granularité de 5 secondes. En effet, le résultat du benchmark original est une métrique finale, or nous voulons ici étudier l’évolution des performances au cours du temps.
Nous utilisons dans ce chapitre des blocs de 64 ko, la taille du fichier utilisé est variable, elle est précisée lors de la description de chacune des expériences.
Allocations de mémoire. Afin de générer des allocations de mémoire, nous avons développé un microbenchmark qui alloue (malloc) progressivement toute la mémoire de la VM sur laquelle il s’exécute. Ces allocations sont effectuées par petits fragments, de taille fixe, que nous validons en écrivant des données dans chacun d’eux pour s’as-surer que les pages ont réellement été allouées à la VM par le système d’exploitation. Nous mesurons le temps nécessaire pour créer chaque fragment (allocation + ´ecriture), ce qui permet de mesurer le ralentissement dû à Puma subit par la VM. Une fois la mé-moire allouée, le benchmark temporise puis libère progressivement la mémé-moire.