La macchina virtuale è più lenta della macchina fisica sottostante?

Questa domanda è piuttosto generale, ma in particolare mi interessa sapere se la macchina virtuale che esegue Ubuntu Enterprise Cloud sarà più lenta della stessa macchina fisica senza virtualizzazione. Quanto (1%, 5%, 10%)?

Qualcuno ha misurato la differenza di prestazioni del server Web o del server db (virtuale VS fisico)?

Se dipende dalla configurazione, immaginiamo due processori quad core, 12 GB di memoria e un sacco di dischi SSD, che eseguono Ubuntu Enterprise Server a 64 bit. Inoltre, solo 1 macchina virtuale ha permesso di utilizzare tutte le risorse disponibili.

L'esperienza tipica di un carico di lavoro del server per scopi generici su un hypervisor bare metal \ Tipo 1 è circa l'1-5% dell'overhead della CPU e il 5-10% dell'overhead della memoria, con un overhead aggiuntivo che varia a seconda del carico IO complessivo. Ciò è sostanzialmente coerente con la mia esperienza con i moderni sistemi operativi guest in esecuzione su VMware ESX \ ESXi, Microsoft Hyper-V e Xen in cui l'hardware sottostante è stato progettato in modo appropriato. Per i sistemi operativi per server a 64 bit in esecuzione su hardware che supporta le estensioni di virtualizzazione dell'hardware della CPU più recenti mi aspetterei che tutti gli hypervisor di tipo 1 si stessero dirigendo verso quel numero ambientale dell'1%. La maturità di KVM non è abbastanza fino a Xen (o VMware) a questo punto, ma non vedo alcun motivo per pensare che sarebbe notevolmente peggiore di loro per l'esempio che descrivi.

Per casi d'uso specifici, sebbene le "prestazioni" complessive \ complessive di un ambiente virtuale possano superare i server bare metal \ discreti. Ecco un esempio di una discussione su come un impianto VMware Clustered può essere più veloce \ migliore \ più economico di un Oracle RAC bare metal. Le tecniche di gestione della memoria di VMware (in particolare la condivisione trasparente delle pagine) possono eliminare l'overhead di memoria quasi interamente se si dispone di un numero sufficiente di VM abbastanza simili. La cosa importante in tutti questi casi è che i vantaggi di prestazioni \ efficienza che la virtualizzazione può offrire saranno realizzati solo se si stanno consolidando più VM su host, il tuo esempio (1 VM sull'host) sarà sempre più lento del bare metal in una certa misura .

Sebbene tutto ciò sia utile, i problemi reali in termini di virtualizzazione dei server tendono ad essere incentrati su gestione, tecniche di alta disponibilità e scalabilità. Un margine di prestazioni della CPU del 2-5% non è importante quanto essere in grado di scalare in modo efficiente a 20, 40 o comunque quante macchine virtuali sono necessarie su ciascun host. Puoi gestire il miglioramento delle prestazioni selezionando una CPU leggermente più veloce come base o aggiungendo più nodi nei cluster, ma se l'host non è in grado di ridimensionare il numero di VM che può eseguire o l'ambiente è difficile da gestire o inaffidabile quindi è inutile dal punto di vista della virtualizzazione del server.

"Performance" ha molti aspetti. Gli n00bs misurano il tempo di avvio di un sistema operativo e dicono ad esempio che Windows 2012 è davvero fantastico perché si avvia in 12 secondi su HD reale, forse 1 secondo su SSD.
Ma questo tipo di misura non è molto utile: le prestazioni sono uguali al tempo di avvio del sistema operativo, ma il sistema operativo si avvia una volta al mese in modo da ottimizzare che non ha molto senso.

Perché è la mia attività quotidiana, potrei sottolineare le 4 parti seguenti che compongono la "performance"

1. Carico della CPU
   Questo dovrebbe essere comparabile, nel senso che un'attività che richiede 1000 ms su bare metal verrà eseguita in 1000 ms di tempo di processo e probabilmente 1050 ms di tempo di clock in un ambiente VM inattivo sullo stesso hardware (alcuni dettagli in seguito). Google MSDN per processtime e queryperformancecounter e tu puoi fare qualcosa che può mostrare quanto la VM consuma il tuo tempo CPU.

2. Prestazioni SQL
   Le prestazioni SQL dipendono fortemente da IO per l'archivio dati in cui sono archiviati i dati SQL. Ho visto una differenza del 300% tra ISCSI di prima generazione che potresti trovare sul NAS di Buffalo, quindi ISCSI con DCE e un vero ambiente FC di vecchia scuola, a tutti i livelli. Oggi l'FC vince ancora, perché la latenza dell'FC è l'archiviazione lowesst che porta a una "copia" del protocollo FC per i miglioramenti del data center TCP / IP. Qui IOps e latenza sono fondamentali ma anche larghezza di banda IO dal processo del server ai media - dipende se l'app tende a No-SQL o al datawarehousing o è nel mezzo come sistemi ERP ... Sage KHK per le piccole imprese, SAP per quelli enormi.

3. Accesso al filesystem
   Alcune applicazioni, come lo streaming video, si basano su una larghezza di banda minima garantita, altre si affidano alla massima velocità di trasmissione IO, come ad esempio l'apertura di file di grandi dimensioni in un editor esadecimale, il caricamento di un progetto video nel tuo film preferito che crea prog. Non è una situazione tipica su un vm .... gli IOps possono anche essere importanti per gli sviluppatori. Gli sviluppatori fanno spesso uso di macchine virtuali perché gli ambienti di sviluppo sono molto sensibili e quindi la tentazione di farlo in una macchina virtuale è alta. Compilare un grande progetto spesso significa leggere tonnellate di piccoli file, fare le cose del compilatore e costruire un EXE e i componenti che lo accompagnano.

4. Latenza di rete verso il client
   Qui l'usabilità dei prog WYSIWIG come word 2010, Openoffice Writer, LaTEX, GSView e altri si basa molto sulla velocità: la velocità con cui un'azione del mouse arriva dal client al server. Soprattutto nelle app CAD questo è importante .... ma non è un problema LAN, è l'accesso remoto su WAN dove questo è importante.

Ma - e parlo dal punto di vista di anni di consulenza - ci sono utenti che hanno la password dell'amministratore (e spesso sono dipendenti di una GRANDE azienda con un GRANDE budget e un GRANDE portafoglio) che lamentano questo e quello, ma deve essere chiarito quale componente delle prestazioni è importante per loro e quale è importante dal punto di vista dell'applicazione che utilizzano.
Molto probabilmente non è un blocco note, ma un'applicazione altamente sofisticata per progettare questo e quello, che era anche molto costoso e dovrebbe essere spostato su VMware, HyperV o Xenapp e non funziona come previsto.

Ma non hanno in mente che potrebbe funzionare su Xeon da 1,5 GHz su blade non realizzati per prestazioni CPU pure, sono costruiti in media, diciamo "ottimizzati per $ per ciclo CPU" o "cicli CPU per Watt" .

E quando parliamo di compromessi ed economizzazioni, ciò porta principalmente a sovraccarichi. I sovraccarichi portano alla mancanza di risorse in cui la CPU può essere gestita abbastanza bene, ma la mancanza di memoria porta al paging, la mancanza di I / O nei router core porta ad un aumento dei tempi di risposta su tutto e il sovraccarico transazionale su qualsiasi tipo di archiviazione potrebbe arrestare ogni app utile di rispondere troppo velocemente. Qui è richiesto il monitoraggio, ma molti fornitori di software non sono in grado di fornire tali informazioni .... d'altra parte un host con risorse di 3 server fisici può molto probabilmente gestire 8 macchine virtuali dello stesso layout come quelle fisiche ...

I compromessi della CPU sui sistemi inattivi spesso portano a sistemi con prestazioni del 50% più lente rispetto ai sistemi fisici, d'altra parte nessuno è in grado di installare il sistema operativo "reale" e l'app "mondo reale" che i ragazzi IT del cliente vogliono spostare nella VM scatola. E ci vogliono giorni (forse settimane ma sicuramente 42 riunioni) per chiarire che la tecnologia VM può offrire flessibilità scambiando la pura velocità della CPU. Questo è appena integrato nelle CPU di questi sistemi blade che ospitano oggigiorno ambienti VM più grandi. Inoltre la memoria non sarà comparabile, si applicano anche alcuni compromessi. DDR3 1600 CL10 avrà una larghezza di banda di memoria maggiore rispetto a DDR2 800 ECC LLR - e tutti sanno che le CPU Intel ne traggono vantaggio in un modo diverso rispetto a cpus AMD. Ma sono usati raramente in ambienti produttivi, più nei whitebox o nei data center ospitati in paesi del terzo mondo che offrono un servizio di datacenter al 10% del prezzo che un datacenter nella propria patria può fatturare. Grazie a Citrx un datacenter può essere ovunque se è inferiore a 150 ms di latenza tra l'utente finale e il datacenter.

E la prospettiva degli utenti domestici ....

Ultimo ma non meno importante, alcune persone vogliono buttare via Win7 o XP e scambiarlo con un Linux, e poi sorge la domanda di gioco perché in realtà sono disponibili solo pochi giochi per Linux e Windows. Il gioco si basa fortemente sull'accelerazione 3D. VMWare 6.5 Workstation e il lettore gratuito connesso possono gestire DirectX 9, il che significa che un Doom3 in una VM può essere eseguito sulla scheda grafica host a schermo intero. I giochi sono principalmente app a 32 bit, quindi non consumano più di 3 GB e per lo più non più di 3 CPU (visto su Crysis). I lettori VM e WS più recenti sono in grado di gestire versioni DirectX superiori e probabilmente anche OpenGL ... Ho utilizzato UT e UT2004 su VMware 6.5, l'host aveva un ATI Radeon 2600 mobile e una CPU T5440. Era stabile a 1280x800 e giocabile anche su giochi di rete ....

Sì. Ma questa non è la domanda. La differenza è normalmente trascurabile (dall'1% al 5%).

Vorrei sottolineare che la virtualizzazione può superare le prestazioni fisiche in determinate situazioni. Poiché il livello di rete non si limita alla velocità di gigabit (anche se l'emulazione hardware è di una scheda LAN specifica), le VM sullo stesso server possono comunicare tra loro a velocità superiori a quella di più server phiscisc con un'apparecchiatura di rete media.

Ho effettuato alcuni confronti di test dello stesso software eseguendo lo stesso test (applicazione Web basata su .NET con elevati volumi di traffico Web e notevole accesso a SQL Server). Ecco cosa ho visto:

• La macchina fisica è migliore nell'istanza delle classi (che si traduce nell'allocazione della memoria a livello di sistema) - questo ha senso per me perché le macchine fisiche lo fanno attraverso l'hardware di gestione della memoria e le VM lo fanno attraverso il software (con assistenza hardware parziale) (Sulla VM , l'app ha trascorso una notevole quantità di tempo nei suoi costruttori (dove viene allocata la memoria (e nient'altro è fatto), sulla macchina fisica, i costruttori non erano nemmeno inclusi nella top 1000)
• Quando sei nel mezzo di un metodo, i due sono quasi equivalenti - questo è probabilmente il modo in cui sono costruiti la maggior parte dei benchmark che mostrano che i due "sono gli stessi"
• Quando si accede a un controller di rete, il fisico batte leggermente la VM - ancora una volta, il fisico non si trova molto tra il processo .NET e l'hardware. VM aggiunge altre "cose" che ogni transazione deve attraversare.
• In realtà, la stessa cosa si applicava all'accesso al disco (SQL Server era su un altro computer) - la differenza è molto piccola, ma quando li sommi tutti, è evidente. Ciò potrebbe essere stato causato dall'accesso più lento alla rete o da un accesso più lento al disco.

Posso facilmente vedere come qualcuno potrebbe costruire benchmark che dimostrano che sono diversi dell'1% o uguali o dove le macchine virtuali sono più veloci. Non includere nulla in cui il processo sfrutta i vantaggi del supporto hardware locale in cui la VM deve simularlo nel software.

Stai cercando di confrontare un sistema operativo, software e dati installati su un determinato hardware fisico con lo stesso sistema operativo, software e dati installati da solo all'interno di un hypervisor sullo stesso hardware originale. Questo confronto non è solo valido, perché quasi nessuno lo fa (almeno all'inizio). Naturalmente sarebbe probabilmente più lento. Per fortuna, manca completamente il punto più comune del perché virtualizzi i server.

Un esempio migliore qui è quello di esaminare due (o più!) Server più vecchi nel tuo data center. Cerca i server che stanno funzionando abbastanza bene, ma ora sono vecchi e stanno arrivando nel loro ciclo di aggiornamento. Questi server funzionano già bene su hardware più vecchio, e quindi grazie alla legge di Moore qualsiasi cosa tu ottenga sarà troppo esagerata.

Allora cosa fai? È semplice. Invece di acquistare due nuovi server, ne acquisti solo uno, quindi esegui la migrazione di entrambi i tuoi vecchi server sullo stesso nuovo dispositivo fisico. Quando ti prepari ad acquistare il tuo nuovo server, pianifichi di avere una capacità sufficiente non solo per gestire il carico da entrambi i server più vecchi, ma anche qualsiasi carico dall'hypervisor (e forse un piccolo extra, in modo da poter ancora ottenere un aumento delle prestazioni e può consentire la crescita).

In sintesi: le macchine virtuali forniscono prestazioni "abbastanza buone" per la maggior parte delle situazioni e consentono di utilizzare meglio i server per evitare "sprechi" di potenza di elaborazione.

Ora allunghiamo un po 'di più. Dal momento che questi sono vecchi server, forse stavi guardando un paio di semplici server per scatole da $ 1500 per sostituirli. Probabilmente, anche una di queste scatole per pizza potrebbe ancora gestire facilmente il carico da entrambe le ipotetiche macchine precedenti ... ma supponiamo che tu decida di spendere $ 7500 o più su qualche hardware reale. Ora hai un dispositivo in grado di gestire facilmente fino a una dozzina di server esistenti (a seconda di come gestisci l'archiviazione e la rete), con un costo iniziale di soli 5. Hai anche i vantaggi di gestire un solo server fisico, disaccoppiando il tuo software dal tuo hardware (ovvero: l'aggiornamento dell'hardware ora ha meno probabilità di aver bisogno di una nuova licenza di Windows o di causare tempi di inattività), risparmi un sacco di energia e il tuo hypervisor può darti informazioni sulle prestazioni migliori di te " ho avuto in passato. Prendi due di questi e, a seconda di quanto sei grande, forse il tuo intero data center è limitato a solo due macchine, o forse vuoi usare il secondo server come hot standby per raccontare una storia ad alta disponibilità.

Il mio punto qui è che non si tratta solo di prestazioni. Non prenderei mai un server di produzione perfettamente valido e lo virtualizzerei da solo con un hardware equivalente solo perché. Si tratta più di risparmio sui costi e altri vantaggi che puoi ottenere dal consolidamento, come l'alta disponibilità. Realizzare questi vantaggi significa che stai spostando i server su hardware diverso e che a sua volta significa che devi prendere il tempo per dimensionare quell'hardware in modo appropriato, inclusa la contabilizzazione della penalità dell'hypervisor. Sì, potresti aver bisogno di un po 'più di potenza di calcolo in totale rispetto a ciascuna di quelle macchine sul proprio dispositivo fisico (suggerimento: probabilmente in realtà avrai bisogno di molta meno potenza di calcolo totale ), ma sarà molto più economico, più efficiente dal punto di vista energetico, e più facile da mantenere eseguire un server fisico piuttosto che eseguirne molti.

Ho appena effettuato l'aggiornamento a un SSD (OCZ Vertex 2) e su di esso eseguo il mio ambiente di sviluppo VM XP, sono uno sviluppatore di software. Una cosa che ho notato è che quando lancio un programma (uno abbastanza grande da impiegare del tempo a caricarsi), esce un nucleo della CPU virtuale. Questo succede anche quando si carica IE. Dato che la CPU si spegne, presumo che il collo di bottiglia sia la CPU e non l'SSD. Ma sembra strano, ho la sensazione che se la stessa cosa fosse fatta su una macchina fisica si caricerebbe più velocemente e la mia sensazione è che ci sia un po 'di elaborazione extra che VMWare sta facendo che sta consumando CPU sull'accesso al disco.

Un esempio, utilizzo Delphi e su una macchina fisica con un normale HDD possono essere necessari 20 secondi per iniziare da un avvio a freddo. Nella VM che esegue un SSD, si carica in 19 secondi da un avvio a freddo. Non molta differenza, scommetto che se l'SSD fosse sulla macchina fisica si caricherà più velocemente. Tuttavia, non ho verificato l'utilizzo della CPU sulla macchina fisica, è possibile che anche la CPU fosse il collo di bottiglia.

Ma la sensazione della VM è che l'accesso al disco tassa la VM.

Ovviamente una macchina virtuale è più lenta della macchina fisica. Ma quando ti trovi in ​​questo scenario devi valutare ciò che è ottimale per soddisfare le tue esigenze. Se hai bisogno di un solo sistema e hai bisogno che sia veloce, installalo direttamente sull'hardware. Dall'altro lato, se hai bisogno di flessibilità, scalabilità (e tutti gli altri vantaggi della virtualizzazione: P), distribuisci una VM. Sarà più lento, ma IMHO in alcuni casi è giustificato e le prestazioni non sono significativamente lente.

Sembra che Microsoft abbia effettuato alcuni test di benchmark utilizzando il server BizTalk e SQL Server in diverse configurazioni al riguardo. Vedi link sotto:

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

Idealmente, le prestazioni di Virtual PC sono:

CPU: 96-97% dell'host

Rete: 70-90% di host

Disco: 40-70% dell'host

Mi dispiace non essere d'accordo con TomTom.

Ho usato VMware Workstation per un po 'principalmente su Windows XP, Windows Vista e ora i sistemi nativi di Windows Seven per eseguire diversi gusti di Windows e Ubuntu.

Sì, un ambiente virtualizzato è più lento di un sistema nativo e può essere compreso tra 5 e 100%.

Il problema principale non è tanto il carico della CPU ma la mancanza di memoria fisica.

Diciamo che hai un Windows Seven 64 Ultimate in esecuzione su un sistema da 4 Gb che quando inattivo ha bisogno di quasi 1,5 Gb e utilizza circa il 10% della CPU. Il lancio del livello aggiuntivo di VMware ti costerà ~ 300 Kb e i carichi della CPU saliranno fino a ~ 20%. Quindi l'avvio di un sistema virtuale all'interno di VMware richiederà almeno la quantità di memoria definita per quella macchina virtuale che è almeno 1 Gb per qualsiasi sistema decente. Quindi vedrai la CPU caricare ~ 60% se la macchina virtuale è Ubuntu e ~ 80% per qualsiasi sapore del recente sistema operativo Windows.

A questo punto, avvierai diverse app all'interno di quella macchina virtuale.

Se la quantità di memoria impostata per quella macchina virtuale non è sufficiente, il sistema virtualizzato inizierà a scambiarsi, rallentando notevolmente le prestazioni e la reattività complessive.

Se la somma della quantità di memoria che hai impostato per quella macchina virtuale più la quantità di memoria necessaria per il tuo sistema nativo è superiore alla quantità di memoria del tuo sistema nativo, allora è il tuo sistema nativo che cambierà, rallentando sia il sistema nativo che quello virtualizzato.

Quindi, dipende innanzitutto dal bilanciamento della memoria necessaria sia per le macchine native che per quelle virtualizzate.

Ora è quasi lo stesso con il carico della CPU. Se un'app virtualizzata richiede un carico di CPU enorme e un'app nativa richiede anche un carico di CPU enorme, il tuo sistema nativo dovrà gestire la priorità e bilanciare la carica della CPU tra le sue diverse app, il sistema virtualizzato non è altro che un'app ma Il fenomeno è un classico problema di caricamento della CPU che puoi risolvere con le priorità delle app.

Quindi, il mio primo consiglio se devi usare la virtualizzazione è quello di mettere un sacco di memoria nella tua macchina, qualunque sia il sistema operativo che usi nativamente o all'interno di una macchina virtuale.

Solo i miei 2 centesimi.

I migliori saluti.

Nella mia esperienza, le macchine virtuali sono sempre molto più lente di quelle fisiche FUORI DALLA SCATOLA.

Lo noterai solo quando esegui applicazioni che colpiscono il disco e tassano molto la CPU. Ho eseguito molti database e server Web su macchine virtuali e come utente finale e il feedback di altri utenti finali (ad esempio: accesso all'app da un browser Web remoto) c'è un notevole ritardo nell'uso delle macchine virtuali.

Naturalmente una macchina virtuale correttamente configurata può arrivare all'80% (non conosco il numero reale) o qualunque sia la velocità della macchina fisica, ma si finisce per scavare davvero in profondità ciò che l'applicazione sta facendo e come la macchina virtuale lavori. Quindi immagino che sia un'equazione di costo di quanto sia prezioso il tuo tempo per configurare i versi di VM semplicemente acquistando e ospitando un nuovo server.

Per me le macchine virtuali NON SONO INFORMAZIONI SULLE PRESTAZIONI, ma sull'essere più facili da gestire e ovviamente per ospitare diverse macchine virtuali a basse prestazioni.