Les Huge Pages offrent-elles un gain de performances mesurable aux machines virtuelles de laboratoire domestique ?

Les pages géantes peuvent offrir un avantage mesurable pour certaines machines virtuelles de laboratoire domestique, mais elles ne constituent pas un accélérateur universel de la virtualisation. Les meilleures candidates sont les charges de travail nécessitant beaucoup de mémoire et sensibles au TLB, comme les bases de données, les services en mémoire, les appliances de traitement de paquets et les machines virtuelles qui restent suffisamment sollicitées pour que la surcharge des tables de pages soit significative. Pour une machine virtuelle Home Assistant peu chargée, une petite machine virtuelle Linux utilitaire ou une machine de test utilisée occasionnellement, la différence peut être trop faible pour justifier de réserver de la RAM.

La règle pratique consiste à comparer les performances de la même machine virtuelle avec une mémoire normale et avec des pages géantes avant de les rendre permanentes. Linux propose déjà les pages géantes transparentes (THP), tandis que KVM/libvirt peut également utiliser des pages HugeTLB explicites pour la mémoire de la machine invitée. Les pages géantes statiques réduisent la flexibilité de l’hôte au profit d’une allocation plus prévisible en grandes pages ; ainsi, un serveur domestique avec peu de RAM ou un surengagement important peut perdre plus qu’il ne gagne.

Les pages géantes réduisent le travail de traduction des adresses, pas tous les goulots d’étranglement des machines virtuelles

La plupart des systèmes Linux x86 utilisent des pages de base de 4 KiB, tandis que des tailles de pages supérieures, telles que 2 MiB et 1 GiB, peuvent mapper beaucoup plus de mémoire avec une seule traduction. La documentation du noyau Linux sur les pages géantes transparentes explique l’avantage central : un mappage plus grand peut réduire les défauts de TLB, lesquels peuvent également coûter moins cher dans un environnement virtualisé avec des tables de pages imbriquées.

Le noyau documente également les réservations explicites HugeTLB dans son guide des pages HugeTLB, qui décrit le mécanisme des pages de grande taille réservées, utilisé lorsque vous souhaitez des tailles de pages prévisibles plutôt que de vous fier uniquement à la promotion transparente.

Cela n’a d’importance que lorsque la traduction d’adresses représente une part significative de la charge de travail. Les pages géantes n’accélèrent pas un disque lent, n’augmentent pas la bande passante réseau, ne résolvent pas la contention du processeur et ne compensent pas une quantité insuffisante de RAM allouée à la machine invitée. Si une machine virtuelle passe la majeure partie de son temps à attendre le stockage, des API distantes ou une application monothread, modifier la taille des pages de l’hôte peut à peine changer le résultat.

Quelles machines virtuelles de laboratoire domestique sont les plus susceptibles d’en bénéficier ?

Une machine virtuelle devient une meilleure candidate aux Huge Pages lorsque son ensemble de mémoire active augmente et reste fréquemment utilisé. Les bases de données dotées de grands pools de tampons, les caches en mémoire, les moteurs d’analyse, les routeurs virtuels à haut débit ainsi que certaines charges de jeu ou de compilation peuvent accéder de manière répétée à suffisamment de mémoire pour que la réduction du nombre d’entrées de traduction soit utile. Les recommandations de Red Hat pour KVM décrivent elles aussi les Huge Pages comme particulièrement pertinentes pour les charges de travail virtualisées utilisant beaucoup de mémoire et de grandes quantités de mémoire, dans leur documentation sur l’optimisation de la virtualisation.

Les petites machines virtuelles d’infrastructure sont différentes. Un résolveur DNS, un proxy inverse léger, un petit nœud de supervision ou un serveur d’automatisation peut n’utiliser activement qu’une fraction de la mémoire qui lui est attribuée. Dans ce cas, les principaux facteurs de performances sont plus probablement le comportement de l’application, la latence du stockage, l’ordonnancement du processeur, les chemins réseau ou les dépendances externes.

Si vous déterminez encore la capacité de virtualisation que l’hôte lui-même doit prendre en charge, l’exemple de configuration ZimaCube et Proxmox de ZimaSpace fournit un contexte utile : l’optimisation de la mémoire doit intervenir après que l’hôte dispose de suffisamment de RAM, de stockage et de capacité d’E/S pour les machines virtuelles que vous prévoyez réellement d’exécuter.

Les Transparent Huge Pages doivent faire partie de la référence

Une erreur courante lors de l’évaluation des performances consiste à comparer des pages Huge Pages statiques à un système qui bénéficiait déjà de THP, sans s’en rendre compte. Linux moderne peut regrouper de manière transparente la mémoire appropriée dans des mappages plus grands. La documentation du noyau indique que THP conserve davantage de fonctionnalités de gestion de la mémoire qu’une réservation HugeTLB fixe et peut utiliser la mémoire libre de manière plus flexible.

Cela signifie que la véritable comparaison n’est souvent pas « pages de 4 Kio contre pages de 2 Mio ». Il s’agit plutôt de comparer « le comportement THP normal de l’hôte aux pages HugeTLB explicitement réservées pour cette VM ». Si les THP capturent déjà une grande partie de la zone de mémoire utile, le gain supplémentaire des Huge Pages statiques peut être modeste.

Vérifiez l’hôte avant les tests :

cat /sys/kernel/mm/transparent_hugepage/enabled
grep -E 'AnonHugePages|HugePages|Hugepagesize' /proc/meminfo

Le noyau Linux expose également les compteurs THP dans /proc/vmstat, ce qui permet de vérifier que l’hôte alloue et regroupe effectivement les pages immenses, plutôt que de supposer que la fonctionnalité est active.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Les Huge Pages statiques privilégient la prévisibilité au détriment de l’élasticité

Libvirt peut demander explicitement des Huge Pages via la configuration <memoryBacking>. Sa documentation actuelle sur le XML des domaines permet de choisir les tailles de page et de les associer aux nœuds NUMA invités.

Proxmox expose la même idée sous-jacente dans sa configuration QEMU. Le schéma qemu-server actuel documente les choix de Huge Pages de 2 Mio et 1 Gio, ainsi qu’un mode de sélection automatique. C’est utile, car cela facilite l’activation de la fonctionnalité, mais il ne faut pas confondre facilité de configuration et accélération garantie.

Le coût est la mémoire réservée. Les pages HugeTLB statiques sont volontairement moins flexibles que la mémoire paginable ordinaire. Un hôte doté de 32 Go de RAM et de plusieurs VM dont la charge fluctue peut privilégier la mémoire récupérable plutôt qu’une légère réduction de la surcharge de traduction pour une seule VM. Si le lab à domicile dépend de l’allocation dynamique de mémoire, de la surallocation ou de changements rapides de densité des VM, mesurez le coût d’opportunité en plus du résultat du benchmark.

L’alignement NUMA devient plus important à mesure que l’hôte gagne en capacité

Sur un mini-PC à socket unique, la question de la NUMA n’est peut-être pas vraiment préoccupante. En revanche, sur une station de travail plus grande ou un serveur à double socket, les Huge Pages ne doivent pas être évaluées indépendamment de la localité du processeur et de la mémoire. Le modèle d’allocation mémoire de Libvirt peut associer les tailles de page aux nœuds NUMA, et ses contrôles de réglage NUMA déterminent où la mémoire invitée doit être allouée.

Un benchmark peut donc montrer une amélioration apparente avec les Huge Pages alors que l’amélioration réelle provient d’une meilleure localité, ou ne montrer aucun gain parce qu’une VM accède régulièrement à de la mémoire NUMA distante. Pour les hôtes de grande taille, testez ensemble l’épinglage du processeur, la topologie NUMA invitée et le placement de la mémoire, plutôt que de modifier uniquement la taille des pages.

Utilisez un test A/B reproductible plutôt qu’un chiffre synthétique accrocheur

La bonne question n’est pas de savoir si les Huge Pages ont déjà amélioré les performances de KVM. Elles le peuvent. La bonne question est de savoir si elles améliorent suffisamment votre VM pour compenser la perte de flexibilité mémoire.

Utilisez la même image de VM, le même nombre de vCPU, la même quantité de RAM, le même chemin de stockage, le même modèle de processeur, la même topologie NUMA et la même charge de travail pour les deux exécutions. Redémarrez l’hôte ou la VM entre les modes afin que la modification du support mémoire soit effectivement appliquée. Enregistrez ensuite à la fois les performances au niveau de l’application et le comportement de la mémoire de l’hôte.

Par exemple, exécutez un benchmark de base de données, une charge de compilation ou un test de traitement de paquets qui ressemble au véritable rôle de la VM, plutôt que de vous appuyer uniquement sur un microbenchmark de copie mémoire. Répétez chaque condition plusieurs fois et comparez les médianes ainsi que la latence de queue. Un gain synthétique de 2 % en mémoire qui ne modifie pas la latence du service constitue généralement un indice plus faible qu’une réduction constante du temps CPU ou de la latence des requêtes avec la charge de travail réelle.

Quand l’avantage est-il suffisamment important pour les conserver ?

Pour un lab à domicile, le seuil doit être opérationnel plutôt qu’idéologique. Conservez les Huge Pages statiques lorsque le résultat est reproductible, que la charge de travail est continuellement importante et que l’hôte dispose de suffisamment de RAM pour que la réservation des pages ne crée pas de pression ailleurs.

Les pages de grande taille sont une optimisation qui vient après les goulots d’étranglement principaux

N’activez pas les pages de grande taille avant d’avoir vérifié si la VM est limitée par le processeur, la capacité mémoire, le stockage ou le réseau. Un laboratoire domestique gagne généralement davantage à corriger d’abord les goulots d’étranglement évidents : suffisamment de RAM pour éviter le swapping, un stockage rapide pour les disques des VM, des périphériques VirtIO correctement configurés, un dimensionnement raisonnable des vCPU et le passthrough matériel uniquement lorsqu’il répond à un besoin réel.

La présentation de ZimaSpace consacrée aux serveurs d’occasion, aux mini-PC et au matériel NAS pour les laboratoires domestiques souligne le même point général : les performances de la virtualisation commencent par le choix d’un matériel adapté à la charge de travail. L’optimisation de la taille des pages intervient au second plan, une fois l’architecture de l’hôte correctement configurée.

Verdict final

Les pages de grande taille peuvent offrir un gain de performances réel, mais elles sont surtout utiles pour les grandes VM stables et gourmandes en mémoire, lorsque la pression exercée sur le TLB est mesurable. Pour les services typiques d’un petit laboratoire domestique, conservez le comportement mémoire par défaut jusqu’à ce qu’un benchmark contrôlé démontre le contraire.

Commencez par la configuration THP normale de l’hôte, mesurez une charge de travail réelle, puis testez explicitement des pages de grande taille de 2 Mio. Ne les conservez que si l’amélioration se confirme lors de tests répétés et si la RAM réservée ne réduit ni la fiabilité ni la densité du reste du serveur.

FAQ

Les pages de grande taille de 1 Gio sont-elles toujours plus rapides que celles de 2 Mio ?

Non. Les pages plus grandes couvrent davantage d’espace d’adressage par entrée du TLB, mais les allocations de 1 Gio sont beaucoup plus grossières et plus difficiles à réserver. La charge de travail et la disposition de la mémoire de l’hôte déterminent si elles sont utiles.

Chaque VM Proxmox doit-elle utiliser des pages de grande taille ?

Non. Les pages de grande taille constituent une option d’optimisation propre à la charge de travail. Les petites VM ou celles qui sont peu utilisées tirent souvent davantage parti d’une mémoire d’hôte flexible.

Les pages transparentes de grande taille rendent-elles les pages statiques de grande taille inutiles ?

Pas toujours. Les THP constituent un mécanisme automatique flexible, tandis que les pages HugeTLB statiques offrent un support plus explicite et prévisible. Comparez les deux avec la même charge de travail.

Que dois-je tester en premier ?

Testez d’abord le débit ou la latence de l’application, puis confirmez le mécanisme à l’aide des métriques de la mémoire de l’hôte et du TLB. Un nombre inférieur de défauts de TLB n’est utile que s’il améliore le service qui vous intéresse.