guestfs-performance - Online în cloud

PROGRAM:

NUME

guestfs-performance - proiectează libguestfs pentru cea mai bună performanță

DESCRIERE

Această pagină documentează cum să obțineți cea mai mare performanță din libguestfs, mai ales când
vă așteptați să utilizați libguestfs pentru a manipula mii de mașini virtuale sau imagini de disc.

Sunt acoperite trei domenii principale. Libguestfs rulează un dispozitiv (o mică distribuție Linux)
în interiorul qemu/KVM. Primele două domenii sunt: ​​minimizarea timpului necesar pentru a începe acest lucru
aparatul și de câte ori trebuie pornit aparatul. A treia zonă este
scurtarea timpului necesar pentru inspecția VM-urilor.

DE BAZĂ MĂSURĂTORI

Înainte de a face modificări în modul în care utilizați libguestfs, luați măsurători de bază.

De bază: Pornire il aparat
Pe o mașină fără încărcătură, timp cât durează pornirea aparatului:

time guestfish -a /dev/null run

Rulați această comandă de mai multe ori la rând și aruncați primele câteva rulări, astfel încât să fiți
măsurarea unui caz tipic „cache fierbinte”.

Explicație

Această comandă pornește aplicația libguestfs pe un disc nul și apoi se închide imediat
ea jos. Prima dată când rulați comanda, aceasta va crea un dispozitiv și îl va stoca în cache
(de obicei sub /var/tmp/.guestfs-*). Executările ulterioare ar trebui să refolosească dispozitivul din cache.

Așteptat rezultate obținute

Ar trebui să vă așteptați să obțineți timpi sub 6 secunde. Dacă orele pe care le vezi pe o
mașina descărcată se află deasupra acesteia, apoi consultați secțiunea „DEPANAREA PERFORMANȚEI SRASE”
de mai jos.

De bază: Efectuarea inspecție of a oaspete
Pentru acest test veți avea nevoie de o mașină descărcată și de cel puțin un invitat real sau o imagine de disc.
Dacă intenționați să utilizați libguestfs numai împotriva X invitați (de exemplu, X = Windows), atunci folosiți
un oaspete X aici ar fi cel mai potrivit. Dacă intenționați să rulați libguestfs împotriva
un mix de invitați, apoi folosiți un mix de invitați pentru testare aici.

Stabiliți cât timp durează efectuarea inspecției și montarea discurilor oaspetelui. Folosește
prima comandă dacă veți folosi imagini de disc și a doua comandă dacă veți fi
folosind libvirt.

time guestfish --ro -a disk.img -i exit

time guestfish --ro -d GuestName -i exit

Rulați comanda de mai multe ori la rând și aruncați primele câteva rulări, astfel încât să fiți
măsurarea unui caz tipic „cache fierbinte”.

Explicație

Această comandă pornește aplicația libguestfs de pe imaginea de disc numită sau oaspete libvirt,
efectuează inspecția libguestfs asupra acestuia (vezi „INSPECȚIE” în guestfs(3)), se montează pe cea a oaspetelui
discuri, apoi renunță la toate aceste rezultate și se oprește.

Prima dată când rulați comanda, aceasta va crea un dispozitiv și îl va stoca în cache (de obicei
în /var/tmp/.guestfs-*). Executările ulterioare ar trebui să refolosească dispozitivul din cache.

Așteptat rezultate obținute

Trebuie să vă așteptați la timpi care sunt ≤ 5 secunde mai mari decât cei măsurați în prima linie de bază
testul de mai sus. (De exemplu, dacă primul test de bază a rulat în 5 secunde, atunci acest test
ar trebui să ruleze în ≤ 10 secunde).

ÎNŢELEGERE THE APARAT AND CÂND IT IS CONSTRUIT/CACHAT

Prima dată când utilizați libguestfs, acesta va construi și va stoca în cache un dispozitiv. Aceasta este de obicei
in /var/tmp/.guestfs-*, cu excepția cazului în care ați setat $TMPDIR sau $LIBGUESTFS_CACHEDIR, caz în care
va fi sub acel director temporar.

Pentru mai multe informații despre modul în care este construit aparatul, consultați „APLICAȚII SUPERMIN” în
supermin(1).

De fiecare dată când libguestfs rulează, acesta va verifica dacă nu există fișiere gazdă utilizate de dispozitiv
schimbat. Dacă vreunul are, atunci aparatul este reconstruit. Acest lucru se întâmplă de obicei atunci când un pachet
este instalat sau actualizat pe gazdă (de ex. folosind programe precum „yum” sau „apt-get”). The
motivul reconstrucției aparatului este securitatea: noul program care a fost
instalat poate conține o remediere de securitate și, prin urmare, dorim să includem programul fix în fișierul
aparatul automat.

Acestea sunt implicațiile performanței:

· Procesul de construire (sau reconstrucție) a dispozitivului din cache este lent și puteți
evitați acest lucru folosind un aparat fix (vezi mai jos).

· Dacă nu utilizați un aparat fix, rețineți că actualizarea software-ului pe gazdă va cauza
o reconstrucție unică a aparatului.

· / var / tmp (sau $TMPDIR, $LIBGUESTFS_CACHEDIR) ar trebui să fie pe un disc rapid și să aibă o mulțime
de spațiu pentru aparat.

UTILIZAREA A FIXED APARAT

Pentru a controla pe deplin când este construit aparatul, puteți construi un aparat fix. Acest
aparatul ar trebui să fie stocat pe un disc local rapid.

Pentru a construi aparatul, rulați comanda:

libguestfs-make-fixed-appliance

înlocuind " " cu numele unui director în care va fi stocat aparatul
(în mod normal, ați denumi un subdirector, de exemplu: /usr/local/lib/guestfs/appliance or
/dev/shm/appliance).

Apoi setați $LIBGUESTFS_PATH (și asigurați-vă că această variabilă de mediu este setată în libguestfs
program), sau modificați programul astfel încât să numească „guestfs_set_path”. De exemplu:

exportați LIBGUESTFS_PATH=/usr/local/lib/guestfs/appliance

Acum puteți rula programe libguestfs, instrumente virt, guestfish etc. ca de obicei. Programele
va folosi aparatul dvs. fix și nu va construi, reconstrui sau stoca în cache pe al lor
aparat.

(Pentru informații detaliate despre acest subiect, vezi: libguestfs-make-fixed-appliance(1)).

Performanţă of il fixată aparat
În testarea noastră nu am constatat că utilizarea unui aparat fix a dat vreun lucru măsurabil
beneficii de performanță, chiar și atunci când aparatul a fost localizat în memorie (adică pornit /dev/shm).
Cu toate acestea, există două puncte de luat în considerare:

1. Utilizarea unui dispozitiv fix oprește libguestfs să reconstruiască vreodată dispozitivul, adică
că libguestfs va avea timpi de pornire mai previzibili.

2. Aparatul este încărcat la cerere. Un test simplu, cum ar fi:

time guestfish -a /dev/null run

nu încarcă foarte mult din aparat. Un adevărat program libguestfs folosind complicat
Apelurile API ar solicita încărcare mult mai mult din aparat. Fiind capabil să stocheze
aparatul într-o locație specificată face performanța mai previzibilă.

REDUCE THE NUMĂR OF ORI THE APARAT IS LANSAT

De departe cel mai eficient, deși nu întotdeauna cel mai simplu mod de a obține performanțe bune este
pentru a se asigura că aparatul este lansat de un număr minim de ori. Acest lucru va fi probabil
implică schimbarea aplicației libguestfs.

Încercați să apelați „guestfs_launch” cel mult o dată pentru fiecare mașină virtuală țintă sau imagine de disc.

În loc să utilizați o instanță separată de pește oaspete(1) pentru a face o serie de modificări la
același oaspete, utilizați o singură instanță de guestfish și/sau folosiți guestfish --asculta opțiune.

Luați în considerare să vă scrieți programul ca un demon care ține deschis un oaspete în timp ce faceți o serie
a schimbarilor. Sau organizați toate operațiunile pe care doriți să le efectuați înainte de a deschide invitatul.

De asemenea, puteți încerca să adăugați discuri de la mai mulți oaspeți la un singur aparat. Înainte de a încerca
aceasta, rețineți următoarele puncte:

1. Adăugarea mai multor oaspeți la un aparat este o problemă de securitate, deoarece poate permite unul
invitatul să interfereze cu discurile altui invitat. Fă-o doar dacă ai încredere în toate
invitați sau dacă puteți grupa oaspeții în funcție de încredere.

2. Există o limită strictă a numărului de discuri pe care le puteți adăuga la un singur aparat. Apel
„guestfs_max_disks” în guestfs(3) pentru a obține această limită. Pentru mai multe informații vezi
„LIMITE” în guestfs(3).

3. Folosirea libguestfs în acest fel este complicată. Discurile pot avea interacțiuni neașteptate: pentru
de exemplu, dacă doi invitați folosesc același UUID pentru un sistem de fișiere (pentru că au fost clonați),
sau au grupuri de volum cu același nume (dar vezi „guestfs_lvm_set_filter”).

virt-df(1) adaugă mai multe discuri în mod implicit, astfel încât codul sursă pentru acest program ar fi a
bun loc pentru a începe.

Scurtarea THE TIMP LUAT PENTRU INSPECŢIE OF VM-uri

Sfatul principal este evident: nu efectuați inspecția (care este costisitoare) decât dacă aveți nevoie
rezultatele.

Dacă ați efectuat anterior o inspecție asupra oaspetelui, atunci ar putea fi sigur să păstrați cache și
reutilizați rezultatele de la ultima dată.

Unele discuri nu trebuie deloc inspectate: de exemplu, dacă creați un disc
imagine, sau dacă imaginea de disc nu este o VM sau dacă imaginea de disc are un aspect cunoscut.

Chiar și atunci când este necesară inspecția de bază ("guestfs_inspect_os"), inspecție auxiliară
operațiunile pot fi evitate:

· Montarea discurilor este necesară doar pentru a obține informații suplimentare despre sistemul de fișiere.

· Listarea aplicațiilor („guestfs_inspect_list_applications”) este o operațiune costisitoare
pe Linux, dar aproape gratuit pe Windows.

· Generarea unei pictograme invitat ("guestfs_inspect_get_icon") este ieftină pe Linux, dar costisitoare
pe Windows.

PARALEL APARATE

Dispozitivele Libguestfs sunt în mare parte legate de I/O și puteți lansa mai multe dispozitive în
paralel. Cu condiția să existe suficientă memorie liberă, ar trebui să existe o mică diferență între
lansarea 1 aparat vs N aparate în paralel.

Pe un laptop cu 2 nuclee (4 fire) cu 16 GB RAM, folosind testul (nu deosebit de realist)
Scriptul Perl de mai jos, următorul grafic arată o scalabilitate excelentă atunci când rulează între 1
și 20 de aparate în paralel:

12 ++---+----+----+----+-----+----+----+----+----+-- -++
+ + + + + + + + + + *
| |
| * |
11 ++ ++
| |
| |
| * * |
10 ++ ++
| * |
| |
s | |
9 ++ ++
e | |
| * |
c | |
8 ++ * ++
o | * |
| |
n 7 ++ ++
| * |
d | * |
| |
s 6 ++ ++
| * * |
| * |
| |
5 ++ ++
| |
| * |
| * * |
4 ++ ++
| |
| |
+ * * * + + + + + + + +
3 ++-*-+----+----+----+-----+----+----+----+----+-- -++
0 2 4 6 8 10 12 14 16
numărul de aparate paralele

Este posibil să rulați mai mult de 20 de aparate în paralel, dar dacă utilizați
backend libvirt, atunci ar trebui să știți că libvirt limitează numărul de
conexiuni client la 20.

Scriptul Perl simplu de mai jos a fost folosit pentru a colecta datele pentru diagrama de mai sus, dar există
mult mai multe informații despre acest subiect, inclusiv scripturi și grafice de testare mai avansate,
disponibil în următoarele postări pe 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

folosiți strict;
folosiți fire;
folosiți avertismente;
utilizați Sys::Guestfs;
utilizați Time::HiRes qw(time);

sub test {
my $g = Sys::Guestfs->new;
$g->add_drive_ro ("/dev/null");
$g->lansare ();

# Puteți adăuga ceva de lucru pentru libguestfs aici.

$g->close ();
}

# Pune totul în cache.
Test (); Test (); Test ();

pentru firele mele de $nr_threads (1..20) {
my $start_t = ora ();
@threadurile mele;
foreach (1..$nr_threads) {
push @threads, fire->creați (\&test)
}
foreach (@threads) {
$_->ună ();
dacă ($erarea mea = $_->eroare ()) {
die "lansarea a eșuat cu fire de discuții $nr_threads: $err"
}
}
my $end_t = timp ();
printf ("%d %.2f\n", $nr_threads, $end_t - $start_t);
}

UTILIZAREA MODUL UTILIZATOR LINUX

Începând cu libguestfs 1.24, a fost posibil să se utilizeze backend-ul Linux (uml) în mod utilizator
în loc de KVM (consultați „BACKEND LINUX MODUL UTILIZATOR” în guestfs(3)). Această secțiune face unele
remarci generale despre acest backend, dar este extrem de recomandabil să-ți măsori pe al tău
sarcina de lucru sub UML, mai degrabă decât comentariile de încredere sau intuiția.

· UML funcționează de obicei la fel sau ușor mai lent decât KVM, pe baremetal.

· Cu toate acestea, UML funcționează adesea la fel în virtualizare ca și pe baremetal,
întrucât KVM poate rula mult mai lent în condiții de virtualizare (deoarece accelerarea hardware virt
nu este disponibilă).

· Încărcarea și descărcarea sunt de 10 ori mai lente în UML decât KVM. Libguestfs trimite
aceste date prin portul serial emulat UML, care este mult mai puțin eficient decât KVM
virtio-serial.

· UML nu are unele caracteristici (de ex. suport pentru qcow2), deci este posibil să nu fie aplicabil deloc.

Pentru câteva cifre reale, consultați:
http://rwmj.wordpress.com/2013/08/14/performance-of-user-mode-linux-as-a-libguestfs-backend/#conţinut

DEPANARE SĂRAC PERFORMANȚĂ

Asigura hardware virtualizare is disponibil
Utilizare / proc / cpuinfo si aceasta pagina:

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

pentru a se asigura că virtualizarea hardware este disponibilă. Rețineți că poate fi necesar să-l activați
în BIOS-ul tău.

Hardware virt nu este de obicei disponibil în interiorul mașinilor virtuale, iar libguestfs va rula lent în interior
o altă mașină virtuală orice ai face. Virtualizarea imbricată nu funcționează bine în sistemul nostru
experiență și cu siguranță nu înlocuiește rularea libguestfs pe baremetal.

Asigura KVM is disponibil
Asigurați-vă că KVM este activat și disponibil pentru utilizatorul care va rula libguestfs. Ar trebui
fiți sigur să setați permisiunile 0666 /dev/kvm și majoritatea distribuțiilor fac asta acum.

Procesoare la evita
Evitați procesoarele care nu au virtualizare hardware și unele procesoare care au
pur și simplu foarte lent (AMD Geode fiind un exemplu grozav).

Xen dom0
În Xen, dom0 este o mașină virtuală și, prin urmare, virtualizarea hardware nu este disponibilă.

DETALIAT DISTRIBUTII UTILIZAREA TS

Folosește ts(1) comandă (de la moreutils) pentru a afișa timpii detaliate:

$ guestfish -a /dev/null run -v |& ts -i '%.s'
0.000022 libguestfs: lansare: program=guestfish
0.000134 libguestfs: lansare: version=1.29.31fedora=23,release=2.fc23,libvirt
0.000044 libguestfs: lansare: backend înregistrat: unix
0.000035 libguestfs: lansare: backend înregistrat: uml
0.000035 libguestfs: lansare: backend înregistrat: libvirt
0.000032 libguestfs: lansare: backend înregistrat: direct
0.000030 libguestfs: lansare: backend=libvirt
0.000031 libguestfs: lansare: tmpdir=/tmp/libguestfsw18rBQ
0.000029 libguestfs: lansare: umask=0002
0.000031 libguestfs: lansare: euid=1000
0.000030 libguestfs: versiunea libvirt = 1002012 (1.2.12)
[etc]

Marcajele de timp sunt secunde (incremental de la linia anterioară).

DETALIAT DISTRIBUTII UTILIZAREA SYSTEMTAP

Puteți utiliza SystemTap (Etapa(1)) pentru a obține calendare detaliate din programele libguestfs.

Salvați următorul script ca timp.stap:

ultima globală;

function display_time () {
acum = gettimeofday_us ();
delta = 0;
dacă (ultimul > 0)
delta = acum - ultimul;
ultimul = acum;

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

sonda începe {
ultimul = 0;
printf ("gata\n");
}

/* Afișează toate apelurile către marcatori statici. */
procesul de sondare("/ Usr / lib*/libguestfs.so.0")
.provider("guestfs").mark("*") ? {
display_time();
printf ("\t%s %s\n", $$nume, $$parms);
}

/* Afișează toate apelurile către funcțiile guestfs_*. */
procesul de sondare("/ Usr / lib*/libguestfs.so.0")
.function("guestfs_[az]*") ? {
display_time();
printf ("\t%s %s\n", probefunc(), $$parms);
}

Rulați-l ca root într-o singură fereastră:

# stap timp.stap
gata

Se imprimă „gata” când SystemTap a încărcat programul. Rulați programul libguestfs,
guestfish sau un instrument virt într-o altă fereastră. De exemplu:

$ guestfish -a /dev/null run

În fereastra Stap veți vedea o cantitate mare de rezultate, cu timpul necesar pentru fiecare
pasul prezentat (microsecunde în paranteză). De exemplu:

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): launch_start
[etc]

Va trebui să consultați și chiar să modificați sursa către libguestfs pentru a înțelege pe deplin
ieșirea.

DETALIAT DEBUGARE UTILIZAREA GDB

Vă puteți atașa la BIOS/kernel-ul aparatului folosind gdb. Dacă știi ce faci,
aceasta poate fi o modalitate utilă de a diagnostica regresiile de boot.

În primul rând, trebuie să schimbați qemu, astfel încât să ruleze cu opțiunile „-S” și „-s”. Aceste opțiuni
determina qemu să se întrerupă la pornire și vă permite să atașați un depanator. Citit whoa(1) pentru mai departe
informație. Libguestfs invocă qemu de mai multe ori (pentru a scana rezultatul de ajutor și așa mai departe)
și vrei doar ca invocarea finală a qemu să folosească aceste opțiuni, așa că folosește un wrapper qemu
script ca acesta:

#!/ bin / bash -

# Setați acest lucru pentru a indica binarul real qemu.
qemu=/usr/bin/qemu-kvm

if [ "$1" != "-global" ]; atunci
# Ieșire de ajutor pentru scanare etc.
exec $qemu "$@"
altfel
# Rulează cu adevărat qemu.
exec $qemu -S -s „$@”
fi

Acum rulați guestfish sau alt instrument libguestfs cu qemu wrapper (vezi „QEMU WRAPPERS” în
guestfs(3) pentru a înțelege ce face acest lucru):

LIBGUESTFS_HV=/path/to/qemu-wrapper guestfish -a /dev/null -v run

Acest lucru ar trebui să se întrerupă imediat după lansarea qemu. Într-o altă fereastră, atașați la qemu folosind gdb:

$ gdb
(gdb) arhitectură set i8086
Se presupune că arhitectura țintă este i8086
(gdb) țintă la distanță :1234
Depanare de la distanță folosind :1234
0x0000fff0 în ?? ()
(gdb) cont

În acest moment puteți utiliza tehnici standard gdb, de ex. apăsând „^C” pentru a întrerupe pornirea
și „bt” obțin o urmărire a stivei, setarea punctelor de întrerupere etc. Rețineți că atunci când treceți de
BIOS și în nucleul Linux, veți dori să schimbați arhitectura înapoi la 32 sau 64
biți.

Utilizați online guestfs-performance folosind serviciile onworks.net