perché Virtualbox utilizza il 15-20% di CPU quando la VM è in pausa?


10

Corro VirtualBox 3.1 su Ubuntu con un guest Win XP. Ho notato con mia sorpresa che quando metto in pausa la VM (il suo schermo diventa grigio) VirtualBox continua a utilizzare il 15-20% della CPU dell'host.

Questo comportamento è normale?

C'è un modo per evitarlo? (Senza salvare lo stato della VM e uscire da VirtualBox.)

Grazie per eventuali approfondimenti!

~ lara

Risposte:


8

Al fine di ridurre l'utilizzo della CPU VirtualBox in ogni momento, ricorrere a questo strano hack.

Creare una nuova macchina virtuale e non installarvi un sistema operativo. Di 'a VirtualBox che eseguirà DOS e gli darà le risorse minime assolute. Non installare un O / S. Eseguilo, lascialo fuoriuscire all'avvio e minimizzalo.

Durante l'esecuzione del tuo O / S reale in una seconda macchina virtuale, vedrai che l'utilizzo della CPU Virtualbox inattiva scende al 3-5%.

Idea da jed4czar: http://ubuntuforums.org/showthread.php?s=58e862a814e65eb96f8fe8389b615366&t=838073&page=2

EDIT: per rispondere direttamente alle tue domande

perché Virtualbox utilizza il 15-20% di CPU quando la VM è in pausa?

È un bug. Utilizza sempre il 15-20% di CPU in più rispetto a quando è necessaria una VM, a meno che non venga utilizzato l'hack fornito.

C'è un modo per evitarlo?

Vedi l'hack sopra.


bello sapere che vbox alloca possibili fonti cpu utilizzate all'avvio
Diskilla

ooooh ha risolto anche per me! Fantastico, grazie. Per informazioni, sto eseguendo Windows 8.1, VM è centos e consumava in idle circa il 15% della CPU. VBox v4.3.12
Sebas

Incredibile, questo è ancora un problema.
kmarsh

4

Ho provato l'hack descritto sopra con la VM DOS, ma senza successo (eseguendo guest Ubuntu 12.04 su un MacBook Pro con OS X). Ho anche provato le modifiche ai parametri del kernel menzionate nel thread Oracle , ancora nessuna modifica. Indipendentemente da ciò che facevo, i miei ospiti sembravano consumare il 15-20% di CPU ciascuno. Tuttavia, ho notato che l'unico ospite a cui mi è capitato di assegnare 2 CPU non stava masticando il 15-20%, ma si stava comportando come previsto.

Abbastanza sicuro, quando ho passato gli altri a 2 CPU il problema è scomparso. Dall'esperienza precedente, so che il passaggio a 2 CPU abilita anche l'opzione IO APIC nella sezione della scheda madre, quindi sospettavo che fosse il cambiamento davvero interessante. Cioè, questo:

IOAPIC abilitato

Si noti che è necessario spegnere la macchina per modificare questa impostazione, altrimenti è disattivata. Dopo averlo abilitato sugli ospiti e riavviato, non importava se avessi 1 o più CPU, l'utilizzo della CPU del 15-20% è andato via, quindi ho pensato di condividere la mia soluzione qui.


1

Ho avuto lo stesso problema su un box Quad di Windows 7 con Oracle 5 nella VM.

Seguendo il consiglio di Adam, ho verificato l'opzione Abilitato IO APIC ma senza risultati. Quindi, ho seguito l'idea di kmarsh, che probabilmente ha richiesto meno di un minuto per tentare, e l'utilizzo del processore è passato dal 15-20% al 4-5%.

Le impostazioni utilizzate erano, Nome: Memory Hack, Tipo: Altro, Versione: DOS. Dimensioni memoria: 4 MB, disco rigido: non aggiungere un disco rigido virtuale. Fare clic su [Crea]. Avvio della macchina virtuale richiede un disco di avvio, ho usato: Host Drive 'D:', fare clic su [Avvia]. Stati della macchina virtuale: "FATAL: impossibile leggere dal supporto di avvio! Sistema arrestato." A quel punto, l'utilizzo della cpu è diminuito, quindi ho minimizzato la finestra. L'avvio di una seconda macchina virtuale non fa differenza.


Sembra che questo problema sia così complesso che nessuno lo risolverà.
kmarsh

0

Ho riscontrato questo problema di VirtualBox su una macchina P4 da 2 cpu con ram da 3 GB con host CentOS 5.5.

Non ho riscontrato questo problema su una macchina i720 8cpu con 8 concerti con Win7 a 64 bit. Ho eseguito 3 macchine virtuali VMWare più VirtualBox, tutte con memoria da 2 GB, e non ho avuto alcun problema con la CPU.

Ciò suggerisce che il problema è l'esecuzione su una macchina "piccola" o su un host Linux.

La tua soluzione ha funzionato bene, grazie.

Prendo atto che questi post precedenti risalgono a un anno fa e il mio VirtualBox è la versione 4.0.4 più recente, quindi Oracle non ha ancora risolto questo bug.


2
Mi aspetto che questa riduzione delle prestazioni sia associata al fatto che le CPU più recenti hanno VT-x e simili per consentire la virtualizzazione assistita dall'hardware, il che significherebbe che il programma VirtualBox non sta facendo il lavoro e quindi un utilizzo della CPU inferiore. Un P4 probabilmente non avrebbe la tecnologia VT-x e quindi dovrebbe tradurre le chiamate di sistema via software e utilizzare di conseguenza più CPU.
Mokubai

Questo deve essere stato risolto ormai. usando l'host Ubuntu e il guest XP che esegue VirtualBox v4.3.6 quando metto in pausa il guest, l'utilizzo della CPU scende sotto l'1%
Seeker,

0

Le altre risposte non spiegano o risolvono il bug per me (host Debian, guest Ubuntu in pausa). Oracle ha una sezione per questo:

Alcuni guest Linux possono causare un carico elevato della CPU anche se il sistema guest sembra essere inattivo. Ciò può essere causato da un'alta frequenza del timer del kernel guest. Alcune distribuzioni Linux, ad esempio Fedora, forniscono un kernel Linux configurato per una frequenza del timer di 1000Hz. Si consiglia di ricompilare il kernel guest e selezionare una frequenza del timer di 100Hz.

I kernel Linux forniti con Red Hat Enterprise Linux, così come i kernel delle relative distribuzioni Linux, come CentOS e Oracle Linux, supportano un parametro del kernel divisore = N. Quindi, tali kernel supportano una frequenza del timer inferiore senza ricompilazione. Suggeriamo di aggiungere il parametro del kernel divisore = 10 per selezionare una frequenza del timer del kernel guest di 100Hz.

Fonte: i guest Linux possono causare un carico elevato della CPU

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.