Performances des serveurs de jeu : bare metal ou machines virtuelles

La réponse courte

Le bare metal l'emporte sur les deux chiffres qui décident si un serveur de jeu est agréable : le temps de tick dans le pire cas et la latence dans le pire cas. Une machine virtuelle mono-locataire sur du matériel que vous contrôlez s'en approche assez pour que la plupart des joueurs ne voient jamais la différence. Un VPS multi-locataire survendu, le genre qui remplit le bas de gamme de l'hébergement de jeux, est l'endroit où tout déraille, parce que ce que fait un hyperviseur sous contention (faire attendre votre CPU à son tour) est précisément ce qu'une boucle de jeu à tick fixe ne peut pas absorber.

Voilà tout l'argument en un paragraphe. Un serveur de jeu ne se juge pas sur la quantité de travail qu'il abat en une seconde ; il se juge sur la capacité de chaque tick à finir dans son budget. Un seul tick manqué et chaque joueur connecté le voit : rubber-banding, un tir qui n'est pas comptabilisé, un retour en arrière. Le débit moyen peut sembler parfait pendant que le pire pour cent des ticks gâche la partie sans bruit. La virtualisation ajoute de la variance précisément à ce pire pour cent, et la virtualisation bon marché en ajoute beaucoup.

La position honnête est donc conditionnelle, pas partisane. Le bare metal est le choix sûr par défaut pour tout ce qui est compétitif ou très fréquenté. Une VM convient, et vaut parfois mieux, quand l'hyperviseur vous appartient et que vous décidez qui d'autre tourne sur la machine. Un VPS partagé chez un hébergeur qui vend quatre fois plus de vCPU qu'il n'a de cœurs est la configuration qui produit les fils de discussion « pourquoi mon serveur lague ». Cet article explique le mécanisme derrière chacun de ces cas et montre comment mesurer celui dans lequel vous vous trouvez.

Ce guide couvre :

• ce qu'un hyperviseur ajoute à une boucle de tick : ordonnancement des vCPU, steal time, gigue des timers, NUMA et chemins d'E/S
• pourquoi la simulation à tick fixe se soucie du tick au 95e percentile, pas de la moyenne
• l'économie de la surallocation qui fait laguer l'hébergement de jeux sur VPS bon marché
• comment mesurer le steal time et le temps de tick sur votre propre serveur, avec de vraies commandes
• pourquoi les conteneurs ne sont pas des VM, et quand une VM est le bon outil

Pour le cadre plus large (hébergement managé contre machine à vous, et choix du matériel), le guide de l'hébergement de jeux sur bare metal est l'article pilier dont celui-ci dépend.

Ce qu'un hyperviseur ajoute

Commençons par la version rassurante. Un hyperviseur moderne comme KVM exécute les instructions CPU de l'invité sur le vrai processeur, avec assistance matérielle (VT-x ou AMD-V). En calcul brut, une VM tourne à quelques pour cent du natif, et si un serveur de jeu était limité par le CPU au sens « traiter un gros tableau », la virtualisation compterait à peine. Ce n'est pas le cas, et tout est là. Un serveur de jeu est limité par la latence sur un calendrier répétitif, et l'hyperviseur se place entre ce calendrier et le matériel. Voici ce qu'il y insère.

Ordonnancement des vCPU et steal time. Les CPU virtuels de votre VM ne sont pas des CPU ; ce sont des threads que l'ordonnanceur de l'hôte exécute sur de vrais cœurs quand il le décide. Quand l'hôte est occupé par d'autres invités, des processus hôtes ou des interruptions, votre vCPU attend dans une file d'exécution qu'un cœur physique se libère. Cette attente est le steal time CPU, affiché %st ou st dans top, vmstat et mpstat. C'est du temps pendant lequel votre boucle de jeu voulait le CPU et ne l'a pas eu. Sur une machine avec assez de cœurs pour tous les invités, il reste proche de zéro ; en surallocation, il grimpe, et chaque milliseconde de steal est une milliseconde de retard pour votre tick. L'analyse du steal time par Leaseweb fixe la règle empirique : un steal soutenu au-dessus de 10 pour cent signifie que l'invité tourne plus lentement qu'il ne devrait.

Gigue des timers et des interruptions. Une boucle de jeu se réveille sur un timer 20 ou 64 fois par seconde. Sous virtualisation, cette interruption de timer passe elle-même par l'hyperviseur, qui ajoute à chaque réveil de petits délais variables. Sur un hôte inactif, le délai est négligeable. Sous charge, le réveil peut dériver de plusieurs millisecondes, et une boucle qui se réveille en retard finit en retard.

Effets NUMA. Sur un serveur à deux sockets, la mémoire rattachée à un socket est plus lente à atteindre depuis l'autre. Si l'hyperviseur place vos vCPU sur un socket alors que la mémoire de votre VM se trouve sur l'autre, chaque accès paie la pénalité inter-nœuds. Le bare metal obéit à la même physique, mais le système d'exploitation voit la vraie topologie et place les threads en conséquence ; une VM voit souvent une topologie aplatie et synthétique, à moins que l'hôte n'expose délibérément la vraie.

Memory ballooning. Le périphérique virtio-balloon permet à l'hôte de reprendre de la RAM à un invité en gonflant un « ballon » à l'intérieur. Pratique pour la densité, hostile à un serveur de jeu : si l'hôte récupère de la mémoire qu'utilisait votre JVM ou votre processus de jeu, vous obtenez du swap ou une pression sur le garbage collection au pire moment. Sur les hôtes survendus, le ballooning est ce qui permet à un fournisseur de caser plus d'invités qu'il n'a de RAM.

Chemins d'E/S virtio. Le disque et le réseau passent par des pilotes paravirtualisés (virtio-blk et virtio-net, généralement avec vhost). Ils sont rapides, mais pas gratuits. Chaque paquet et chaque lecture disque franchit une frontière de plus que sur du bare metal. Pour un monde Minecraft qui charge des chunks, ou un serveur chargé qui écrit des logs et des sauvegardes de monde, ce chemin plus long se traduit par des blocages d'E/S occasionnels qui allongent un tick. La même taxe VirtIO est traitée sous l'angle des conteneurs dans notre comparatif LXC vs KVM.

Pris un par un, ces coûts sont faibles. Le problème, c'est qu'ils tombent tous sur la même victime : le tick qui doit finir en 50 millisecondes, ou en 15.

Pourquoi seul le pire tick compte

Un serveur Minecraft effectue 20 ticks par seconde, ce qui laisse à chaque tick 50 millisecondes pour tout faire : IA des mobs, redstone, mises à jour de blocs, déplacement des entités, puis envoi du monde à chaque joueur. Restez dans le budget et le serveur tient 20 TPS. Dépassez-le et le tick s'allonge, le suivant démarre en retard, et le temps ralentit sur le serveur pour tout le monde à la fois. CS2 fait tourner sa simulation à 64 ticks, soit environ 15,6 millisecondes par tick, avec un système de subtick qui horodate les entrées entre les ticks pour qu'un tir atteigne l'endroit où il a été tiré. Un tick lent retarde tout de même le moment où ces entrées sont traitées.

Voici ce qui piège la planification de capacité : ce sont des problèmes de pire cas, pas de moyenne. Un serveur peut tourner en moyenne à 19,9 TPS et donner une sensation désastreuse parce qu'une fois par seconde, un tick prend 180 millisecondes. Les moyennes masquent cela ; les percentiles, non. Le chiffre utile est le temps de tick au 95e percentile (p95), pas la moyenne, parce qu'il montre à quoi ressemblent vos ticks lents, et ce sont les ticks lents que les joueurs ressentent.

Un hyperviseur qui ajoute 8 millisecondes de steal ici et 12 millisecondes de délai d'ordonnancement là ne fera guère bouger votre moyenne. Il détruira votre p95. C'est toute la raison pour laquelle le bare metal et une VM bien gérée peuvent afficher le même TPS moyen tout en donnant des sensations complètement différentes en plein affrontement. La moyenne dit « ça va » ; le 95e percentile dit « ça saccade sous charge », et seul le second correspond à ce que vivent les joueurs.

Surallocation : pourquoi l'hébergement de jeux sur VPS bon marché lague

L'économie de l'hébergement VPS à petit prix est simple, et elle joue contre vous. Un hébergeur dispose d'une machine avec, disons, 32 cœurs physiques. Vendue honnêtement en cœurs dédiés, elle accueille un nombre fixe de clients. Vendue en vCPU avec une surallocation de 4:1, elle représente 128 vCPU d'offres sur le même silicium. La plupart du temps, la plupart des invités sont inactifs, donc le calcul tient et l'hébergeur gagne de l'argent.

Dès que plusieurs de vos voisins s'activent en même temps (une sauvegarde, un autre serveur de jeu qui se remplit, quelqu'un qui lance une compilation), l'ordonnanceur de l'hôte a plus de vCPU prêts à tourner que de cœurs, et c'est le vôtre qu'il fait attendre. Cette attente est le steal time de la section précédente, et vous n'y pouvez rien, parce que la contention vient de locataires que vous ne voyez pas. C'est le problème du voisin bruyant, et pour une charge à tick fixe, c'est presque le pire cas : votre budget de tick est fixé à 50 ou 15 millisecondes, mais le temps CPU que vous recevez devient une loterie tirée par la charge des autres. C'est aussi pourquoi un VPS peut briller dans un benchmark à 3 h du matin et s'écrouler à l'heure de pointe, sur la même offre, sans que rien n'ait changé de votre côté.

Comment le mesurer sur votre propre serveur

Assez de théorie. Voici comment savoir si la virtualisation vous coûte réellement quelque chose, sur la machine que vous avez.

Steal time. Lancez top et lisez la valeur st sur la ligne %Cpu(s) :

%Cpu(s): 42.1 us,  3.2 sy,  0.0 ni, 38.0 id,  0.0 wa,  0.0 hi,  1.1 si, 15.6 st

Le 15.6 st est le chiffre qui compte : 15,6 pour cent du temps, ce vCPU voulait s'exécuter et ne le pouvait pas, parce que l'hôte était occupé ailleurs. vmstat 1 affiche le même chiffre dans sa colonne st la plus à droite, une fois par seconde, et mpstat -P ALL 1 détaille %steal par cœur :

vmstat 1
mpstat -P ALL 1

Sur du bare metal, st vaut toujours 0, puisqu'il n'y a pas d'hyperviseur pour voler du temps, et c'est en soi un indice. Si vous voyez du steal, vous êtes sur un invité ; si vous voyez un steal soutenu à deux chiffres, votre hôte est en surallocation. Ces sorties sont données à titre d'illustration. Vos valeurs varieront selon le matériel, la charge et l'activité de vos voisins.

Temps de tick Minecraft. Installez le profileur spark (un plugin ou un mod, selon la variante de votre serveur) et lancez /spark tps. Spark rapporte le TPS par rapport à l'objectif de 20, et la durée des ticks par rapport au budget de 50 millisecondes, avec le MSPT minimum, médian, au 95e percentile et maximum :

/spark tps
TPS from last 5s, 10s, 1m, 5m, 15m:
  17.9, 18.8, 19.7, 20.0, 20.0
Tick durations (min/med/95%ile/max ms) from last 10s, 1m:
  22/47/96/210;  20/43/71/180

Surveillez la colonne 95%ile, pas la médiane. Une médiane de 47 millisecondes avec un 95e percentile à 96, c'est un serveur qui paraît sain en moyenne et qui saccade sous charge. Sur un invité en surallocation, ce chiffre au 95e percentile et votre steal time montent ensemble, et c'est ainsi que l'on relie le symptôme à sa cause. /spark health donne le même TPS et le même MSPT avec le CPU et la mémoire dans un seul instantané. (Sortie représentative.)

Serveurs Source et CS2. La commande console stats affiche l'utilisation CPU et un chiffre fps qui suit le tick rate : un serveur sain à 64 ticks affiche un fps égal ou légèrement supérieur à 64, plafonné par le tick rate, et chaque baisse sous charge correspond à une image que la simulation n'a pas pu terminer à temps. Lancez-la plusieurs fois de suite pour voir la variance, car une seule ligne n'est qu'un instantané.

La façon la plus propre d'isoler le coût de l'hyperviseur est de garder tout le reste constant : même CPU, même RAM, même version du jeu, même charge, et de ne changer qu'une chose, le fait que le serveur tourne sur bare metal ou dans un invité KVM sur ce matériel identique. C'est un test à faire dans un labo contrôlé plutôt qu'à débattre à partir de principes.

Ce que cette mesure chiffrerait ne fait pas débat : sur un matériel identique, l'exécution en bare metal garde un temps de tick au 95e percentile plus bas et plus stable, et le désavantage de l'invité grandit avec la charge. Ce qu'un benchmark tranche, c'est la taille de l'écart sur une VM mono-locataire que vous contrôlez, généralement faible, par rapport à ce qu'en fait la surallocation, qui ne l'est pas.

Les conteneurs ne sont pas des machines virtuelles

Une bonne partie de l'inquiétude autour de la virtualisation disparaît dès que l'on distingue conteneurs et VM, car le compromis n'est pas le même. Un conteneur système LXC ou un conteneur Docker partage le noyau de l'hôte. Il n'y a ni noyau invité, ni matériel virtuel, ni couche d'ordonnancement de vCPU entre votre processus et le cœur. Il n'y a donc pratiquement pas de steal time ni de gigue liée à la virtualisation des timers : un serveur de jeu conteneurisé sur bare metal tourne à une vitesse quasi native, avec un cgroup qui plafonne le CPU et la mémoire qu'il peut consommer. Le surcoût est une erreur d'arrondi.

« Je veux faire tourner plusieurs serveurs de jeu isolés sur une seule machine » n'exige donc pas de VM. Les conteneurs offrent des limites de ressources par serveur, un empaquetage propre et des performances quasi natives sur le même noyau, ce que fait sous le capot un panneau de jeu comme Pterodactyl. Les compromis qui existent (isolation plus faible qu'une VM, noyau partagé, pas de migration à chaud) concernent la sécurité et l'exploitation, pas les performances de tick, et nous les traitons en détail dans LXC vs KVM dans Proxmox. Pour les performances brutes d'un serveur de jeu, le conteneur sur bare metal est l'option quasi native ; la VM est celle qui ajoute la couche d'ordonnancement dont parle tout cet article.

Quand une VM est le bon choix

L'ennemi n'est pas la virtualisation, c'est la surallocation. Il existe de vrais cas où une VM est le bon outil, et ils ont un point commun : c'est vous qui maîtrisez la contention.

• Serveurs de dev, de staging et de test. L'expérience compétitive de personne ne dépend du tick p95 d'une machine de staging. Créez des VM sans compter ; l'isolation et le confort des snapshots valent plus que les dernières millisecondes.
• Petits serveurs ou serveurs entre amis. Un serveur survie pour vous et une douzaine d'amis passe la plupart de ses ticks bien en dessous du budget. La marge est telle que le surcoût de l'hyperviseur ne devient jamais le goulot d'étranglement, et une VM modeste fait parfaitement l'affaire.
• Une VM sur votre propre hyperviseur. C'est le cas important. Si vous louez une machine bare metal entière et y faites tourner votre propre hyperviseur, c'est vous qui décidez combien d'invités partagent les cœurs et s'ils sont en surallocation. Épinglez la VM de jeu sur des cœurs dédiés, ne surallouez pas, et vous obtenez l'essentiel de la souplesse de la virtualisation avec un steal time que vous maîtrisez au lieu d'un steal time que votre hébergeur vous impose. Toute la différence avec un VPS bon marché tient à qui prend la décision de surallocation.

La configuration à éviter pour tout ce qui est fréquenté ou compétitif est celle où quelqu'un d'autre a pris cette décision à votre place, et l'a tarifée de manière agressive.

Si vous devez virtualiser : les réglages utiles

Avec une VM sur du matériel que vous contrôlez, quelques réglages récupèrent l'essentiel des performances perdues dans le pire cas :

• Épinglez les vCPU sur des cœurs physiques. L'épinglage CPU (vcpupin dans libvirt) attache les vCPU de la VM de jeu à des cœurs physiques précis, pour que l'ordonnanceur arrête de les déplacer. Cela réduit la gigue et améliore le comportement du cache. Ne partagez pas ces cœurs épinglés avec d'autres invités.
• Utilisez le modèle de CPU de l'hôte. Configurez l'invité en host-passthrough (ou au moins host-model) pour que la VM voie le vrai CPU et tout son jeu d'instructions, au lieu d'un modèle au plus petit dénominateur commun qui laisse des performances sur la table.
• Ne surallouez pas les cœurs qui comptent. Faites correspondre les vCPU de la VM de jeu à de vrais cœurs, et gardez le total de vCPU engagés inférieur ou égal au nombre de cœurs physiques quand la stabilité du tick compte. La densité à laquelle vous renoncez, c'est la latence que vous gardez.
• Désactivez le ballooning pour la VM de jeu. Donnez-lui une réservation mémoire fixe pour que l'hôte ne puisse pas reprendre de RAM en pleine partie. Laissez le ballooning aux invités qui le supportent.
• Gardez les chemins rapides pour la carte réseau et le disque. Utilisez virtio avec vhost-net, et placez l'état du jeu sur NVMe. Le dimensionnement est traité dans le guide de dimensionnement des serveurs, qui défend aussi des cœurs moins nombreux et plus rapides plutôt que beaucoup de cœurs lents.

Rien de tout cela ne fait battre le bare metal par une VM. L'écart se réduit au point où, sur une machine que vous contrôlez, la différence cesse de compter pour la plupart des serveurs.

Le verdict, selon la situation

La latence est l'autre moitié de la sensation de jeu, et elle dépend surtout de la géographie et du routage plutôt que du choix entre bare metal et VM ; le guide de la latence des serveurs de jeu traite cet aspect.

Déployer sur Serverside.com

Si la charge est compétitive ou fréquentée, l'argument ci-dessus pointe dans une seule direction : la machine entière, sans hyperviseur entre votre boucle de tick et les cœurs. Un serveur de jeu Serverside.com est du bare metal mono-locataire sur notre propre réseau (AS55285) : pas de steal time, pas de voisins bruyants, et aucune surallocation décidée par quelqu'un d'autre que vous. Le provisionnement prend moins d'une minute, et une mitigation DDoS permanente protège l'interface publique, ce qui n'est pas facultatif pour un serveur de jeu. Si vous préférez découper vous-même une machine en VM, c'est possible aussi : louez le matériel dédié, faites tourner votre propre hyperviseur, et chaque décision de contention que cet article vous a appris à surveiller vous revient.

FAQ

Une VM ajoute-t-elle toujours du lag à un serveur de jeu ?

Non. Une VM sur du matériel que vous contrôlez, avec des vCPU épinglés et sans surallocation, ajoute un surcoût assez faible pour que la plupart des serveurs ne le remarquent jamais. Le lag que l'on attribue à la « virtualisation » vient presque toujours de la surallocation plutôt que de l'hyperviseur lui-même : un VPS partagé où votre temps CPU dépend de la charge des autres locataires. Le mécanisme sous-jacent est le steal time CPU, et vous pouvez le mesurer directement.

Qu'est-ce que le steal time CPU et à partir de quelle valeur pose-t-il problème ?

Le steal time (%st dans top) est le pourcentage du temps pendant lequel votre CPU virtuel était prêt à s'exécuter mais devait attendre que l'hôte lui attribue un cœur physique. Sur du bare metal, il vaut toujours zéro. Sur une VM saine, il reste proche de zéro. Une règle empirique courante veut qu'un steal soutenu au-dessus de 10 pour cent signifie que l'invité tourne plus lentement qu'il ne devrait, et pour un serveur de jeu à tick fixe, même quelques pour cent se traduisent par des ticks lents.

Pourquoi mon serveur de jeu sur VPS lague-t-il alors que l'utilisation CPU semble faible ?

Parce que l'utilisation CPU vue depuis l'invité ne montre pas la contention sur l'hôte. Votre serveur peut rester à 30 pour cent de CPU et manquer des ticks quand même si l'hôte fait sans cesse attendre votre CPU virtuel ; ce temps perdu apparaît comme du steal, pas comme de l'utilisation. Regardez la colonne st dans top ou vmstat 1. Un steal élevé avec une utilisation faible est la signature classique d'un VPS surchargé.

Les conteneurs sont-ils meilleurs que les VM pour les performances d'un serveur de jeu ?

En performances brutes, oui. Un conteneur Docker ou LXC sur bare metal partage le noyau de l'hôte : il n'y a donc ni couche d'ordonnancement de CPU virtuels ni steal time, et il tourne à une vitesse quasi native. Les VM offrent une isolation plus forte et des fonctions comme la migration à chaud que les conteneurs n'ont pas. Pour les performances de tick, un conteneur sur bare metal bat une VM ; pour isoler des locataires non fiables, la VM l'emporte. Notre comparatif LXC vs KVM détaille le compromis complet.

Comment savoir si la virtualisation pénalise mon serveur ?

Deux chiffres. Pour le steal time, lancez top, vmstat 1 ou mpstat -P ALL 1 et lisez la colonne st ou %steal. Pour la santé du tick sous Minecraft, installez le profileur spark et lancez /spark tps, en surveillant le MSPT au 95e percentile plutôt que la moyenne. Sur les serveurs Source et CS2, la commande stats affiche un chiffre fps qui suit le tick rate. Si le steal time et le temps de tick au 95e percentile montent ensemble, le problème vient de l'hôte.