Ottimizzazione software per macchine virtuali

Question

Quando sai che il tuo software (non un driver, non parte dell'OS, solo un'applicazione) verrà eseguito principalmente in un ambiente virtualizzato ci sono strategie per ottimizzare il tuo codice e/o le impostazioni del compilatore? O qualche guida per ciò che dovresti e non dovresti fare?

Non si tratta di un guadagno di prestazioni dello 0,0x% ma forse, solo forse ci sono cose semplici che miglioreranno drasticamente le prestazioni o cose che sembrano semplici ma che sono note per essere disastrose in ambienti virtualizzati. Ad esempio, l'abilitazione di CONFIG_PARAVIRT in una compilazione del kernel è facile e può migliorare notevolmente le prestazioni. Ora sto cercando cose simili per le applicazioni, se ce ne sono.

Nel mio caso sarà C++ Code e probabilmente VMWare ma voglio mantenere la domanda come lingua/prodotto-agnostico il più possibile. Mi chiedo se ci siano anche tali strategie o se questa sarebbe una completa perdita di tempo - dopotutto il concetto di virtualizzazione è che non devi preoccupartene troppo.

Answer 1

L'unico consiglio che posso darti è l'uso attento di mlock()/mlockall() .. mentre si guardano i driver con palloncini buggati.

Ad esempio, se un guest Xen viene avviato con 1 GB, quindi ridotto a 512 MB, è tipico che il dominio privilegiato NON guardasse quanta memoria il kernel paravirtualizzato stava effettivamente promettendo ai processi (cioè Committed_AS). In realtà, con Xen, a meno che questo valore non sia posto su Xenbus, l'host privilegiato non ha idea di cosa faccia un tale pallone. Credo che questo coincida anche con KVM, a seconda di come è configurato il kernel .. ma la tua domanda presume che non sappiamo nulla di queste cose :)

Quindi, proteggere le cose (attenzione, ma prudenza) che semplicemente non può essere sfasato, considera sempre lo scenario "il cielo sta calando".

Allo stesso modo, l'uso di posix_fadvise()/posix_madvise() per indicare al kernel PV quanto basta o non è necessario il buffering è sempre una buona idea.

Oltre a ciò, c'è ben poco che tu possa fare .. dato che stai parlando solo del kernel paravirtualizzato, che è stato progettato per rendere i processi ignari alla virtualizzazione in primo luogo.

Non uso molto KVM (ancora), anche se ho intenzione di esplorarlo di più in futuro. Tuttavia, il 90% delle cose che sto scrivendo ultimamente è specificamente progettato per essere eseguito su guest Xen paravirtualizzati. Mi dispiace di essere un po 'centric Xen/C, ma questo è dove la mia esperienza è e dovrebbe essere presente con in linea principale (ops presto anche Xen-0) :)

Buona domanda, btw :)

Edit:

Quando ho detto "attento ma prudente", intendevo un gradino sopra il conservatore. Se il programma assegna una struttura del lavoro che richiede la maggior parte delle funzioni, bloccala. Se assegnate buffer per leggere file enormi, non bloccarli .. e assicuratevi di chiamare posix_fadvise() per far sapere al kernel che intendete accedervi solo una volta (se questo è il caso). Inoltre, assicurati di consigliare il kernel sull'utilizzo dei file mappati in memoria, specialmente se servono ad organizzare la concorrenza.

In breve, aiutare i vostri kernel ospitanti gestire la memoria, non lasciare i blocchi allocati critiche vengono gettati in paging sporca, non date per scontato il vostro programma è più importante di qualsiasi altra cosa, bloccando tutto ciò alloca :)

Ci scusiamo per l'ambiguità. La frase migliore che ho potuto fare è stata "attenta, ma prudente".

Answer 2

Il mio unico consiglio è di tenere bassa la memoria e l'IO, se possibile.

IO in una VM è piuttosto lento rispetto all'hardware fisico. Se puoi evitare di farlo, evitalo.

Answer 3

Le cose lente sull'hardware reale sono ancora più lente quando il sistema è virtualizzato. Dipende dalla tecnologia di virtualizzazione utilizzata quanto più lentamente diventano.

Evitare in particolare tutto ciò che richiede I/O con il mondo esterno all'ambiente virtuale. A partire da come sono impostate le cose, questo include il disegno sullo schermo, lo swapping e l'I/O su disco e rete. È all'incirca in ordine decrescente di importanza.

Se possibile, fingere di scrivere per un computer di dieci anni. Se la tua applicazione funziona su un PC desktop del 1999 o un laptop, dovrebbe andare bene.

Answer 4

Ho trovato tutto ciò che riguarda I/O.

Le VM in genere fanno molto male all'IO. Questo rende le cose molto peggiori di quelle che sarebbero in una vera latta.

Lo swap è soprattutto un cattivo killer: distrugge completamente le prestazioni della macchina virtuale, anche un po ', dato che IO è così lento.

La maggior parte delle implementazioni ha una grande quantità di conflitti di I/O tra macchine virtuali, non ne ho visto uno che eviti questo o lo gestisca in modo ragionevole.

Quindi, se possibile, usa un ramdisc per i file temporanei, ma non farlo scambiare, perché sarebbe ancora peggio.