Quelques pistes d’optimisation pour vos machines virtuelles

Cet article a été publié il y a 7 ans 2 mois 8 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

La virtualisation a vraiment révolutionné la façon de fonctionner des hébergeurs, et même d’amateurs avertis, en permettant de limiter le nombre de machines physiques pour adresser un nombre grandissant de besoins client. Mais qui dit changement d’architecture dit contraintes particulières, et pour tirer le maximum des performances de son instance virtuelle, notamment sous Linux, il est nécessaire de procéder à quelques ajustements, qui de toute façon seront bienvenus, et certains même réutilisables sur une installation plus classique.

Utiliser les drivers du matériel virtuel

Quelque soit l’hyperviseur, celui-ci présente à l’instance virtuelle du matériel qui permet d’optimiser autant que possible toute la communication avec du matériel réel. En premier lieu, les contrôleurs disque et réseau. C’est plus performant qu’une émulation complète, mais pour être exploité ça demande des pilotes spécifiques.

Sur Proxmox à la création de la VM vous pouvez utiliser Virtio, les drivers idoines étant inclus dans le noyau Linux et donc automatiquement pris en charge. Il est même possible d’utiliser les drivers Virtio sous Windows. Si votre hyperviseur est VMware, installez les VMware Tools. Virtualbox propose des « guest additions », parfois proposées dans les dépôts des distributions pour les invités (et même déjà installés pour certaines), sinon chaque version propose de les installer depuis un CD « virtuel ». Microsoft a carrément poussé les sources des pilotes pour Hyper-V, la technologie de virtualisation embarquée dans Windows Server et au logiquement cœur d’Azure, leur plateforme cloud publique, au sein du noyau Linux.

Le disque, cet ennemi terrible

C’est l’un des principaux points qui restent problématiques, même sur une machine physique classique. Et bien qu’on commence à réduire le problème de temps d’accès physique à partir de SSD, dans le cadre de la virtualisation, sur des grosses infrastructures on passe par le réseau pour accéder à son disque. Il y a donc pleins de trucs à faire pour en tirer le meilleur.

Le RAMdisk pour certains dossiers temporaires

Les dossiers temporaires, par principe, sont temporaires (badum tss). Si leur contenu est inutile à terme, mais qu’ils sont fréquemment utilisés, alors pour éviter des accès disque, on peut, si on dispose de suffisamment de mémoire, monter un dossier directement en mémoire vive avec tmpfs. Sans même parler de limiter les I/O, ça sera beaucoup, beaucoup plus rapide. Mais vous êtes limités par la quantité de RAM de votre instance.

Ajuster le swapiness

J’en ai déjà parlé, avec le réglage par défaut le noyau a tendance à coller des choses en swap un peu trop rapidement alors qu’il y a plein de mémoire libre. Le swap étant par définition sur disque, ben voilà…

Remplir l’espace libre de zéro

Hein ? Ah oui, il faut qu’on parle de réservation fine. Un disque virtuel est souvent constitué d’un fichier plat. Le thin provisioning consiste à ne consommer réellement sur le disque physique (ou la grappe de disque, puisque c’est souvent un gros système de stockage partagé, sorte de méga RAID matériel), que la partie réellement consommée par l’environnement virtuel. En clair, quand vous faites du thin provisioning, si vous créez un disque de 50Go, mais n’en consommez que 3, le fichier fera 3Go, et il grossira en fonction. C’est pratique, vous pouvez déclarer beaucoup plus d’espace disque que vous n’en avez réellement, en partant du principe que tout le monde ne consommera pas ce qu’il a demandé.

Seulement, quand il s’agit de consommer un espace disque « nouveau », les performances s’écroulent, sans parler du potentiel de splitter son disque virtuel sur plusieurs emplacements physiques. Forcer l’écriture des zéros permet de réserver d’emblée l’intégralité du disque, et donc du fichier. Mais ça a un impact non négligeable : la sauvegarde se fera sur l’intégralité du disque, et vous perdez l’intérêt du thin provisioning. Donc à vous de voir.

Changer d’ordonnanceur d’entrées/sorties

Historiquement, pour optimiser les opérations sur disque, qui sont traditionnellement lentes sur support physique, les développeurs du noyau ont pensé et codées plusieurs méthodes, et l’ordonnanceur est le chef d’orchestre de ces optimisations. Dans le cadre d’une machine virtuelle, le stockage étant déporté, ces optimisations sont directement prises en charge par le contrôleur de la grappe de stockage. Il n’est donc plus nécessaire de dépenser des cycles CPU en calculs devenus inutiles, et par chance, sous Linux on peut modifier l’ordonnanceur, pour noop (pour no-optimization) :

Pour le faire en live pour le disque concerné, GRUB pour la persistance.

Désactiver certaines opérations du système de fichiers

La date d’accès d’un fichier n’a que peu d’intérêt, à moins de vouloir en faire des statistiques. Hors, mettre à jour cette date consomme des opérations disque. Et ça tombe bien, il y a des options de montage pour nos systèmes de fichiers qui permettent ça : exemple sur une de mes VMs :

Les noatime (pour no access time), nodiratime (no directory access time), sont là pour dire de ne plus mettre à jour l’accès. Quand pour info, ces valeurs sont disponibles avec la commande stat :

Utiliser un stockage SSD

Même distant, un stockage de type SSD reste plus réactif qu’un stockage à base de plateaux. Pour les détails techniques je vous renvoie vers l’article, toujours d’actualité, que j’ai écrit il y a déjà un petit moment maintenant. Si vous en avez les moyens (parce que ça reste généralement plus cher), il sera préférable d’utiliser un tel support en cas de forts besoins.

Et potentiellement d’autres

Je n’ai pas la science infuse, ces petits conseils découlent de mes lectures et parfois de mes expérimentations. Il y a certainement bien d’autres possibilités, certaines dépendantes des applications que vous utiliserez dans de tels environnements. Je pense notamment à sysstat, qui n’est pas recommandé dans un environnement virtuel (la conso CPU et RAM étant biaisée par ce que masque l’hyperviseur à l’invité), ou le NTP pour s’assurer d’un temps système stable (pratique pour la crypto).