Convertir des Gio en Mio

Un gibioctet vaut 1 073 741 824 octets, environ 7 % de plus qu’un gigaoctet. Windows mesure en gibioctets tout en les étiquetant « Go », et c’est là tout le mystère de l’espace disque qui s’évapore.

Un mébioctet vaut 1 024 kibioctets, soit 1 048 576 octets. Les outils Linux et les chiffres de mémoire désignent presque toujours cela, même quand ils écrivent « Mo ».

Dans ce sens, l'opération est une multiplication, et par un nombre entier : un gibioctet fait 1 024 mébioctets, exactement, et 1 024 est la définition, pas une mesure tombée juste.

C'est donc une des rares conversions qui valent le coup de tête, et le résultat se vérifie : divisez en sens inverse et vous devez retomber exactement sur le nombre de départ, sans reste à justifier.

Un GiB vaut 1 024 fois l'unité du dessous ; un GB, 1 000. Sur cette page, c'est l'écart entre 1024 MiB et 953,6743 MiB — 7,4 % — et il grandit à chaque palier : négligeable sur une photo, visible sur un disque dur.

Le mystère de l'espace disque manquant tient tout entier là-dedans, et sur cette page il vaut 7,4 %. Un disque vendu en GB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 953,6743 MiB là où la boîte annonçait 1024 MiB. macOS compte ces tailles en unités décimales depuis 10.6, d'où le même disque qui paraît de deux tailles sur deux machines — rien n'a disparu et personne n'arrondit : les mêmes octets portent deux noms.

Le -m de QEMU est un nombre de mébioctets sans habillage. virt-install prend son --memory en mébioctets. La plupart des API d’hyperviseur ou de nuage écrites avant que les préfixes IEC n’aient un nom utilisent un champ qui s’appelle memoryMB, et la valeur y est binaire quoi que dise l’étiquette. Pendant ce temps, chaque catalogue d’instances, chaque plan de capacité, chaque document d’achat s’écrit en gibioctets, de sorte que la conversion arrive exactement au point où la taille cesse d’être une décision pour devenir un paramètre de configuration.

libvirt est l’exception qui mérite d’être sue, parce que le XML de domaine y laisse par défaut l’élément memory en kibioctets et non en mébioctets. Un invité de 8 GiB devient <memory unit=’KiB’>8388608</memory>, et une valeur qui ressemble à une coquille est presque toujours l’autre unité. L’élément accepte un attribut unit explicite, et écrire unit=’GiB’ dans un modèle que des humains éditent fait disparaître la question pour de bon.

Un invité auquel on attribue 8 192 MiB coûte à l’hôte cette part pour ses propres pages, plus un ensemble de structures qui n’existent que parce que la machine est virtuelle. Les tables de pages imbriquées font correspondre le physique vu par l’invité au physique de l’hôte, et leur taille suit celle de l’espace d’adressage de l’invité. Le modèle de périphérique tourne en processus sur l’hôte avec son propre tas. La mémoire vidéo émulée est une vraie allocation. L’hyperviseur tient de la métadonnée par page pour tout ce qu’il distribue.

Le total est en général un petit pourcentage plutôt qu’une valeur fixe, ce qui est la raison pour laquelle un hôte qui faisait tourner sans peine huit invités de 8 GiB ne fera pas quatre invités de 16 GiB alors que l’arithmétique est la même. Dimensionner un hôte en sommant les mébioctets attribués et en comparant à la mémoire installée ne laisse rien pour l’hyperviseur lui-même, et la panne au bout du chemin est la mise en swap de l’hôte — bien pire pour un invité que de lui avoir donné moins de mémoire dès le départ.

La mémoire d’un invité s’alloue en général à la première écriture, de sorte qu’un invité qui vient de démarrer avec 16 384 MiB d’attribution peut ne consommer qu’un dixième de cette valeur côté hôte. Le pilote de ballon permet à l’hyperviseur d’en reprendre davantage : il se gonfle à l’intérieur de l’invité, le noyau de l’invité libère des pages pour lui répondre, et l’hyperviseur les récupère. Le dégonflement les rend. La valeur attribuée devient un plafond plutôt qu’une réservation.

La conséquence pour l’arithmétique de capacité est qu’il y a trois nombres par invité, et un seul d’entre eux figure dans le fichier de configuration. Attribuée est ce que vous avez tapé ; la cible du ballon est ce que l’hyperviseur autorise à l’instant ; résidente est ce que l’hôte a réellement engagé. Un tableau de bord qui rapporte l’un des trois en gibioctets contre un plan bâti sur un autre sera faux d’un facteur qui change au cours de la journée.

Soutenir un invité en huge pages supprime un niveau de traversée de la table des pages, et l’effet se mesure sur les charges gourmandes en mémoire, mais cela change l’arithmétique. Les pages font 2 MiB au lieu de 4 KiB, de sorte que l’attribution doit être un multiple de 2 MiB ; le pool doit être réservé sur l’hôte à l’avance et n’est disponible pour rien d’autre ; et l’allocation paresseuse s’arrête, parce qu’un invité soutenu en huge pages prend son attribution complète dès le départ.

Cela transforme 8 192 MiB de plafond en engagement de 4 096 huge pages, et la surallocation devient impossible pour cet invité. Cela veut dire aussi que le pool de l’hôte doit être dimensionné dans la même unité : réserver 65 536 huge pages fait 128 GiB, et un hôte qui en réserve plus que ce qu’utilisent ses invités a retiré cette mémoire à tout le reste. Quand un invité utilise plutôt des huge pages de 1 GiB, l’attribution doit être un multiple de 1 024 MiB et la granularité d’une erreur est un gibioctet entier.

Sur un hôte à plusieurs nœuds mémoire, un invité plus gros qu’un nœud doit être réparti, et la répartition est bien meilleure quand elle est faite exprès plutôt que laissée à l’ordonnanceur. Un invité de 12 288 MiB sur deux nœuds fait 6 144 chacun, ce qui est net ; le même invité à 12 000 MiB fait 6 000 chacun, ce qui est correct arithmétiquement et inconfortable vis-à-vis des huge pages et de toute réservation par nœud.

La panne quand on la laisse implicite est l’accès mémoire distant : un vCPU épinglé à un nœud qui lit des pages résidant sur l’autre paie une latence à chaque accès, et l’effet est une charge plus lente que la même charge sur un hôte plus petit. virsh numatune et la topologie NUMA de l’invité lui-même comptent tous les deux, et tous deux se configurent en mébioctets par nœud, de sorte que le gibioctet doit se diviser proprement avant que rien de tout cela puisse s’exprimer.

Sommer les mébioctets attribués de tous les invités et diviser par la mémoire de l’hôte donne un ratio de surallocation, et les ratios jusqu’à environ 1,5 sont courants sur des charges où les invités sont peu actifs. La raison en est qu’attribuée est un plafond et que la plupart des invités ne s’en approchent jamais. La raison pour laquelle cela échoue est que les invités qui s’en approchent ont tendance à le faire en même temps, parce qu’ils répondent en général au même événement.

Le chiffre qui mérite d’être suivi en regard du ratio est la mémoire libre de l’hôte en mébioctets au pic, et non à la moyenne, et ce qu’il faut éviter est que l’hôte aille chercher de la swap. Un invité dont les pages sont évacuées par l’hôte la vit comme une mémoire devenue mille fois plus lente sans aucune indication de la cause, et la gestion mémoire de l’invité — qui croit ces pages en RAM — prend alors exactement les mauvaises décisions à leur sujet.

Le hotplug mémoire n’ajoute pas une quantité arbitraire. L’invité expose une taille de bloc — en général 128 MiB sur x86-64 — et la mémoire arrive en blocs entiers, de sorte qu’une demande de 1 000 MiB devient huit blocs et 1 024 MiB. Le retrait est plus difficile que l’ajout, parce que le noyau de l’invité doit d’abord libérer le bloc et peut en être incapable si quelque chose d’inamovible s’y est posé. Un invité qui est passé de 4 GiB à 12 ne reviendra pas toujours en arrière.

L’approche pratique est de dimensionner pour le jeu de travail avec la marge que la charge mérite, et de traiter la réduction comme un redémarrage plutôt que comme une opération en ligne. Quand un invité doit vraiment varier, le ballon est le mécanisme qui gère bien, et le hotplug est celui qui gère la croissance au-delà du plafond initial — et le plafond lui-même, la valeur maxMemory, est encore un champ en mébioctets qu’il faut fixer avant que l’invité ne démarre.