guestfs-performance - Online nel cloud

PROGRAMMA:

NOME

guestfs-performance - ingegneria libguestfs per le massime prestazioni

DESCRIZIONE

Questa pagina documenta come ottenere le massime prestazioni da libguestfs, specialmente quando
ti aspetti di utilizzare libguestfs per manipolare migliaia di macchine virtuali o immagini disco.

Tre aree principali sono coperte. Libguestfs esegue un'appliance (una piccola distribuzione Linux)
all'interno di qemu/KVM. Le prime due aree sono: ridurre al minimo il tempo impiegato per iniziare questo
apparecchio e il numero di volte che l'apparecchio deve essere avviato. La terza area è
ridurre il tempo necessario per l'ispezione delle macchine virtuali.

LINEA DI BASE MISURE

Prima di apportare modifiche al modo in cui usi libguestfs, prendi le misurazioni di base.

Linea di base: Di partenza , il apparecchio
A macchina scarica, tempo quanto tempo occorre per avviare l'apparecchio:

time guestfish -a /dev/null run

Esegui questo comando più volte di seguito e scarta le prime esecuzioni, in modo da essere
misurare un tipico caso di "cache calda".

Spiegazione

Questo comando avvia l'appliance libguestfs su un disco nullo, quindi si chiude immediatamente
giù. La prima volta che esegui il comando, creerà un'appliance e la cache
(di solito sotto /var/tmp/.guestfs-*). Le esecuzioni successive dovrebbero riutilizzare l'appliance memorizzata nella cache.

Previsto sul risultato

Dovresti aspettarti di ottenere tempi inferiori a 6 secondi. Se le volte che vedi su an
macchina scarica sono al di sopra di questo, quindi vedere la sezione "RISOLUZIONE DEI PROBLEMI PRESTAZIONI SCARSE"
qua sotto.

Linea di base: Esecuzione ispezione of a ospite
Per questo test avrai bisogno di una macchina scarica e almeno un guest reale o un'immagine del disco.
Se hai intenzione di usare libguestfs solo contro X guest (es. X = Windows), usa
un ospite X qui sarebbe più appropriato. Se stai pianificando di eseguire libguestfs contro
un mix di ospiti, quindi usa un mix di ospiti per i test qui.

Tempo quanto tempo ci vuole per eseguire l'ispezione e montare i dischi del guest. Utilizzare il
primo comando se utilizzerai immagini disco e il secondo comando se lo farai
usando libvirt.

ora guestfish --ro -a disk.img -i esci

time guestfish --ro -d GuestName -i exit

Esegui il comando più volte di seguito e scarta le prime esecuzioni, in modo da essere
misurare un tipico caso di "cache calda".

Spiegazione

Questo comando avvia l'appliance libguestfs sull'immagine del disco denominata o sul guest libvirt,
esegue l'ispezione libguestfs su di esso (vedi "ISPEZIONE" in ospiti(3)), monta l'ospite
dischi, quindi scarta tutti questi risultati e si spegne.

La prima volta che esegui il comando, creerà un'appliance e la cache (di solito
per /var/tmp/.guestfs-*). Le esecuzioni successive dovrebbero riutilizzare l'appliance memorizzata nella cache.

Previsto sul risultato

Dovresti aspettarti tempi che sono ≤ 5 secondi maggiori di quelli misurati nella prima linea di base
prova sopra. (Ad esempio, se il primo test di riferimento è stato eseguito in 5 secondi, allora questo test
dovrebbe funzionare in ≤ 10 secondi).

COMPRENSIONE LA APPARECCHIO E QUANDO IT IS COSTRUITO/CACHECATO

La prima volta che usi libguestfs, verrà creato e memorizzato nella cache un'appliance. Questo di solito è
in /var/tmp/.guestfs-*, a meno che tu non abbia impostato $TMPDIR o $LIBGUESTFS_CACHEDIR nel qual caso
sarà in quella directory temporanea.

Per maggiori informazioni sulla struttura dell'apparecchio, vedere "APPARECCHI SUPERMIN" in
supermini(1).

Ogni volta che viene eseguito libguestfs, verificherà che nessun file host utilizzato dall'appliance sia presente
cambiato. In caso affermativo, l'apparecchio viene ricostruito. Questo di solito accade quando un pacchetto
è installato o aggiornato sull'host (ad es. utilizzando programmi come "yum" o "apt-get"). Il
motivo per ricostruire l'apparecchio è la sicurezza: il nuovo programma che è stato
installato potrebbe contenere una correzione di sicurezza, quindi vogliamo includere il programma corretto nel
apparecchio automaticamente.

Queste sono le implicazioni sulle prestazioni:

· Il processo di costruzione (o ricostruzione) dell'appliance memorizzata nella cache è lento e puoi
evitare che ciò accada utilizzando un apparecchio fisso (vedi sotto).

· Se non si utilizza un dispositivo fisso, tenere presente che l'aggiornamento del software sull'host causerà
una volta ricostruire l'apparecchio.

· / Var / tmp (o $TMPDIR, $LIBGUESTFS_CACHEDIR) dovrebbe essere su un disco veloce e avere molto
di spazio per l'apparecchio.

UTILIZZO A FISSO APPARECCHIO

Per controllare completamente quando l'appliance è stata costruita, puoi costruire un'appliance fissa. Questo
l'appliance deve essere memorizzata su un disco locale veloce.

Per compilare l'appliance, esegui il comando:

libguestfs-make-fixed-appliance

sostituendo" " con il nome di una directory in cui verrà memorizzato l'apparecchio
(normalmente chiameresti una sottodirectory, ad esempio: /usr/local/lib/guestfs/appliance or
/dev/shm/apparecchio).

Quindi imposta $LIBGUESTFS_PATH (e assicurati che questa variabile d'ambiente sia impostata nella tua libguestfs
program), o modifica il tuo programma in modo che chiami "guestfs_set_path". Per esempio:

esporta LIBGUESTFS_PATH=/usr/local/lib/guestfs/appliance

Ora puoi eseguire programmi libguestfs, strumenti virt, guestfish ecc. normalmente. I programmi
utilizzerà l'appliance fissa e non costruirà, ricostruirà o metterà mai nella cache la propria
apparecchio.

(Per informazioni dettagliate su questo argomento, vedere: libguestfs-make-fixed-appliance(1)).

Prestazione of , il fisso apparecchio
Nei nostri test non abbiamo riscontrato che l'utilizzo di un apparecchio fisso fornisse risultati misurabili
vantaggio in termini di prestazioni, anche quando l'apparecchio si trovava in memoria (ad es. acceso /dev/shm).
Tuttavia ci sono due punti da considerare:

1. L'utilizzo di un'appliance fissa impedisce a libguestfs di ricostruire l'appliance, il che significa che
che libguestfs avrà tempi di avvio più prevedibili.

2. L'apparecchio viene caricato su richiesta. Un semplice test come:

time guestfish -a /dev/null run

non carica molto l'apparecchio. Un vero programma libguestfs che usa complicato
Le chiamate API richiederebbero molto più carico dell'appliance. Essere in grado di memorizzare il
l'appliance in una posizione specifica rende le prestazioni più prevedibili.

RIDUCENTE LA NUMERO OF TEMPI LA APPARECCHIO IS LANCIATO

Di gran lunga il modo più efficace, anche se non sempre il più semplice, per ottenere buone prestazioni è
per garantire che l'apparecchio venga avviato il numero minimo di volte. Questo sarà probabilmente
implica la modifica dell'applicazione libguestfs.

Prova a chiamare "guestfs_launch" al massimo una volta per macchina virtuale o immagine disco di destinazione.

Invece di usare un'istanza separata di pesce ospite(1) per apportare una serie di modifiche al
stesso guest, usa una singola istanza di guestfish e/o usa guestfish --Ascoltare opzione.

Considera di scrivere il tuo programma come un demone che tiene aperto un ospite mentre crea una serie
di modifiche. Oppure organizza tutte le operazioni che desideri eseguire prima di aprire l'ospite.

Puoi anche provare ad aggiungere dischi da più ospiti a una singola appliance. prima di provare
questo, notare i seguenti punti:

1. L'aggiunta di più ospiti a un'appliance è un problema di sicurezza perché potrebbe consentirne uno
guest per interferire con i dischi di un altro guest. Fallo solo se ti fidi di tutte le
ospiti, o se puoi raggruppare gli ospiti per fiducia.

2. Esiste un limite rigido al numero di dischi che è possibile aggiungere a un singolo dispositivo. Chiamata
"guestfs_max_disks" in ospiti(3) per ottenere questo limite. Per ulteriori informazioni vedere
"LIMITI" in ospiti(3).

3. Usare libguestfs in questo modo è complicato. I dischi possono avere interazioni impreviste: per
esempio, se due ospiti utilizzano lo stesso UUID per un filesystem (perché sono stati clonati),
o avere gruppi di volumi con lo stesso nome (ma vedere "guestfs_lvm_set_filter").

virt-df(1) aggiunge più dischi per impostazione predefinita, quindi il codice sorgente per questo programma sarebbe a
buon punto di partenza.

GRASSO SOLIDO VEGETALE O ANIMALE PER CUCINARE LA ORARIO PRESO PER ISPEZIONE OF VM

Il consiglio principale è ovvio: non eseguire l'ispezione (che è costosa) a meno che non sia necessario
i risultati.

Se in precedenza hai eseguito un'ispezione sull'ospite, potrebbe essere sicuro memorizzare nella cache e
riutilizzare i risultati dell'ultima volta.

Alcuni dischi non devono essere affatto ispezionati: ad esempio, se stai creando un disco
image o se l'immagine del disco non è una macchina virtuale o se l'immagine del disco ha un layout noto.

Anche quando è richiesta l'ispezione di base ("guestfs_inspect_os"), l'ispezione ausiliaria
operazioni possono essere evitate:

· Il montaggio dei dischi è necessario solo per ottenere ulteriori informazioni sul filesystem.

· Elencare le applicazioni ("guestfs_inspect_list_applications") è un'operazione costosa
su Linux, ma quasi gratuito su Windows.

· La generazione di un'icona ospite ("guestfs_inspect_get_icon") è economica su Linux ma costosa
Su Windows.

PARALLELO APPARECCHI

Le appliance Libguestfs sono per lo più legate all'I/O e puoi avviare più appliance in
parallelo. A condizione che ci sia abbastanza memoria libera, dovrebbe esserci poca differenza in
lancio di 1 appliance contro N appliance in parallelo.

Su un laptop a 2 core (4 thread) con 16 GB di RAM, utilizzando il test (non particolarmente realistico)
Script Perl di seguito, il grafico seguente mostra un'eccellente scalabilità durante l'esecuzione tra 1
e 20 apparecchi in parallelo:

12 ++---+----+----+----+-----+----+----+----+----+-- -++
+ + + + + + + + + + *
| |
| *|
11++++
| |
| |
| * * |
10++++
| *|
| |
s | |
9++++
e| |
| *|
c| |
8++ * ++
o| *|
| |
n7++++
| *|
d | *|
| |
s6++++
| * * |
| *|
| |
5++++
| |
| *|
| * * |
4++++
| |
| |
+ * * * + + + + + + + + +
3 ++-*-+----+----+----+-----+----+----+----+----+-- -++
0 2 4 6 8 10 12 14 16 18 20
numero di apparecchi paralleli

È possibile far funzionare molti più di 20 apparecchi in parallelo, ma se si utilizza il
libvirt backend, allora dovresti essere consapevole che libvirt limita il numero di
connessioni client a 20.

Il semplice script Perl di seguito è stato utilizzato per raccogliere i dati per il grafico sopra, ma c'è
molte più informazioni su questo argomento, inclusi script e grafici di test più avanzati,
disponibile nei seguenti post del blog:

http://rwmj.wordpress.com/2013/02/25/multiple-libguestfs-appliances-in-parallel-part-1/
http://rwmj.wordpress.com/2013/02/25/multiple-libguestfs-appliances-in-parallel-part-2/
http://rwmj.wordpress.com/2013/02/25/multiple-libguestfs-appliances-in-parallel-part-3/
http://rwmj.wordpress.com/2013/02/25/multiple-libguestfs-appliances-in-parallel-part-4/

#!/usr/bin/env perl

usare rigorosamente;
utilizzare i fili;
utilizzare gli avvisi;
usa Sys::Guestfs;
usa Time::HiRes qw(time);

sottoprova {
my $g = Sys::Guestfs->new;
$g->add_drive_ro ("/dev/null");
$g->lancio ();

# Puoi aggiungere del lavoro da fare per libguestfs qui.

$g->chiudi ();
}

# Metti tutto nella cache.
test (); test (); test ();

per i miei $nr_threads (1..20) {
my $start_t = ora ();
i miei @thread;
foreach (1..$nr_thread) {
push @threads, threads->create (\&test)
}
foreach (@thread) {
$_->unisci ();
if (mio $err = $_->error ()) {
die "lancio fallito con $nr_threads thread: $err"
}
}
mio $end_t = ora ();
printf ("%d %.2f\n", $nr_threads, $end_t - $start_t);
}

UTILIZZO MODALITÀ UTENTE LINUX

A partire da libguestfs 1.24, è stato possibile utilizzare il backend User-Mode Linux (uml)
invece di KVM (vedi "USER-MODE LINUX BACKEND" in ospiti(3)). Questa sezione fa un po'
osservazioni generali su questo backend, ma lo è vivamente consigliabile per misurare il proprio
carico di lavoro in UML piuttosto che fidarsi di commenti o intuizioni.

· UML di solito esegue le stesse prestazioni o leggermente più lentamente di KVM, su baremetal.

· Tuttavia, UML spesso esegue le stesse prestazioni in virtualizzazione come su baremetal,
considerando che KVM può essere eseguito molto più lentamente sotto la virtualizzazione (poiché l'accelerazione hardware virt
Non è disponibile).

· Il caricamento e il download sono fino a 10 volte più lenti su UML rispetto a KVM. Libguestfs invia
questi dati sulla porta seriale emulata UML, che è molto meno efficiente di quella di KVM
virtio-seriale.

· UML manca di alcune funzionalità (ad es. il supporto per qcow2), quindi potrebbe non essere applicabile.

Per alcune cifre reali, vedere:
http://rwmj.wordpress.com/2013/08/14/performance-of-user-mode-linux-as-a-libguestfs-backend/# Content

RISOLUZIONE DEI PROBLEMI POVERO PERFORMANCE

Garantire hardware virtualizzazione is disponibile
Usa il / proc / cpuinfo e questa pagina:

http://virt-tools.org/learning/check-hardware-virt/

per garantire la disponibilità della virtualizzazione hardware. Nota che potrebbe essere necessario abilitarlo
nel tuo BIOS.

L'hardware virt di solito non è disponibile all'interno delle VM e libguestfs verrà eseguito lentamente all'interno
un'altra macchina virtuale qualunque cosa tu faccia. La virtualizzazione annidata non funziona bene nel nostro
esperienza, e non è certamente un sostituto per l'esecuzione di libguestfs su baremetal.

Garantire KVM is disponibile
Assicurati che KVM sia abilitato e disponibile per l'utente che eseguirà libguestfs. Dovrebbe
essere sicuro di impostare i permessi 0666 su /dev/kvm e la maggior parte delle distribuzioni ora lo fa.

Processori a evitare
Evita i processori che non dispongono della virtualizzazione hardware e alcuni processori che lo sono
semplicemente molto lento (AMD Geode è un ottimo esempio).

Xen dom0
In Xen, dom0 è una macchina virtuale, quindi la virtualizzazione dell'hardware non è disponibile.

DETTAGLIATO TEMPI UTILIZZO TS

Usa il ts(1) comando (da moreutils) per mostrare i tempi dettagliati:

$ guestfish -a /dev/null run -v |& ts -i '%.s'
0.000022 libguestfs: launch: program=guestfish
0.000134 libguestfs: lancio: versione=1.29.31fedora=23,release=2.fc23,libvirt
0.000044 libguestfs: avvio: backend registrato: unix
0.000035 libguestfs: lancio: backend registrato: uml
0.000035 libguestfs: lancio: backend registrato: libvirt
0.000032 libguestfs: lancio: backend registrato: diretto
0.000030 libguestfs: launch: backend=libvirt
0.000031 libguestfs: avvia: tmpdir=/tmp/libguestfsw18rBQ
0.000029 libguestfs: launch: umask=0002
0.000031 libguestfs: lancio: euid=1000
0.000030 libguestfs: versione libvirt = 1002012 (1.2.12)
[eccetera]

I timestamp sono secondi (in modo incrementale dalla riga precedente).

DETTAGLIATO TEMPI UTILIZZO SISTEMATAP

Puoi usare SystemTap (STAP(1)) per ottenere tempi dettagliati dai programmi libguestfs.

Salva il seguente script come time.stap:

ultimo globale;

funzione display_time() {
ora = gettimeofday_us ();
delta = 0;
se (ultimo > 0)
delta = ora - ultimo;
ultimo = ora;

printf ("%d (+%d):", ora, delta);
}

inizio sonda {
ultimo = 0;
printf ("pronto\n");
}

/* Visualizza tutte le chiamate ai marker statici. */
processo sonda("/ Usr / lib*/libguestfs.so.0")
.provider("guestfs").mark("*") ? {
mostra_ora();
printf ("\t%s %s\n", $$nome, $$parms);
}

/* Visualizza tutte le chiamate alle funzioni guestfs_*. */
processo sonda("/ Usr / lib*/libguestfs.so.0")
.function("guestfs_[az]*") ? {
mostra_ora();
printf ("\t%s %s\n", probefunc(), $$parms);
}

Eseguilo come root in una finestra:

# passo tempo.passo
pronto

Stampa "pronto" quando SystemTap ha caricato il programma. Esegui il tuo programma libguestfs,
guestfish o uno strumento virt in un'altra finestra. Per esempio:

$ guestfish -a /dev/null eseguito

Nella finestra di stap vedrai una grande quantità di output, con il tempo impiegato per ciascuno
passo mostrato (microsecondi tra parentesi). Per esempio:

xxxx (+0): guestfs_create
xxxx (+29): guestfs_set_pgroup g=0x17a9de0 pgroup=0x1
xxxx (+9): guestfs_add_drive_opts_argv g=0x17a9de0 [...]
xxxx (+8): guestfs_int_safe_strdup g=0x17a9de0 str=0x7f8a153bed5d
xxxx (+19): guestfs_int_safe_malloc g=0x17a9de0 nbytes=0x38
xxxx (+5): guestfs_int_safe_strdup g=0x17a9de0 str=0x17a9f60
xxxx (+10): guestfs_launch g=0x17a9de0
xxxx (+4): avvio_avvio
[eccetera]

Dovrai consultare e persino modificare il sorgente in libguestfs per comprenderlo appieno
Il risultato.

DETTAGLIATO DEBUG UTILIZZO GDB

Puoi collegarti al BIOS/kernel dell'appliance usando gdb. Se sai cosa stai facendo,
questo può essere un modo utile per diagnosticare le regressioni di avvio.

Innanzitutto, devi cambiare qemu in modo che funzioni con le opzioni "-S" e "-s". Queste opzioni
fa sì che qemu si metta in pausa all'avvio e ti consenta di collegare un debugger. Leggi whoa(1) per ulteriori
informazione. Libguestfs invoca qemu più volte (per scansionare l'output della guida e così via)
e vuoi solo che l'invocazione finale di qemu utilizzi queste opzioni, quindi usa un wrapper qemu
sceneggiatura in questo modo:

#!/ bin / bash -

# Imposta questo per puntare al vero binario qemu.
qemu=/usr/bin/qemu-kvm

if [ "$1" != "-globale" ]; poi
# Scansione dell'output della guida, ecc.
exec $qemu "$@"
altro
# Veramente in esecuzione qemu.
exec $qemu -S -s "$@"
fi

Ora esegui guestfish o un altro strumento libguestfs con il wrapper qemu (vedi "QEMU WRAPPERS" in
ospiti(3) per capire cosa sta facendo):

LIBGUESTFS_HV=/percorso/di/qemu-wrapper guestfish -a /dev/null -v run

Questo dovrebbe fermarsi subito dopo l'avvio di qemu. In un'altra finestra, allega a qemu usando gdb:

$ GDB
(gdb) imposta l'architettura i8086
Si presume che l'architettura di destinazione sia i8086
(gdb) target remoto: 1234
Debug remoto utilizzando : 1234
0x0000fff0 dentro ?? ()
(gdb) continua

A questo punto puoi usare le tecniche gdb standard, ad es. premendo "^C" per interrompere l'avvio
e "bt" ottengono una traccia dello stack, impostando punti di interruzione, ecc. Nota che quando hai superato il
BIOS e nel kernel Linux, ti consigliamo di riportare l'architettura a 32 o 64
po.

Usa guestfs-performance online utilizzando i servizi onworks.net