c - Hvorfor ville vores software køre så meget langsommere under virtualisering?

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg forsøger at finde ud af, hvorfor vores software kører så meget langsommere, når den kører under virtualisering. Det meste af statistikken, jeg har set, siger, at det kun skal være en 10\% præstations straf i værste fald, men på en Windows virtuelle server, ydeevne straf kan er 100-400\%. Jeg har forsøgt at profilere forskellene, men profilresultaterne giver mig ingen mening. Her er hvad jeg ser, når jeg profilerer på min Vista 32-bit boks uden virtualisering:
Indtast billedbeskrivelse her


Og her løber man på en Windows 2008 64-bit server med virtualisering: Indtast billedbeskrivelse her


Den langsomme bruger en meget stor del af sin tid i RtlInitializeExceptionChain, som viser som 0,0s på den hurtige. Enhver ide om hvad det gør? Også når jeg vedlægger processen min maskine, er der kun en enkelt tråd PulseEvent, men når jeg forbinder på serveren, er der to tråde, GetDurationFormatEx og RtlInitializeExceptionChain. Så vidt jeg ved, er koden som vi kun har skrevet i brug en enkelt tråd. Også for hvad det er værd at dette er en konsol kun ansøgning skrevet i ren C uden nogen brugerinterface.


Kan nogen kaste lys over noget af dette for mig? Endnu bare oplysninger om, hvad nogle af disse ntdll og kernel32 opkald gør? Jeg er også usikker på, hvor meget forskellene er 64/32-bit relaterede, og hvor mange er virtuelle/ikke-virtuelle relaterede. Desværre har jeg ikke let adgang til andre konfigurationer for at bestemme forskellen.

Bedste reference


Jeg antager, at vi kunne dele grunde til langsommere præstation på en virtuel maskine i to klasser:


1. Konfiguration Skew



Denne kategori er for alle de ting, der ikke har noget at gøre med virtualisering i sig selv , men hvor den konfigurerede virtuelle maskine ikke er så god som den virkelige. En rigtig let ting at gøre er at give den virtuelle maskine kun én CPU-kerne og sammenligne den derefter med en applikation, der kører på et 2-CPU 8-core 16-hyperthread Intel Core i7-monster. I dit tilfælde har du i det mindste ikke kørt det samme operativsystem. Sandsynligvis er der også andre skævheder.


2. Dårlig virtualisering passer



Ting som databaser, der gør en masse låsning, virtualiserer ikke godt, og den typiske overhead kan ikke finde anvendelse på testet. Det er ikke din præcise sag, men jeg har fået at vide, at straffen er 30-40\% for MySQL. Jeg bemærker et indtastningspunkt kaldet ... semafor i din liste. Det er et tegn på noget, der vil virtualisere langsomt.


Det grundlæggende problem er, at konstruktioner, der ikke kan udføres indbygget i brugermodus, kræver fælder (langsomt, alt for sig selv) og derefter yderligere overhead i hypervisoremuleringskode.

Andre referencer 1


Jeg antager, at du giver tilstrækkelige ressourcer til dine virtuelle maskiner. Fordelen ved virtualisering er at konsolidere 5 maskiner, der kun kører ved 10-15\% CPU/hukommelse på en enkelt maskine, der kører ved 50-75\% CPU/hukommelse og som stadig efterlader dig 25-50\% overhead for de 'bursty' tider.


Personlig anekdote: 20 maskiner blev virtualiseret, men hver bruger så meget CPU som det kunne. Dette forårsagede problemer, da en enkelt maskine forsøgte at bruge mere strøm end en enkelt kerne kunne tilvejebringe. Derfor hypervisor virtualisering en enkelt kerne over flere kerner, dræbe ydeevne. Når vi har spredt CPU-brugen af ​​hver VM til det maksimale, der er tilgængeligt fra en enkelt kerne, skubbes ydeevnen.