guestfs-performance - Online in de Cloud

PROGRAMMA:

NAAM

guestfs-performance - engineering libguestfs voor de beste prestaties

PRODUCTBESCHRIJVING

Deze pagina documenteert hoe u de beste prestaties uit libguestfs kunt halen, vooral wanneer:
je verwacht libguestfs te gebruiken om duizenden virtuele machines of schijfkopieën te manipuleren.

Er worden drie hoofdgebieden behandeld. Libguestfs draait een apparaat (een kleine Linux-distributie)
binnen qemu/KVM. De eerste twee gebieden zijn: het minimaliseren van de tijd die nodig is om hiermee te beginnen
apparaat en het aantal keren dat het apparaat moet worden gestart. Het derde gebied is
verkorting van de tijd die nodig is voor inspectie van VM's.

BASISLIJN AFMETINGEN

Voer basislijnmetingen uit voordat u wijzigingen aanbrengt in de manier waarop u libguestfs gebruikt.

Basislijn: Start de toestel
Op een onbeladen machine, tijd hoe lang het duurt om het apparaat op te starten:

time guestfish -a /dev/null uitgevoerd

Voer deze opdracht meerdere keren achter elkaar uit en gooi de eerste paar runs weg, zodat u:
het meten van een typisch "hot cache"-geval.

Uitleg

Deze opdracht start het libguestfs-apparaat op een nulschijf en sluit vervolgens onmiddellijk af
het naar beneden. De eerste keer dat u de opdracht uitvoert, wordt een apparaat gemaakt en in de cache opgeslagen
(meestal onder /var/tmp/.guestfs-*). Volgende uitvoeringen moeten het apparaat in de cache opnieuw gebruiken.

Verwachte

Je zou verwachten dat je tijden onder de 6 seconden krijgt. Als de tijden die je ziet op een
onbeladen machine zich daarboven bevinden, raadpleeg dan de sectie "PROBLEEMOPLOSSING SLECHTE PRESTATIES"
hieronder.

Basislijn: Uitvoerend inspectie of a gast
Voor deze test heb je een niet-geladen machine en minstens één echte gast- of schijfkopie nodig.
Als je van plan bent om libguestfs te gebruiken tegen alleen X guests (bijv. X = Windows), gebruik dan
een X-gast hier zou het meest geschikt zijn. Als je van plan bent om libguestfs uit te voeren tegen:
een mix van gasten, gebruik dan een mix van gasten om hier te testen.

Tijd hoe lang het duurt om inspectie uit te voeren en de schijven van de gast te koppelen. Gebruik de
eerste commando als je schijfkopieën gaat gebruiken, en het tweede commando als je
libvirt gebruiken.

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

tijd guestfish --ro -d GuestName -i exit

Voer de opdracht meerdere keren achter elkaar uit en gooi de eerste paar runs weg, zodat u
het meten van een typisch "hot cache"-geval.

Uitleg

Dit commando start de libguestfs appliance op de genoemde disk image of libvirt guest,
voert er libguestfs-inspectie op uit (zie "INSPECTIE" in gastfs(3)), monteert de gast
disks, negeert vervolgens al deze resultaten en wordt afgesloten.

De eerste keer dat u de opdracht uitvoert, wordt een apparaat gemaakt en in de cache opgeslagen (meestal
voor /var/tmp/.guestfs-*). Volgende uitvoeringen moeten het apparaat in de cache opnieuw gebruiken.

Verwachte

U kunt tijden verwachten die ≤ 5 seconden langer zijn dan gemeten in de eerste baseline
hierboven testen. (Als de eerste basislijntest bijvoorbeeld in 5 seconden liep, dan is deze test
zou binnen ≤ 10 seconden moeten werken).

BEGRIP HET APPARAAT EN WANNEER IT IS GEBOUWD/CACHED

De eerste keer dat u libguestfs gebruikt, zal het een apparaat bouwen en in de cache plaatsen. Dit is meestal
in /var/tmp/.guestfs-*, tenzij je $TMPDIR of $LIBGUESTFS_CACHEDIR hebt ingesteld, in welk geval
het zal onder die tijdelijke map staan.

Voor meer informatie over de constructie van het apparaat, zie "SUPERMIN APPARATEN" in
supermin(1).

Elke keer dat libguestfs wordt uitgevoerd, controleert het of er geen hostbestanden die door het apparaat worden gebruikt,
veranderd. Als dat het geval is, wordt het apparaat opnieuw opgebouwd. Dit gebeurt meestal wanneer een pakket
is geïnstalleerd of bijgewerkt op de host (bijv. met behulp van programma's zoals "yum" of "apt-get"). De
reden voor het reconstrueren van het apparaat is veiligheid: het nieuwe programma dat is
geïnstalleerd kan een beveiligingsoplossing bevatten, en daarom willen we het vaste programma opnemen in de
apparaat automatisch.

Dit zijn de gevolgen voor de prestaties:

· Het proces van het bouwen (of opnieuw opbouwen) van het apparaat in de cache is traag en u kunt
voorkom dit door een vast toestel te gebruiken (zie hieronder).

· Als u geen vast apparaat gebruikt, houd er dan rekening mee dat het updaten van software op de host tot gevolg zal hebben:
een eenmalige verbouwing van het apparaat.

· / Var / tmp (of $TMPDIR, $LIBGUESTFS_CACHEDIR) moet op een snelle schijf staan ​​en voldoende
ruimte voor het apparaat.

GEBRUIK MAKEND VAN A FIXED APPARAAT

Om volledig te controleren wanneer het toestel wordt gebouwd, kunt u een vast toestel bouwen. Dit
apparaat moet worden opgeslagen op een snelle lokale schijf.

Voer de opdracht uit om het apparaat te bouwen:

libguestfs-make-fixed-appliance

vervangen " " met de naam van een map waarin het apparaat wordt opgeslagen
(normaal noem je een submap, bijvoorbeeld: /usr/local/lib/guestfs/appliance or
/dev/shm/apparaat).

Stel vervolgens $LIBGUESTFS_PATH in (en zorg ervoor dat deze omgevingsvariabele is ingesteld in uw libguestfs
programma), of pas uw programma aan zodat het "guestfs_set_path" aanroept. Bijvoorbeeld:

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

Nu kun je libguestfs-programma's, virt-tools, guestfish enz. zoals normaal uitvoeren. de programma's
zullen uw vaste apparaat gebruiken en zullen nooit hun eigen apparaat bouwen, herbouwen of cachen
apparaat.

(Voor gedetailleerde informatie over dit onderwerp, zie: libguestfs-make-fixed-appliance(1)).

Performance of de vast toestel
Bij onze tests hebben we niet gevonden dat het gebruik van een vast apparaat meetbare
prestatievoordeel, zelfs wanneer het apparaat zich in het geheugen bevond (bijv /dev/shm).
Er zijn echter twee punten om te overwegen:

1. Door een vast apparaat te gebruiken, kunnen libguestfs het apparaat nooit opnieuw opbouwen, wat betekent:
dat libguestfs meer voorspelbare opstarttijden zullen hebben.

2. Het toestel wordt op verzoek geladen. Een simpele test zoals:

time guestfish -a /dev/null uitgevoerd

laadt niet veel van het apparaat. Een echt libguestfs-programma met ingewikkeld
API-aanroepen zouden veel meer van het apparaat vragen. Het kunnen opslaan van de
apparaat op een bepaalde locatie maakt de prestatie voorspelbaarder.

VERMINDEREN HET NUMMER OF TIJDEN HET APPARAAT IS GELANCEERD

Veruit de meest effectieve, maar niet altijd de eenvoudigste manier om goede prestaties te krijgen, is:
om ervoor te zorgen dat het apparaat zo min mogelijk wordt gestart. Dit zal waarschijnlijk
omvatten het wijzigen van uw libguestfs-toepassing.

Probeer 'guestfs_launch' maximaal één keer per virtuele doelmachine of schijfkopie aan te roepen.

In plaats van een apart exemplaar van gastvis(1) om een ​​reeks wijzigingen aan te brengen in de
dezelfde gast, gebruik een enkele gastvis en/of gebruik de gastvis --luisteren optie.

Overweeg om je programma te schrijven als een daemon die een gast openhoudt terwijl je een serie maakt
van veranderingen. Of rangschik alle bewerkingen die u wilt uitvoeren voordat u de guest opent.

U kunt ook proberen schijven van meerdere gasten toe te voegen aan één apparaat. Alvorens te proberen
let hierbij op de volgende punten:

1. Het toevoegen van meerdere gasten aan één apparaat is een beveiligingsprobleem omdat het er één kan toestaan
guest om de schijven van een andere guest te verstoren. Doe het alleen als je alle
gasten, of als u gasten kunt groeperen op basis van vertrouwen.

2. Er is een harde limiet aan het aantal schijven dat u aan een enkel apparaat kunt toevoegen. Telefoongesprek
"guestfs_max_disks" in gastfs(3) om deze limiet te krijgen. Voor meer informatie zie
"GRENZEN" in gastfs(3).

3. Het gebruik van libguestfs op deze manier is ingewikkeld. Schijven kunnen onverwachte interacties hebben: voor
als twee gasten bijvoorbeeld dezelfde UUID gebruiken voor een bestandssysteem (omdat ze gekloond zijn),
of volumegroepen met dezelfde naam hebben (maar zie "guestfs_lvm_set_filter").

virtuele-df(1) voegt standaard meerdere schijven toe, dus de broncode voor dit programma zou zijn:
goede plek om te beginnen.

VERKORTING HET TIJD GENOMEN VOOR INSPECTIE OF VM

Het belangrijkste advies ligt voor de hand: voer geen inspectie uit (wat duur is) tenzij u nodig hebt
het resultaat.

Als u eerder een inspectie van de gast heeft uitgevoerd, is het mogelijk veilig om te cachen en
hergebruik de resultaten van de vorige keer.

Sommige schijven hoeven helemaal niet te worden geïnspecteerd: bijvoorbeeld als u een schijf maakt
image, of als de schijfkopie geen VM is, of als de schijfkopie een bekende lay-out heeft.

Zelfs wanneer basisinspectie ("guestfs_inspect_os") vereist is, is aanvullende inspectie
operaties kunnen worden vermeden:

· Het aankoppelen van schijven is alleen nodig om meer informatie over het bestandssysteem te krijgen.

· Het aanbieden van applicaties ("guestfs_inspect_list_applications") is een dure operatie
op Linux, maar bijna gratis op Windows.

· Het genereren van een gastpictogram ("guestfs_inspect_get_icon") is goedkoop onder Linux, maar duur
op Windows.

PARALLEL HUISHOUDELIJKE APPARATEN

De apparaten van Libguestf zijn meestal I/O-gebonden en je kunt meerdere apparaten in
parallel. Mits er voldoende vrij geheugen is, zou er weinig verschil moeten zijn in
1 toestel vs N toestellen parallel lanceren.

Op een 2-core (4-thread) laptop met 16 GB RAM, met behulp van de (niet bijzonder realistische) test
Perl-script hieronder, de volgende plot toont uitstekende schaalbaarheid bij het uitvoeren tussen 1
en 20 apparaten parallel:

12 ++---+----+----+----+-----+----+----+----+----+-- -++
+ + + + + + + + + + *
| |
| * |
11++++
| |
| |
| * * |
10++++
| * |
| |
s | |
9++++
e | |
| * |
c| |
8 ++ * ++
of | * |
| |
nr 7 ++ ++
| * |
d| * |
| |
s6 ++ ++
| * * |
| * |
| |
5++++
| |
| * |
| * * |
4++++
| |
| |
+ * * * + + + + + + + +
3 ++-*-+----+----+----+-----+----+----+----+----+-- -++
0 2 4 6 8 10 12 14 16 18 20
aantal parallelle apparaten

Het is mogelijk om veel meer dan 20 apparaten parallel te laten werken, maar als u de
libvirt-backend, moet u zich ervan bewust zijn dat libvirt standaard het aantal
klantverbindingen naar 20.

Het eenvoudige Perl-script hieronder werd gebruikt om de gegevens voor de bovenstaande plot te verzamelen, maar er is
veel meer informatie over dit onderwerp, waaronder meer geavanceerde testscripts en grafieken,
beschikbaar in de volgende blogberichten:

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

gebruik strikt;
gebruik draden;
gebruik waarschuwingen;
gebruik Sys::Guestfs;
gebruik Tijd::HiRes qw(tijd);

subtest {
mijn $g = Sys::Guestfs->nieuw;
$g->add_drive_ro ("/dev/null");
$g->start ();

# Je zou wat werk voor libguestfs kunnen toevoegen om hier te doen.

$g->sluiten ();
}

# Haal alles in de cache.
toets (); toets (); toets ();

voor mijn $nr_threads (1..20) {
mijn $start_t = tijd ();
mijn @threads;
foreach (1..$nr_threads) {
push @threads, threads->create (\&test)
}
foreach (@threads) {
$_->doe mee ();
if (mijn $fout = $_->fout ()) {
die "start mislukt met $nr_threads threads: $err"
}
}
mijn $end_t = tijd ();
printf ("%d %.2f\n", $nr_threads, $end_t - $start_t);
}

GEBRUIK MAKEND VAN GEBRUIKERSMODUS LINUX

Sinds libguestfs 1.24 is het mogelijk om de User-Mode Linux (uml) backend te gebruiken
in plaats van KVM (zie "USER-MODE LINUX BACKEND" in gastfs(3)). Dit gedeelte maakt wat
algemene opmerkingen over deze backend, maar het is zeer raadzaam om je eigen te meten
werklast onder UML in plaats van commentaar of intuïtie te vertrouwen.

· UML presteert meestal hetzelfde of iets langzamer dan KVM, op ​​baremetal.

· UML presteert echter vaak hetzelfde onder virtualisatie als op baremetal,
terwijl KVM veel langzamer kan werken onder virtualisatie (aangezien hardware virt-acceleratie)
is niet beschikbaar).

· Uploaden en downloaden is maar liefst 10 keer langzamer op UML dan KVM. Libguestfs stuurt
deze gegevens via de UML-geëmuleerde seriële poort, die veel minder efficiënt is dan die van KVM
virtio-serieel.

· UML mist enkele functies (bijv. qcow2-ondersteuning), dus het kan zijn dat het helemaal niet van toepassing is.

Voor enkele actuele cijfers, zie:
http://rwmj.wordpress.com/2013/08/14/performance-of-user-mode-linux-as-a-libguestfs-backend/#blij

PROBLEMEN OPLOSSEN ARM PRESTATIES

Verzekeren hardware virtualisatie is Beschikbaar
Te gebruiken / proc / cpuinfo en deze pagina:

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

om ervoor te zorgen dat hardwarevirtualisatie beschikbaar is. Houd er rekening mee dat u het mogelijk moet inschakelen
in uw BIOS.

Hardwarevirt is meestal niet beschikbaar binnen VM's, en libguestfs zullen binnen langzaam werken
een andere virtuele machine, wat je ook doet. Geneste virtualisatie werkt niet goed in onze
ervaring, en is zeker geen vervanging voor het draaien van libguestfs op baremetal.

Verzekeren KVM is Beschikbaar
Zorg ervoor dat KVM is ingeschakeld en beschikbaar is voor de gebruiker die libguestfs zal uitvoeren. Het zou moeten
wees veilig om 0666-machtigingen in te stellen /dev/kvm en de meeste distributies doen dit nu.

Processoren naar vermijd
Vermijd processors die geen hardwarevirtualisatie hebben, en sommige processors die:
gewoon erg traag (AMD Geode is een goed voorbeeld).

Xen dom0
In Xen is dom0 een virtuele machine, dus hardwarevirtualisatie is niet beschikbaar.

GEDETAILLEERD TIJDEN GEBRUIK MAKEND VAN TS

Gebruik de ts(1) opdracht (van moreutils) om gedetailleerde timings weer te geven:

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

De tijdstempels zijn seconden (incrementeel sinds de vorige regel).

GEDETAILLEERD TIJDEN GEBRUIK MAKEND VAN SYSTEEMTAP

U kunt SystemTap (nietje(1)) om gedetailleerde timings van libguestfs-programma's te krijgen.

Sla het volgende script op als tijd.stap:

globale laatste;

functie display_time () {
nu = gettimeofday_us ();
delta = 0;
als (laatste > 0)
delta = nu - laatste;
laatste = nu;

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

sonde beginnen {
laatste = 0;
printf ("klaar\n");
}

/* Toon alle oproepen naar statische markeringen. */
sondeproces ("/ Usr / lib*/libguestfs.so.0")
.provider("guestfs").mark("*") ? {
weergave_tijd();
printf ("\t%s %s\n", $$name, $$parms);
}

/* Toon alle oproepen naar guestfs_* functies. */
sondeproces ("/ Usr / lib*/libguestfs.so.0")
.function("guestfs_[az]*") ? {
weergave_tijd();
printf ("\t%s %s\n", probefunc(), $$parms);
}

Voer het uit als root in één venster:

# stap tijd.stap
klaar

Het drukt "klaar" af wanneer SystemTap het programma heeft geladen. Voer uw libguestfs-programma uit,
guestfish of een virtuele tool in een ander venster. Bijvoorbeeld:

$ guestfish -een /dev/null run

In het stapvenster ziet u een grote hoeveelheid uitvoer, met de tijd die voor elke uitvoer nodig is
stap getoond (microseconden tussen haakjes). Bijvoorbeeld:

xxxx (+0): gastfs_create
xxxx (+29): guestfs_set_pgroep g=0x17a9de0 pgroep=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): lancering_start
[Etc.]

U moet de broncode raadplegen en zelfs wijzigen om libguestfs volledig te begrijpen
het resultaat.

GEDETAILLEERD DEBUGEN GEBRUIK MAKEND VAN GDB

U kunt verbinding maken met de BIOS/kernel van het apparaat met behulp van gdb. Als je weet wat je doet,
dit kan een handige manier zijn om opstartregressies te diagnosticeren.

Ten eerste moet je qemu wijzigen zodat het werkt met de "-S" en "-s" opties. Deze opties
ervoor zorgen dat qemu pauzeert bij het opstarten en je toestaat een debugger toe te voegen. Lezen qemu(1) voor verder
informatie. Libguestfs roept qemu meerdere keren aan (om de help-output te scannen, enzovoort)
en je wilt alleen dat de laatste aanroep van qemu deze opties gebruikt, dus gebruik een qemu-wrapper
script als dit:

#!/ bin / bash -

# Stel dit in om naar het echte qemu-binaire bestand te wijzen.
qemu=/usr/bin/qemu-kvm

if [ "$1" != "-global" ]; dan
# Scanhulpuitvoer enz.
exec $qemu "$@"
anders
# Echt qemu rennen.
exec $qemu -S -s "$@"
fi

Voer nu guestfish of een ander libguestfs-tool uit met de qemu-wrapper (zie "QEMU WRAPPERS" in
gastfs(3) om te begrijpen wat dit doet):

LIBGUESTFS_HV=/pad/naar/qemu-wrapper guestfish -a /dev/null -v run

Dit zou moeten pauzeren net nadat qemu is gestart. Koppel in een ander venster aan qemu met gdb:

$ gdb
(gdb) architectuur instellen i8086
De doelarchitectuur wordt verondersteld i8086 . te zijn
(gdb) doel afstandsbediening: 1234
Foutopsporing op afstand met :1234
0x0000fff0 in ?? ()
(gdb) vervolg

Op dit punt kunt u standaard gdb-technieken gebruiken, bijv. op "^C" drukken om het opstarten te onderbreken
en "bt" een stacktracering krijgen, breekpunten instellen, enz. Merk op dat wanneer u voorbij de . bent
BIOS en in de Linux-kernel, je zult de architectuur terug willen veranderen naar 32 of 64
beetje.

Gebruik guestfs-performance online met onworks.net-services