Quel est le surcoût de la virtualisation x86 / x64?

Combien de frais généraux la virtualisation x86 / x64 (j'utiliserai probablement VirtualBox, possiblement VMWare, certainement pas la paravirtualisation) a-t-elle pour chacune des opérations suivantes un hôte Win64 et un invité Linux64 utilisant la virtualisation matérielle Intel?

• Code 64 bits en mode utilisateur purement lié au processeur

• Code 32 bits en mode utilisateur purement lié au processeur

• Fichier E / S sur le disque dur (je me soucie principalement du débit, pas de la latence)

• E / S réseau

• Primitives de synchronisation des threads (mutex, sémaphores, variables de condition)

• Commutateurs de contexte de thread

• Opérations atomiques (en utilisant le lockpréfixe, des choses comme comparer et échanger)

Je suis principalement intéressé par le cas x64 assisté par matériel (Intel et AMD), mais cela ne me dérangerait pas d'entendre parler de la traduction binaire non assistée et des cas x86 (c'est-à-dire hôte et invité 32 bits). Je ne suis pas intéressé par la paravirtualisation.

J'ai trouvé qu'il n'y a pas de réponse simple et absolue à des questions comme la vôtre. Chaque solution de virtualisation se comporte différemment lors de tests de performances spécifiques. De plus, des tests comme le débit d'E / S disque peuvent être divisés en de nombreux tests différents (lecture, écriture, réécriture, ...) et les résultats varient d'une solution à l'autre et d'un scénario à l'autre. C'est pourquoi il n'est pas trivial de pointer une solution comme étant la plus rapide pour les E / S disque, et c'est pourquoi il n'y a pas de réponse absolue pour les étiquettes comme la surcharge pour les E / S disque.

Cela devient plus complexe lorsque vous essayez de trouver une relation entre différents tests de référence. Aucune des solutions que j'ai testées n'avait de bonnes performances sur les tests de micro-opérations. Par exemple: dans VM, un seul appel à "gettimeofday ()" a pris, en moyenne, 11,5 fois plus de cycles d'horloge pour terminer que sur le matériel. Les hyperviseurs sont optimisés pour les applications du monde réel et ne fonctionnent pas bien sur les micro-opérations. Cela peut ne pas être un problème pour votre application qui peut mieux convenir à une application réelle. Je veux dire par micro-opération toute application qui passe moins de 1 000 cycles d'horloge à terminer (pour un processeur 2,6 GHz, 1 000 cycles d'horloge sont dépensés en 385 nanosecondes, soit 3,85e-7 secondes).

J'ai effectué des tests de référence approfondis sur les quatre principales solutions de consolidation de centres de données pour l'architecture x86. J'ai fait près de 3000 tests comparant les performances à l'intérieur des machines virtuelles aux performances matérielles. J'ai appelé «frais généraux» la différence entre les performances maximales mesurées à l'intérieur des machines virtuelles et les performances maximales mesurées sur le matériel.

Les solutions:

• VMWare ESXi 5
• Microsoft Hyper-V Windows 2008 R2 SP1
• Citrix XenServer 6
• Red Hat Enterprise Virtualization 2.2

Les OS invités:

• Microsoft Windows 2008 R2 64 bits
• Red Hat Enterprise Linux 6.1 64 bits

Informations sur le test:

• Serveurs: 2X Sun Fire X4150 chacun avec 8 Go de RAM, 2 processeurs Intel Xeon E5440 et quatre ports Ethernet gigabit
• Disques: 6 disques SAS de 136 Go sur iSCSI sur Gigabit Ethernet

Logiciel de référence:

• CPU et mémoire: référence Linpack pour 32 et 64 bits. Ceci est gourmand en CPU et en mémoire.

• E / S de disque et latence: Bonnie ++

• E / S réseau: Netperf: TCP_STREAM, TCP_RR, TCP_CRR, UDP_RR et UDP_STREAM

• Micro-opérations: rdtscbench : Appels système, communication inter-process pipe

Les moyennes sont calculées avec les paramètres:

• CPU et mémoire: MOYENNE (HPL32, HPL64)

• E / S disque: MOYENNE (put_block, rewrite, get_block)

• E / S réseau: MOYENNE (tcp_crr, tcp_rr, tcp_stream, udp_rr, udp_stream)

• Micro-opérations MOYENNE (getpid (), sysconf (), gettimeofday (), malloc [1M], malloc [1G], 2pipes [], simplemath [])

Pour mon scénario de test, en utilisant mes métriques, les moyennes des résultats des quatre solutions de virtualisation sont:

Surcharge de la couche VM, invité Linux:

• CPU et mémoire: 14,36%

• E / S réseau: 24,46%

• E / S disque: 8,84%

• Latence du disque pour la lecture: 2,41 fois plus lente

• Temps d'exécution des micro-opérations: 10,84 fois plus lent

Surcharge de la couche VM, invité Windows:

• CPU et mémoire moyenne pour 32 et 64 bits: 13,06%

• E / S réseau: 35,27%

• E / S disque: 15,20%

Veuillez noter que ces valeurs sont génériques et ne reflètent pas le scénario de cas spécifique.

Veuillez consulter l'article complet: http://petersenna.com/en/projects/81-performance-overhead-and-comparative-performance-of-4-virtualization-solutions

Il y a trop de variables dans votre question, mais je pourrais essayer de le réduire. Supposons que vous optez pour VMware ESX, vous faites tout correctement - le dernier processeur avec prise en charge de la virtualisation, les outils VMware avec stockage paravirtualisé et les pilotes réseau, beaucoup de mémoire. Supposons maintenant que vous exécutez une seule machine virtuelle sur cette configuration. D'après mon expérience, vous devriez avoir ~ 90% de la vitesse du processeur pour la charge de travail liée au processeur. Je ne peux pas vous en dire beaucoup sur les vitesses du réseau, puisque nous utilisons des liaisons 1 Gbit / s et que je peux le saturer sans problème, cela peut être différent avec une liaison 10 Gbit / s mais nous n'en avons pas. Le débit de stockage dépend du type de stockage, je peux obtenir environ 80% du débit de stockage avec le stockage local, mais pour NFS 1 Gbit / s, il est proche de 100% car la mise en réseau est un goulot d'étranglement ici. Ne peut pas parler d'autres statistiques,

Ces chiffres sont très approximatifs et dépendent fortement de votre type de charge, de votre matériel, de votre réseau. Cela devient encore plus flou lorsque vous exécutez plusieurs charges de travail sur le serveur. Mais ce que je veux dire ici, c'est que dans des conditions idéales, vous devriez être en mesure d'obtenir près de 90% des performances natives.

D'après mon expérience, le problème beaucoup plus important pour les applications hautes performances est la latence et c'est particulièrement vrai pour les applications client-serveur. Nous avons un moteur de calcul qui reçoit les demandes de plus de 30 clients, effectue des calculs courts et renvoie les résultats. Sur le métal nu, il pousse généralement le processeur à 100%, mais le même serveur sur VMware ne peut charger le processeur qu'à 60-80% et cela est principalement dû à la latence dans le traitement des demandes / réponses.

Je n'ai pas creusé les performances des primitives de base comme le changement de contexte et les opérations atomiques, mais voici mes résultats d'un test de force brute que j'ai effectué récemment avec différents hyperviseurs. Cela devrait indiquer ce à quoi vous pourriez vous attendre si vous êtes principalement limité en termes de bande passante CPU et RAM.

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/