Vraag Is de virtuele machine langzamer dan de onderliggende fysieke machine?


Deze vraag is vrij algemeen, maar vooral wil ik weten of de virtuele machine waarop Ubuntu Enterprise Cloud wordt uitgevoerd, langzamer is dan dezelfde fysieke machine zonder enige virtualisatie. Hoeveel (1%, 5%, 10%)?

Heeft iemand het prestatieverschil van de webserver of db-server (virtueel VS fysiek) gemeten?

Als het van de configuratie afhangt, stellen we ons twee quad core-processors, 12 GB geheugen en een heleboel SSD-schijven voor, met een 64-bits ubuntu enterprise-server. Daar bovenop kon slechts 1 virtuele machine alle beschikbare bronnen gebruiken.


45
2018-04-24 07:18


oorsprong


Ubuntu Entreprise Cloud is gebaseerd op KVM niet Xen. - Antoine Benkemoun
Antoine, je hebt gelijk - "De kernvisualisatiestrategie is altijd gebaseerd geweest op KVM, hoewel met de ontwikkeling van lib-virt, het management van KVM- en Xen-hosts is verenigd." - Ik zal de vermelding over Xen aanpassen. - Michal Illich


antwoorden:


De typische ervaring voor een serverload voor algemene doeleinden op een bare metal \ Type 1 Hypervisor is ongeveer 1-5% van de CPU-overhead en 5-10% geheugenoverhead, met wat extra overheadkosten die variëren afhankelijk van de totale IO-belasting. Dat is redelijk consistent in mijn ervaring met moderne Guest OS's die draaien onder VMware ESX \ ESXi, Microsoft Hyper-V en Xen, waar de onderliggende hardware op de juiste manier is ontworpen. Voor 64-bits Server-besturingssystemen die worden uitgevoerd op hardware die de meest recente cpu-hardware-virtualisatie-uitbreidingen ondersteunt, zou ik verwachten dat alle Type 1-hypervisors naar dat 1% overheadnummer gaan. De volwassenheid van KVM is op dit moment nog niet volledig aan Xen (of VMware), maar ik zie geen reden om te denken dat het merkbaar erger zou zijn dan het voorbeeld dat u beschrijft.

Voor specifieke use-cases kan de algehele \ aggregate "performance" van een virtuele omgeving blankere \ discrete servers overschrijden. Hier is een voorbeeld van een discussie over hoe een VMware-geclusterde implementatie sneller \ beter \ goedkoper kan zijn dan een bare metal Oracle RAC. VMware's geheugenbeheertechnieken (vooral transparant delen van pagina's) kunnen de geheugenoverhead bijna volledig elimineren als je genoeg VM's hebt die vergelijkbaar genoeg zijn. Het belangrijkste in al deze gevallen is dat de prestaties \ efficiëntie-voordelen die virtualisatie kan opleveren alleen zullen worden gerealiseerd als u meerdere VM's op hosts consolideert, uw voorbeeld (1 VM op de host) zal in bepaalde mate altijd langzamer zijn dan bare metal .

Hoewel dit allemaal nuttig is, hebben de echte problemen in termen van servervirtualisatie de neiging zich te concentreren op beheer, hoge beschikbaarheidstechnieken en schaalbaarheid. Een 2-5% CPU-prestatiemarge is niet zo belangrijk als het efficiënt kunnen schalen naar 20, 40 of zoveel VM's die u nodig hebt op elke host. Je kunt omgaan met de prestatiehit door een iets snellere CPU als je basislijn te selecteren, of door meer knooppunten in je clusters toe te voegen, maar als de host het aantal VM's dat het kan uitvoeren niet kan opschalen, of de omgeving moeilijk te beheren of onbetrouwbaar, dan is het waardeloos vanuit een oogpunt van servervirtualisatie.


28
2018-04-24 15:03



U gebruikt verouderde technologie - met name de 5% tot 10% geheugenoverhead is oude hardware. De nieuwere hardware-chips hebben een overhead van ongeveer 2% tot 3% als de hyper-vizier dit ondersteunt - en we praten over dingen die een jaar oud zijn en nieuw zijn. AMD en Intel hebben toen hun API voor Hyper-Visor-geheugenkaarten verbeterd. Zoals je later zei, sloegen ze behoorlijk transparant (doel van 1%). +1 voor het wijzen op de echte voordelen. - TomTom
Ik heb de 5-10% gebaseerd op wat ik heb gezien met VMware en het is gebaseerd op pre EPT \ RVI-kit. Het is logisch dat het verbeterde op hardware gebaseerde virtuele geheugenbeheer in de meest recente CPU's de hoeveelheid RAM-geheugen zou verminderen - Helvick
betreffende het transparante delen van pagina's, het is stom als je grote geheugenpagina's hebt die alle nieuwe cpu's ondersteunen. In dit geval krijg je eigenlijk niets. - tony roth
@Tony dat is alleen waar als je niet overcommitteerd bent - als je dan ESX \ ESXi 4 zal kiezen om kleine pagina's te gebruiken, en TPS zal beginnen. Ik heb dit niet tot het uiterste geduwd, dus ik kan niet bevestigen dat het echt werkt zoals geadverteerd, maar het is een verstandige aanpak die overcommitment moet toestaan ​​wanneer dit absoluut noodzakelijk is zonder dat dit ten koste gaat van de prestaties. Zien kb.vmware.com/selfservice/microsites/... - Helvick
@Helvick, als je win7 of w2k8r2 uitvoert, werkt TPS niet zo goed, omdat de gast dingen agressief aanpakt. - tony roth


"Prestaties" heeft veel aspecten. De n00bs meten de opstarttijd van een besturingssysteem en zeggen b.v. Windows 2012 is zooooo geweldig omdat het in 12 seconden opstart op echte HD, misschien 1 sec op SSD.
Maar dit soort metingen is niet erg handig: de prestaties zijn gelijk aan de opstarttijd van het besturingssysteem, maar het besturingssysteem wordt één keer per maand opgestart, dus het optimaliseren is niet logisch.

Omdat het mijn dagelijkse bezigheid is, zou ik kunnen wijzen op de 4 volgende delen waaruit de "prestatie" bestond

  1. CPU-belasting
    Dit moet vergelijkbaar zijn, wat betekent dat een taak van 1000 ms op bare metal wordt uitgevoerd in een proces van 1000 ms en waarschijnlijk 1050 ms van de kloktijd in een niet-actieve VM-omgeving op dezelfde hardware (later enkele details). Google de MSDN voor processtime en queryperformancecounter en yu kan iets doen dat kan laten zien hoeveel de VM jouw CPU-tijd opgebruikt.

  2. SQL-prestaties
    SQL-prestaties zijn in hoge mate afhankelijk van IO in de datastore waar de SQL-gegevens worden opgeslagen. Ik heb 300% verschil gezien tussen 1'st gen ISCSI die je misschien aantreft op Buffalo thuis NAS, dan ISCSI met DCE en een echte old school FC-omgeving, op alle niveaus. De FC wint nog steeds, omdat de FC-wachttijd de laagste is die kan worden bereikt en die leidt tot een "kopie" van het FC-protocol voor verbeteringen van het TCP / IP-datacenter. Hier is IOps en latency van vitaal belang, maar ook IO-bandbreedte van het serverproces naar de media - hangt ervan af of de app neigt naar No-SQL of naar Datawarehousing of zit midden in die zoals ERP-sytemen ... Sage KHK voor kleine ondernemingen, SAP voor de gigantische. Beide hebben een CEO-visie op financiële bedrijfsstatistieken en wanneer de CEO op de knop drukt verleent hij effectief vakanties voor enkele dagen wanneer het IO-subsysteem van de database tekortkomingen vertoont.

  3. Bestandsysteemtoegang
    Sommige applicaties, zoals videostreaming, vertrouwen op een gegarandeerde minimale bandbreedte, andere zijn afhankelijk van maximale IO-doorvoer, zoals het openen van grote bestanden in een hex-editor, het laden van een videoproject in uw favoriete film maken van prog. Geen typische situatie op een vm ... de IOps kunnen ook belangrijk zijn voor ontwikkelaars. Ontwikkelaars maken vaak gebruik van VM's omdat ontwikkelomgevingen zeer gevoelig zijn en dus is de verleiding om dat in een VM te doen hoog. Het compileren van een groot project betekent vaak het lezen van tonnen kleine bestanden, het compiler-spul doen en een EXE en de bijbehorende componenten bouwen.

  4. Netwerklatentie voor de client
    Hier is de bruikbaarheid van WYSIWIG-progs zoals Word 2010, Openoffice Writer, LaTEX, GSView en anderen sterk afhankelijk van de snelheid - hoe snel een muisactie van de client naar de server gaat. Vooral in CAD-apps is dit belangrijk ... maar ook geen LAN-probleem, het is remote access over WAN waar dit belangrijk is.

Maar - en ik spreek vanuit het perspectief van jarenlange consultancy - er zijn gebruikers die het admin-wachtwoord hebben (en ze zijn vaak werknemers van een GROOT bedrijf met een GROOT budget en een GROOT pocketboek) die dit en dat klagen, maar het moet worden verduidelijkt welke prestatiecomponent voor hen belangrijk is en die belangrijk is vanuit het perspectief van de applicatie die zij gebruiken.
Het is hoogstwaarschijnlijk geen kladblok, maar een zeer geavanceerde applicatie voor het engineeren van dit en dat, dat ook erg duur was en moet worden verplaatst naar VMware, HyperV of Xenapp en het werkt niet zoals verwacht.

Maar ze denken er niet aan dat het op 1,5 GHz-Xeons kan werken op blades die niet zijn gemaakt voor pure CPU-prestaties, ze zijn gebouwd voor een gemiddelde, laten we zeggen "geoptimaliseerd voor $ per CPU-cyclus" of "CPU-cycli per Watt" .

En als we het hebben over afwegingen en economiseringen - dat leidt meestal tot overcommitments. Overcommitments leiden tot een gebrek aan bronnen waar de CPU redelijk goed kan worden afgehandeld, maar gebrek aan geheugen leidt tot paging, gebrek aan IO in de core routers leidt tot langere responstijden en transactionele overbelasting op elke vorm van opslag kan elke nuttige app stoppen reageren te snel. Hier is monitoring vereist, maar veel softwareleveranciers zijn niet in staat om dergelijke informatie te verstrekken .... aan de andere kant kan een host met bronnen van 3 fysieke servers waarschijnlijk 8 virtuele machines van dezelfde lay-out verwerken als de fysieke ...

De CPU-afwegingen bij inactieve systemen leiden vaak tot systemen die 50% langzamer presteren dan fysieke systemen, aan de andere kant kan niemand de "echte wereld" os en de "echte wereld" app installeren die de IT-jongens van de klant willen verplaatsen naar de VM doos. En het duurt dagen (misschien weken maar zeker 42 vergaderingen) om duidelijk te maken dat VM-technologie flexibiliteit kan bieden door pure CPU-snelheid te verhandelen. Dit is net ingebouwd in de CPU's op deze bladesystemen die tegenwoordig gebruikmaken van grotere VM-omgevingen. Ook zal het geheugen niet vergelijkbaar zijn, ook zijn enkele compromissen van toepassing. DDR3 1600 CL10 heeft een hogere geheugenbandbreedte dan DDR2 800 ECC LLR - en iedereen weet dat Intel CPU's hier op een andere manier van profiteren dan AMD cpus. Maar ze worden zelden gebruikt in productieve omgevingen, meer in whiteboxes of in datacenters gehost in derde wereldlanden die datacenter-service bieden voor 10% van de prijs die een datacenter in uw eigen thuisland u mag in rekening brengen. Dankzij Citrx kan een datacenter overal zijn als het minder dan 150 ms vertraging heeft tussen de eindgebruiker en het datacenter.

En het perspectief van de thuisgebruikers .... 

Last but not least willen sommige mensen Win7 of XP weggooien en inruilen voor een Linux, en dan komt de spelvraag aan de orde, omdat er eigenlijk maar weinig spellen beschikbaar zijn voor Linux en Windows. Gaming vertrouwt sterk op 3D-versnelling. VMWare 6.5 Workstation en de aangesloten gratis speler kunnen DirectX 9 gebruiken, wat betekent dat een Doom3 in een VM op een volledige grafische kaart op de host-grafische kaart kan worden uitgevoerd. Spellen zijn meestal 32-bits apps, dus ze zullen niet meer dan 3 GB opeten en meestal niet meer dan 3 CPU's (gezien op Crysis). Nieuwere VM-spelers en WS kunnen overweg met hogere DirectX-versies en waarschijnlijk ook met OpenGL ... Ik heb UT en UT2004 gespeeld op VMware 6.5, de host had een ATI Radeon 2600 mobiel en een T5440-CPU. Het was stabiel op 1280x800 en zelfs op netwerkspellen speelbaar ....


22
2017-12-17 21:45



We houden van goede antwoorden op tijdloze vragen. Welkom bij Server Fault! - Michael Hampton♦


Ja. Maar dat is niet de vraag. Het verschil is normaal gesproken te verwaarlozen (1% tot 5%).


9
2018-04-24 07:25



Ik geloof je. Maar toch: kunt u een benchmark koppelen waar iemand deze daadwerkelijk heeft gemeten? - Michal Illich
Het hangt van zoveel factoren af ​​dat niemand jouw vraag kan beantwoorden. Het hangt af van welke hypervisor je hebt, de serverspecificatie, opslag en vooral wat er nog meer aan de hand is met de host op het moment in kwestie. - Chopper3
Eigenlijk niet. Als je veel dingen doet, wordt de fysieke machine gedeeld. Maar de overhead van de hyper-vizier is behoorlijk constant, gezien hardware-virtualisatie. Als u begint met het laden van meerdere VM's, wordt het resulterende beschikbare powe gedeeld, maar het is - in totaal - nog steeds slechts iets minder dan wat de server heeft. - TomTom
Citaat nodig. - Zoredache
de overhead van de hypervisor hangt af van hoeveel het OS kan worden verlicht en dit betekent niet dat het wordt geprogavirtualiseerd. - tony roth


Ik wijs erop dat virtualisatie in bepaalde situaties de fysieke prestaties kan overstijgen. Omdat de netwerklaag niet beperkt is tot gigabit-snelheid (hoewel de hardware-emulatie van een specifieke LAN-kaart is), kunnen VM's op dezelfde server onderling communiceren met snelheden die groter zijn dan die van meerdere phyiscal-servers met gemiddelde netwerkapparatuur.


8
2017-08-28 12:00



Twee stukjes software die worden uitgevoerd op twee VM's op dezelfde server zullen niet sneller communiceren dan twee software onder hetzelfde besturingssysteem op één bare metal-server. - bokan


U probeert een besturingssysteem, software en gegevens die op een bepaalde fysieke hardware zijn geïnstalleerd, te vergelijken met hetzelfde besturingssysteem, dezelfde software en dezelfde gegevens die u zelf hebt geïnstalleerd in een hypervisor op dezelfde originele hardware. Deze vergelijking is gewoon niet geldig, omdat bijna niemand dit doet. Natuurlijk is dat waarschijnlijk langzamer. Gelukkig mist het volledig het meest voorkomende punt waarom je servers virtualiseert.

Een beter voorbeeld is hier om naar twee (of meer!) Oudere servers in uw datacenter te kijken. Zoek naar servers die redelijk goed presteren, maar die nu oud zijn en hun verversingscyclus hebben bereikt. Deze servers presteren al goed op oudere hardware, dus dankzij de wet van Moore wordt alles wat je krijgt veelzeggend.

Dus wat doe je? Het is makkelijk. In plaats van twee nieuwe servers te kopen, koopt u er slechts één en migreert u vervolgens beide oude servers naar hetzelfde fysieke nieuwe apparaat. Wanneer u zich voorbereidt om uw nieuwe server aan te schaffen, plant u zodat u voldoende capaciteit hebt om niet alleen de belasting van beide oudere servers, maar ook elke belasting van de hypervisor af te handelen (en misschien een beetje extra, zodat u nog steeds een prestatieverbetering krijgt en kan groei mogelijk maken).

Samenvattend: virtuele machines bieden "goed genoeg" prestaties voor de meeste situaties en helpen u om uw servers beter te gebruiken om "verspilde" rekenkracht te vermijden.

Laten we dit een beetje verder uitrekken. Omdat dit oude servers zijn, keek je misschien naar een paar eenvoudige pinautomaatservers van $ 1500 om ze te vervangen. De kans is groot dat zelfs een van deze pizzadozen de belasting van beide hypothetische oudere machines nog steeds gemakkelijk aankan ... maar laten we zeggen dat u in plaats daarvan $ 7500 of meer aan echte hardware besteedt. Nu hebt u een apparaat dat maar liefst tien van uw bestaande servers kan verwerken (afhankelijk van hoe u met opslag en netwerken werkt), met een initiële kost van slechts 5. U profiteert ook van het beheer van slechts één fysieke server, ontkoppeling uw software van uw hardware (dwz: het vernieuwen van de hardware heeft nu waarschijnlijk minder behoefte aan een nieuwe Windows-licentie of het veroorzaken van downtime), u bespaart veel stroom en uw hypervisor kan u betere informatie geven over de prestaties dan u in het verleden had . Ontvang er twee en afhankelijk van hoe groot je bent, is misschien je hele datacenter beperkt tot slechts twee machines, of misschien wil je de tweede server gebruiken als hot-standby om een ​​beter verhaal met hoge beschikbaarheid te vertellen.

Mijn punt is hier het gaat niet alleen om prestaties.  Ik zou nooit een perfect goede productieserver nemen en deze alleen virtualiseren naar gelijkwaardige hardware, alleen omdat. Het gaat meer om kostenbesparingen en andere voordelen die u kunt halen uit consolidatie, zoals hoge beschikbaarheid. Als u deze voordelen realiseert, betekent dit dat u servers naar andere hardware verplaatst, en dat betekent op zijn beurt dat u de tijd moet nemen om die hardware op de juiste manier in te delen, inclusief het verrekenen van de hypervisor-boete. Ja, u zou in totaal iets meer rekenkracht nodig hebben dan als elk van die machines op hun eigen fysieke apparaat zou zijn (hint: u moet waarschijnlijk waarschijnlijk veel minder totale rekenkracht), maar het wordt een heel veel goedkoper, energiezuiniger en gemakkelijker te onderhouden om één fysieke server uit te voeren dan om er veel van te draaien.


1
2018-02-18 15:02



Het gaat niet altijd om consolidatie en kostenbesparingen. Een hypervisor is een product met veel functies, waarvan vele het potentieel hebben om bedrijfswaarde toe te voegen, onafhankelijk van de redenen die de meeste mensen virtualiseren. Consolidatie en kostenbesparingen kunnen deel uitmaken van die bedrijfswaarde, of misschien niet. Snapshots, live migratie, Storage vMotion en hardware-abstractie kunnen allemaal deel uitmaken van de bedrijfs-IT-strategie. - jgoldschrafe
@jgold Point genomen. U bent zelfs een grote vergeten: hoge beschikbaarheid. In mijn verdediging noemde ik hardware abstration (soort van) in mijn laatste bewerking, en voor iemand die net virtualisatie vanuit de hoek van de oorspronkelijke vraag onderzoekt, denk ik dat consolidatie / kosten echt het grote punt is om over te brengen. - Joel Coel


Ik heb enkele testvergelijkingen gedaan van dezelfde software die dezelfde test uitvoert (op .NET gebaseerde webapplicatie met grote hoeveelheden webverkeer en aanzienlijke SQL Server-toegang). Dit is wat ik heb gezien:

  • De fysieke machine is beter in het instantiëren van klassen (wat zich vertaalt naar het toewijzen van geheugen op systeemniveau) - dit is logisch voor mij omdat fysieke machines dit doen door geheugenbeheerhardware en VM's dit doen door middel van software (met gedeeltelijke hardwarehulp) (On the VM , de app bracht een aanzienlijke hoeveelheid tijd door in zijn constructors (waar het geheugen wordt toegewezen (en niets anders wordt gedaan), op de fysieke machine waren de constructeurs zelfs niet opgenomen in de top 1000)
  • Wanneer je middenin een methode zit, zijn de twee ongeveer gelijkwaardig - dit is waarschijnlijk hoe de meeste benchmarks zijn geconstrueerd die laten zien dat de twee "hetzelfde zijn"
  • Wanneer u een netwerkcontroller opent, verslaat het fysieke systeem de VM een beetje - opnieuw heeft het fysieke niet veel plaats tussen het .NET-proces en de hardware. VM voegt andere "dingen" toe waar elke transactie doorheen moet reizen.
  • Echt, hetzelfde gold voor schijftoegang (de SQL Server was op een andere machine) - het verschil is erg klein, maar als je ze allemaal optelt, is het merkbaar. Dit kan veroorzaakt zijn door de langzamere netwerktoegang of door een langzamere schijftoegang.

Ik kan gemakkelijk zien hoe iemand benchmarks kan bouwen die bewijzen dat ze 1% verschillend of gelijk zijn of waar VM's sneller zijn. Voeg niets toe waar uw proces voordeel haalt uit de voordelen van de lokale hardware-ondersteuning waar de VM het in software moet simuleren.


1
2017-08-09 13:27



Dit is waar ik naar op zoek was. 1 - Phil Ricketts


Ik heb zojuist een upgrade naar een SSD (OCZ Vertex 2) uitgevoerd en ik voer mijn XP VM-ontwikkelomgeving erop uit, ik ben een softwareontwikkelaar. Een ding dat ik gemerkt heb is dat wanneer ik een programma start (eentje groot genoeg om de tijd te nemen om te laden), één kern van de virtuele CPU eruit pint. Dit gebeurt ook bij het laden van IE. Omdat de CPU vastzit, neem ik aan dat het knelpunt de CPU is en niet de SSD. Maar het lijkt vreemd, ik heb het gevoel dat als hetzelfde zou worden gedaan op een fysieke machine dat het sneller zou laden en mijn gevoel is dat er wat extra verwerkingsoverhead is die VMWare aan het doen is die CPU verbruikt op schijftoegang.

Een voorbeeld, ik gebruik Delphi en op een fysieke machine met een normale HDD kan het 20 seconden duren om te starten bij een koude start. In de VM die op een SSD loopt, wordt deze in 19 seconden na een koude start geladen. Niet veel verschil, ik wed dat als de SSD zich op de fysieke machine bevond, deze sneller zou laden. Hoe ik het CPU-gebruik op de fysieke machine niet heb gecontroleerd, het is mogelijk dat de CPU daar ook de bottleneck was.

Maar het gevoel van de VM is dat schijftoegang de VM belast.


0
2017-07-19 19:27





Het is duidelijk dat een virtuele machine langzamer is dan de fysieke machine. Maar wanneer u zich in dit scenario bevindt, moet u evalueren wat optimaal is om aan uw behoeften te voldoen. Als u slechts één systeem nodig heeft en snel nodig hebt, installeer het dan direct op de hardware. Aan de andere kant, als je flexibiliteit nodig hebt, schaalbaarheid (en alle andere virtualisatie voordelen: P) implementeer een VM. Het zal langzamer zijn, maar IMHO is in sommige gevallen gerechtvaardigd en de prestaties zijn niet significant traag.


0
2018-02-18 13:39





Het lijkt erop dat Microsoft wat benchmarktests heeft gedaan met behulp van BizTalk-server en SQL Server in verschillende configuraties in dit opzicht. Zie onderstaande link:

http://msdn.microsoft.com/en-us/library/cc768537(v=BTS.10).aspx


0
2017-07-06 14:05



Vermeld de conclusies in uw antwoorden of dit is weinig meer dan SPAM voor de verstrekte link. Dank je. - Chris S
SQL Server presteert Virtueel naar fysiek ratio (met BizTalk: verwerkte berichten / documenten / Sec-statistieken die redelijk redelijk realistisch lijken) wordt als 88% genoteerd - met HyperV. Ziet er niet goed uit. - deadbeef
Oh mijn god, is dat een 250 MB PDF-bestand? O_O - David Balažic


Idealiter zijn de prestaties van virtuele pc's:

PROCESSOR: 96-97% van de host

Netwerk: 70-90% van de host

Schijf: 40-70% van de host


-1
2017-12-22 05:00



En die nummers komen uit .... - Jim B


Sorry dat ik het niet eens ben met TomTom.

Ik gebruik VMware Workstation al een tijdje voornamelijk op Windows XP, Windows Vista en nu Windows Seven-systemen om verschillende Windows-smaken en Ubuntu te gebruiken.

Ja, een gevirtualiseerde omgeving is langzamer dan een native systeem en dat kan in een bereik van 5 tot 100% liggen.

Het grootste probleem is niet zozeer de CPU-belasting, maar het fysieke geheugen ontbreekt.

Laten we zeggen dat je een Windows Seven 64 Ultimate draait op een 4 Gb-systeem dat wanneer hij inactief is bijna 1,5 Gb nodig heeft en ~ 10% van de CPU gebruikt. Het opstarten van de extra laag VMware kost ~ 300 Kb en de CPU-belasting stijgt tot ~ 20%. Vervolgens lanceert een virtueel systeem binnen VMware ten minste de hoeveelheid geheugen die u hebt gedefinieerd voor die virtuele machine en die minimaal 1 Gb is voor elk fatsoenlijk systeem. Dan zie je dat de CPU ~ 60% laadt als de virtuele machine Ubuntu is en ~ 80% voor elke smaak van recent Windows OS.

Nu start u verschillende apps binnen die virtuele machine.

Als de hoeveelheid geheugen die u hebt ingesteld voor die virtuele machine niet voldoende is, begint het gevirtualiseerde systeem te swappen en vertraagt ​​het zijn algehele prestaties en reactievermogen drastisch.

Als de som van de hoeveelheid geheugen die u hebt ingesteld voor die virtuele machine plus de hoeveelheid geheugen die nodig is voor uw systeem, hoger is dan de hoeveelheid geheugen van uw systeem, dan is het uw systeem dat gaat swappen, vertragen zowel het native als gevirtualiseerde systeem.

Het hangt dus eerst af van de balans van het geheugen dat nodig is voor zowel de native als de gevirtualiseerde machines.

Nu is het bijna hetzelfde met de CPU-belasting. Als een gevirtualiseerde app een enorme CPU-belasting nodig heeft en een native app ook een enorme CPU-belasting nodig heeft, moet je native systeem de prioriteit beheren en de CPU-lading in evenwicht brengen tussen de verschillende apps, waarbij het gevirtualiseerde systeem niets anders is dan een app maar dat fenomeen is een klassiek probleem met de CPU-belasting dat u kunt misleiden met app-prioriteiten.

Dus, mijn eerste advies als je virtualisatie moet gebruiken, is om een ​​heleboel geheugen op je machine te zetten, ongeacht het besturingssysteem dat je gebruikt, of in een virtuele machine.

Alleen mijn 2 cent.

Vriendelijke groeten.


-4
2018-04-24 08:03



Stel u deze configuratie voor: 12 GB geheugen, twee quad-core processors. Daar bovenop slechts 1 virtuele machine met 11,5 GB geheugen en alle CPU-kracht. Zal er nog steeds een merkbare vertraging zijn? - Michal Illich
Hoe zou Win7 x64 1,5 GB nodig hebben (of welke cpu-tijd dan ook) wanneer deze niet actief is? Meer dan 384-512 MB in mijn ervaring - de rest is alleen gereserveerd voor I / O-caching en zal indien nodig elders worden vrijgegeven ^^ - Oskar Duveborn
Maar u hebt het over Workstation-virtualisatie en niet een bare-metal-hypervisor die een fractie van de overheadkosten heeft in vergelijking met virtualisatie op Windows. Ubuntu-cloud is misschien niet echt een hypermetallergische hypervisor, maar gebruikt nauwelijks de restitutie van Windows - hij draait op Ubuntu Server die bijvoorbeeld geen GUI heeft. - Jon Rhoades
-1: Zeer slechte vergelijking. VM Workstation is GEEN hypervisor. Ten tweede heb je het over het uitvoeren van hoge belastingen op de host; natuurlijk zal dat een impact hebben op de gast-VM. - gravyface
@ Oskar> Hoe zou Win7 x64 1,5 GB nodig hebben (of welke cpu-tijd dan ook) wanneer deze niet actief is? Meer als 384-512MB in mijn ervaring Bekijk deze foto theliberated7dwarfs.as2.com/pictures/png/W7-Mem.png  Windows 7-64, 4 Gb RAM, nieuwe reboot, geen applicatie-runing maar MSFT Essential Security en Kapersky! Oeps: 1,53 Gb RAM gebruikt en gemiddeld 7% CPU-belasting! @ TomTom & gravyface 1-De eerste vraag ging over generieke VM-machines, niet over hypervisor! 2-My crapy technical platform maakt het geluk van zowel MSFT als VMware. Je vindt het misschien leuk of niet en ik neem het je niet kwalijk;) Met vriendelijke groet - Dopey