Ottimizzazione del software per macchine virtuali

Question

Quando sai che il tuo software (non un driver, non parte del sistema operativo, 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 su cosa dovresti e non dovresti fare?

Non si tratta di un aumento delle prestazioni dello 0,0x% ma forse, forse ci sono cose semplici che miglioreranno drasticamente le prestazioni o cose che sembrano semplici ma sono note per essere disastrose in ambienti virtualizzati. Ad esempio, abilitare CONFIG_PARAVIRT in una build 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à il codice C ++ e probabilmente VMWare, ma voglio mantenere la domanda il più agnostica lingua / prodotto possibile. Mi chiedo se ci siano persino strategie del genere o se ciò sarebbe una completa perdita di tempo - dopo tutto il concetto di virtualizzazione è che non devi preoccuparti troppo di esso.

Answer 1

L'unico consiglio che posso darti è un uso attento di mlock () / mlockall () .. mentre cerco driver con palloncini difettosi.

Ad esempio, se un guest Xen viene avviato con 1 GB, quindi ridotto a 512 MB, è tipico che il dominio privilegiato NON guardi a quanta memoria il kernel paravirtualizzato promettesse effettivamente ai processi (ovvero Committed_AS). In realtà, con Xen, a meno che questo valore non sia posizionato su Xenbus, l'host privilegiato non ha idea di cosa farà un simile fumetto. 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, proteggi le cose (stai attento, ma prudente) che semplicemente non possono essere sfogliate, considera sempre lo scenario "Il cielo sta cadendo".

Allo stesso modo, usare posix_fadvise () / posix_madvise () per dire al kernel PV quanto è necessario o meno il buffering è sempre una buona idea.

Oltre a ciò, c'è molto poco che puoi fare .. dato che stai parlando solo con il kernel paravirtualizzato, che è progettato per rendere i processi ignari della 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 ho scritto di recente è stato appositamente progettato per essere eseguito su ospiti Xen paravirtualizzati. Mi dispiace essere un po 'incentrato su Xen / C, ma è lì che la mia esperienza è e pv_ops è in prima linea (presto anche xen-0 ops) :)

Bella domanda, tra l'altro :)

Modifica

Quando ho detto 'attento ma prudente', intendevo un passo sopra conservatore. Se il programma alloca una struttura di lavoro necessaria per la maggior parte delle funzioni, bloccarla. Se i tuoi buffer di allocazione leggono file enormi, non bloccarli .. e assicurati di chiamare posix_fadvise () per far sapere al kernel che intendi accedervi solo una volta (in questo caso). Inoltre, assicurati di consigliare il kernel sull'utilizzo dei file mappati in memoria, specialmente se servono per organizzare la concorrenza.

In breve, aiuta il kernel host a gestire la memoria, non lasciare che i blocchi allocati critici vengano gettati nel paging sporco, non dare per scontato che il tuo programma sia più importante di qualsiasi altra cosa bloccando tutto ciò che alloca :)

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

Answer 2

Ho trovato che tutto riguardava l'I / O.

Le VM in genere fanno schifo incredibilmente male all'IO. Questo rende le cose molto peggio di quanto non sarebbero in realtà.

Lo scambio è particolarmente un killer negativo: rovina completamente le prestazioni della VM, anche un po ', poiché IO ??è così lento.

La maggior parte delle implementazioni ha una grande quantità di contese IO tra VM, non ne ho visto uno che lo eviti o lo gestisca in modo sensato.

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

Answer 3

Il mio unico consiglio è quello di mantenere la memoria e l'utilizzo di IO basso se possibile.

L'IO in una macchina virtuale è piuttosto lenta rispetto all'hardware fisico. Se riesci a evitare di farlo, evitalo.

Answer 4

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

Evita soprattutto tutto ciò che richiede I / O con il mondo al di fuori dell'ambiente virtuale. A seconda di come sono impostate le cose, questo include disegno sullo schermo, scambio e I / O del disco e della rete. Questo è approssimativamente in un ordine decrescente di importanza.

Se possibile, fai finta di scrivere per un computer di dieci anni. Se l'applicazione funzionerà su un PC desktop o laptop del 1999, dovrebbe funzionare correttamente.