guestfs-performance - En ligne dans le Cloud

PROGRAMME:

Nom

guestfs-performance - ingénierie de libguestfs pour des performances optimales

DESCRIPTION

Cette page documente comment obtenir les meilleures performances de libguestfs, en particulier lorsque
vous vous attendez à utiliser libguestfs pour manipuler des milliers de machines virtuelles ou d'images disque.

Trois domaines principaux sont couverts. Libguestfs exécute une appliance (une petite distribution Linux)
à l'intérieur de qemu/KVM. Les deux premiers domaines sont : minimiser le temps nécessaire pour démarrer ce
l'appareil et le nombre de fois que l'appareil doit être démarré. Le troisième domaine est
raccourcir le temps nécessaire pour l'inspection des machines virtuelles.

RÉFÉRENCE MESURES

Avant d'apporter des modifications à la façon dont vous utilisez libguestfs, prenez des mesures de base.

Référence: Commencez le appareil
Sur une machine déchargée, chronométrez le temps qu'il faut pour démarrer l'appareil :

heure guestfish -a /dev/null run

Exécutez cette commande plusieurs fois de suite et supprimez les premières exécutions, afin que vous soyez
mesurer un cas typique de "cache chaude".

Explication

Cette commande démarre l'appliance libguestfs sur un disque nul, puis s'arrête immédiatement
il vers le bas. La première fois que vous exécutez la commande, elle crée une appliance et la met en cache
(généralement sous /var/tmp/.guestfs-*). Les exécutions suivantes doivent réutiliser l'appliance mise en cache.

Attendu résultats

Vous devriez vous attendre à obtenir des temps inférieurs à 6 secondes. Si les heures que vous voyez sur un
machine déchargée sont au-dessus de cela, puis voir la section "DÉPANNAGE DE MAUVAISE PERFORMANCE"
ci-dessous.

Référence: Exécution inspection of a invité
Pour ce test, vous aurez besoin d'une machine déchargée et d'au moins un véritable invité ou une image disque.
Si vous prévoyez d'utiliser libguestfs contre X invités uniquement (par exemple X = Windows), utilisez
un invité X ici serait le plus approprié. Si vous prévoyez d'exécuter libguestfs contre
un mélange d'invités, puis utilisez un mélange d'invités pour tester ici.

Chronométrez le temps qu'il faut pour effectuer l'inspection et monter les disques de l'invité. Utilisez le
première commande si vous utiliserez des images disque, et la deuxième commande si vous serez
en utilisant libvirt.

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

heure guestfish --ro -d NomInvité -i exit

Exécutez la commande plusieurs fois de suite et supprimez les premières exécutions, de sorte que vous soyez
mesurer un cas typique de "cache chaude".

Explication

Cette commande démarre l'appliance libguestfs sur l'image disque ou l'invité libvirt nommé,
effectue une inspection libguestfs dessus (voir "INSPECTION" dans invités(3)), monte l'invité
disques, puis supprime tous ces résultats et s'arrête.

La première fois que vous exécutez la commande, elle crée une appliance et la met en cache (généralement
sous /var/tmp/.guestfs-*). Les exécutions suivantes doivent réutiliser l'appliance mise en cache.

Attendu résultats

Vous devez vous attendre à des temps supérieurs de ≤ 5 secondes à ceux mesurés dans la première ligne de base
essai ci-dessus. (Par exemple, si le premier test de référence s'est exécuté en 5 secondes, ce test
devrait fonctionner en ≤ 10 secondes).

COMPRÉHENSION LES APPAREIL ET QUAND IT IS CONSTRUIT/CACHÉ

La première fois que vous utilisez libguestfs, il construira et mettra en cache une appliance. C'est généralement
in /var/tmp/.guestfs-*, sauf si vous avez défini $TMPDIR ou $LIBGUESTFS_CACHEDIR auquel cas
ce sera sous ce répertoire temporaire.

Pour plus d'informations sur la façon dont l'appareil est construit, voir « APPAREILS SUPERMIN » dans
supermine (1).

Chaque fois que libguestfs s'exécute, il vérifie qu'aucun fichier hôte utilisé par l'appliance n'a
modifié. Le cas échéant, l'appareil est reconstruit. Cela se produit généralement lorsqu'un paquet
est installé ou mis à jour sur l'hôte (par exemple, en utilisant des programmes comme "yum" ou "apt-get"). Les
raison de la reconstruction de l'appareil est la sécurité : le nouveau programme qui a été
installé peut contenir un correctif de sécurité, et nous voulons donc inclure le programme corrigé dans le
l'appareil automatiquement.

Voici les implications sur les performances :

· Le processus de création (ou de reconstruction) de l'appliance mise en cache est lent et vous pouvez
évitez cela en utilisant un appareil fixe (voir ci-dessous).

· Si vous n'utilisez pas d'appliance fixe, sachez que la mise à jour du logiciel sur l'hôte entraînera
une reconstruction unique de l'appareil.

· / Var / tmp (ou $TMPDIR, $LIBGUESTFS_CACHEDIR) doit être sur un disque rapide et avoir beaucoup
d'espace pour l'appareil.

EN UTILISANT A FIXE APPAREIL

Pour contrôler totalement le moment où l'appareil est construit, vous pouvez construire un appareil fixe. Cette
l'appliance doit être stockée sur un disque local rapide.

Pour créer l'appliance, exécutez la commande :

libguestfs-make-fixed-appliance

remplaçant " " avec le nom d'un répertoire où sera stocké l'appareil
(normalement, vous nommeriez un sous-répertoire, par exemple : /usr/local/lib/guestfs/appliance or
/dev/shm/appliance).

Ensuite, définissez $LIBGUESTFS_PATH (et assurez-vous que cette variable d'environnement est définie dans votre libguestfs
programme), ou modifiez votre programme pour qu'il appelle "guestfs_set_path". Par exemple:

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

Vous pouvez maintenant exécuter les programmes libguestfs, les outils virt, guestfish, etc. normalement. Les programmes
utilisera votre appareil fixe et ne construira, reconstruira ou cachera jamais le leur
appareil.

(Pour des informations détaillées à ce sujet, voir : libguestfs-make-fixed-appliance(1)).

Performance of le fixé appareil
Lors de nos tests, nous n'avons pas trouvé que l'utilisation d'un appareil fixe donnait des résultats mesurables
amélioration des performances, même lorsque l'appliance était située en mémoire (c'est-à-dire sur / dev / shm).
Cependant, il y a deux points à considérer :

1. L'utilisation d'une appliance fixe empêche libguestfs de reconstruire l'appliance, ce qui signifie
que libguestfs aura des temps de démarrage plus prévisibles.

2. L'appareil est chargé à la demande. Un test simple tel que :

heure guestfish -a /dev/null run

ne charge pas beaucoup l'appareil. Un vrai programme libguestfs utilisant des
Les appels d'API solliciteraient beaucoup plus l'appliance. Pouvoir stocker le
l'appareil à un emplacement spécifié rend les performances plus prévisibles.

RÉDUIRE LES NUMÉRO OF TEMPS LES APPAREIL IS LANCÉ

De loin le moyen le plus efficace, mais pas toujours le plus simple, d'obtenir de bonnes performances est
pour s'assurer que l'appliance est lancée le nombre minimum de fois. Ce sera probablement
impliquer de changer votre application libguestfs.

Essayez d'appeler "guestfs_launch" au plus une fois par machine virtuelle ou image disque cible.

Au lieu d'utiliser une instance distincte de poisson invité(1) pour apporter une série de modifications à la
même invité, utilisez une seule instance de guestfish et/ou utilisez le guestfish --Ecoutez option.

Envisagez d'écrire votre programme sous la forme d'un démon qui garde un invité ouvert tout en faisant une série
de changements. Ou rassemblez toutes les opérations que vous souhaitez effectuer avant d'ouvrir l'invité.

Vous pouvez également essayer d'ajouter des disques de plusieurs invités à une seule appliance. Avant d'essayer
ceci, notez les points suivants :

1. L'ajout de plusieurs invités à un appareil est un problème de sécurité car il peut permettre à un
invité d'interférer avec les disques d'un autre invité. Ne le faites que si vous faites confiance à tous les
invités, ou si vous pouvez grouper des invités par confiance.

2. Il existe une limite stricte au nombre de disques que vous pouvez ajouter à une seule appliance. Appel
"guestfs_max_disks" dans invités(3) pour obtenir cette limite. Pour plus d'informations voir
"LIMITES" dans invités (3).

3. Utiliser libguestfs de cette manière est compliqué. Les disques peuvent avoir des interactions inattendues : pour
exemple, si deux invités utilisent le même UUID pour un système de fichiers (car ils ont été clonés),
ou avoir des groupes de volumes avec le même nom (mais voir "guestfs_lvm_set_filter").

virt-df(1) ajoute plusieurs disques par défaut, donc le code source de ce programme serait un
bon endroit pour commencer.

RACCOURCISSEMENT LES PRIS POUR INSPECTION OF VMs

Le conseil principal est évident : n'effectuez pas d'inspection (qui coûte cher) sauf si vous avez besoin
Les resultats.

Si vous avez déjà effectué une inspection sur l'invité, il peut être sûr de mettre en cache et
réutiliser les résultats de la dernière fois.

Certains disques n'ont pas du tout besoin d'être inspectés : par exemple, si vous créez un disque
image, ou si l'image disque n'est pas une machine virtuelle, ou si l'image disque a une disposition connue.

Même lorsqu'une inspection de base ("guestfs_inspect_os") est requise, une inspection auxiliaire
des opérations peuvent être évitées :

· Le montage de disques n'est nécessaire que pour obtenir des informations supplémentaires sur le système de fichiers.

· Lister les applications ("guestfs_inspect_list_applications") est une opération coûteuse
sous Linux, mais presque gratuit sous Windows.

· Générer une icône d'invité ("guestfs_inspect_get_icon") est bon marché sur Linux mais cher
sous Windows.

PARALLÈLE APPAREILS

Les appliances Libguestfs sont principalement liées aux E/S et vous pouvez lancer plusieurs appliances dans
parallèle. À condition qu'il y ait suffisamment de mémoire libre, il devrait y avoir peu de différence dans
lancement d'1 appliance vs N appliances en parallèle.

Sur un ordinateur portable à 2 cœurs (4 threads) avec 16 Go de RAM, en utilisant le test (pas spécialement réaliste)
Script Perl ci-dessous, le graphique suivant montre une excellente évolutivité lors de l'exécution entre 1
et 20 appareils en parallèle :

12 ++---+----+----+----+-----+----+----+----+----+-- -++
+ + + + + + + + + + + *
| |
| * |
11 ++ ++
| |
| |
| * * |
10 ++ ++
| * |
| |
s | |
9 ++ ++
e | |
| * |
c | |
8 ++ * ++
o | * |
| |
n 7 ++ ++
| * |
ré | * |
| |
6 ++ ++
| * * |
| * |
| |
5 ++ ++
| |
| * |
| * * |
4 ++ ++
| |
| |
+ * * * + + + + + + + + +
3 ++-*-+----+----+----+-----+----+----+----+----+-- -++
0 2 4 6 8 10 12 14 16 18 20
nombre d'appareils en parallèle

Il est possible d'exécuter plus de 20 appareils en parallèle, mais si vous utilisez le
libvirt backend, vous devez savoir que libvirt prêt à l'emploi limite le nombre de
connexions client à 20.

Le script Perl simple ci-dessous a été utilisé pour collecter les données pour le tracé ci-dessus, mais il y a
beaucoup plus d'informations sur ce sujet, y compris des scripts de test et des graphiques plus avancés,
disponible dans les articles de blog suivants :

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

utiliser strict;
utiliser des fils ;
utiliser des avertissements ;
utilisez Sys::Guestfs;
utiliser Time::HiRes qw(time);

sous-test {
mon $g = Sys::Guestfs->nouveau ;
$g->add_drive_ro ("/dev/null");
$g->lancer ();

# Vous pouvez ajouter du travail à libguestfs ici.

$g->fermer ();
}

# Mettez tout en cache.
test (); test (); test ();

pour mes $nr_threads (1..20) {
mon $start_t = heure ();
mes @threads ;
foreach (1..$nr_threads) {
push @threads, threads->créer (\&test)
}
foreach (@threads) {
$_->join ();
if (mon $err = $_->error ()) {
die "échec du lancement avec les threads $nr_threads : $err"
}
}
mon $end_t = heure ();
printf ("%d %.2f\n", $nr_threads, $end_t - $start_t);
}

EN UTILISANT MODE UTILISATEUR LINUX

Depuis libguestfs 1.24, il est possible d'utiliser le backend Linux en mode utilisateur (uml)
au lieu de KVM (voir "USER-MODE LINUX BACKEND" dans invités(3)). Cette section fait quelques
remarques générales sur ce backend, mais il est très conseillé pour mesurer le vôtre
charge de travail sous UML plutôt que de se fier aux commentaires ou à l'intuition.

· UML fonctionne généralement de la même manière ou légèrement plus lentement que KVM, sur baremetal.

· Cependant, UML effectue souvent la même chose sous virtualisation que sur baremetal,
alors que KVM peut fonctionner beaucoup plus lentement sous virtualisation (puisque l'accélération matérielle virt
n'est pas disponible).

· Le chargement et le téléchargement sont jusqu'à 10 fois plus lents sur UML que sur KVM. Libguestfs envoie
ces données sur le port série émulé UML, qui est beaucoup moins efficace que celui de KVM
virtio-série.

· UML manque de certaines fonctionnalités (par exemple, la prise en charge de qcow2), il peut donc ne pas être applicable du tout.

Pour quelques chiffres réels, voir:
http://rwmj.wordpress.com/2013/08/14/performance-of-user-mode-linux-as-a-libguestfs-backend/#contenu

DÉPANNAGE PAUVRES PERFORMANCE

Ensure matériel virtualisation is disponibles
Utilisez / proc / cpuinfo et cette page :

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

pour s'assurer que la virtualisation matérielle est disponible. Notez que vous devrez peut-être l'activer
dans votre BIOS.

Le matériel virt n'est généralement pas disponible dans les machines virtuelles, et libguestfs s'exécutera lentement à l'intérieur
une autre machine virtuelle quoi que vous fassiez. La virtualisation imbriquée ne fonctionne pas bien dans notre
expérience, et ne remplace certainement pas l'exécution de libguestfs sur baremetal.

Ensure KVM is disponibles
Assurez-vous que KVM est activé et disponible pour l'utilisateur qui exécutera libguestfs. Cela devrait
être sûr de définir les autorisations 0666 sur /dev/kvm et la plupart des distributions le font maintenant.

Processeurs à éviter
Évitez les processeurs qui n'ont pas de virtualisation matérielle et certains processeurs qui sont
tout simplement très lent (AMD Geode étant un excellent exemple).

Xen dom0
Dans Xen, dom0 est une machine virtuelle et la virtualisation matérielle n'est donc pas disponible.

DÉTAILLÉ Horaires EN UTILISANT TS

Utilisez l'option ts(1) commande (de moreutils) pour afficher les horaires détaillés :

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

Les horodatages sont des secondes (incrémentalement depuis la ligne précédente).

DÉTAILLÉ Horaires EN UTILISANT ACCÈS SYSTÈME

Vous pouvez utiliser SystemTap (étape(1)) pour obtenir les horaires détaillés des programmes libguestfs.

Enregistrez le script suivant sous heure.stap:

dernier mondial ;

fonction display_time () {
maintenant = gettimeofday_us ();
delta = 0 ;
si (dernier > 0)
delta = maintenant - dernier ;
dernier = maintenant ;

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

début de la sonde {
dernier = 0 ;
printf ("prêt\n");
}

/* Affiche tous les appels aux marqueurs statiques. */
processus de sonde("/ usr / lib*/libguestfs.so.0")
.provider("guestfs").mark("*") ? {
temps d'affichage();
printf ("\t%s %s\n", $$name, $$parms);
}

/* Affiche tous les appels aux fonctions guestfs_*. */
processus de sonde("/ usr / lib*/libguestfs.so.0")
.function("guestfs_[az]*") ? {
temps d'affichage();
printf ("\t%s %s\n", probefunc(), $$parms);
}

Exécutez-le en tant que root dans une fenêtre :

# heure d'étape.étape
solutions

Il affiche "prêt" lorsque SystemTap a chargé le programme. Exécutez votre programme libguestfs,
guestfish ou un outil virt dans une autre fenêtre. Par exemple:

$ guestfish -a /dev/null run

Dans la fenêtre stap, vous verrez une grande quantité de sortie, avec le temps pris pour chaque
pas affiché (microsecondes entre parenthèses). Par exemple:

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 noctets=0x38
xxxx (+5): guestfs_int_safe_strdup g=0x17a9de0 str=0x17a9f60
xxxx (+10) : guestfs_launch g=0x17a9de0
xxxx (+4) : launch_start
[etc]

Vous devrez consulter, et même modifier, le code source de libguestfs pour bien comprendre
le résultat.

DÉTAILLÉ DÉBOGAGE EN UTILISANT GDB

Vous pouvez vous connecter au BIOS/noyau de l'appliance à l'aide de gdb. Si vous savez ce que vous faites,
cela peut être un moyen utile de diagnostiquer les régressions de démarrage.

Tout d'abord, vous devez changer qemu pour qu'il s'exécute avec les options "-S" et "-s". Ces options
provoque la pause de qemu au démarrage et vous permet d'attacher un débogueur. Lire qemu(1) pour plus
informations. Libguestfs invoque qemu plusieurs fois (pour analyser la sortie de l'aide, etc.)
et vous voulez seulement que l'invocation finale de qemu utilise ces options, alors utilisez un wrapper qemu
script comme ceci :

#!/ bin / bash -

# Définissez ceci pour qu'il pointe vers le vrai binaire qemu.
qemu=/usr/bin/qemu-kvm

if [ "$1" != "-global" ]; alors
# Sortie d'aide à la numérisation, etc.
exec $qemu "$@"
d'autre
# Vraiment en cours d'exécution qemu.
exec $qemu -S -s "$@"
fi

Exécutez maintenant guestfish ou un autre outil libguestfs avec le wrapper qemu (voir "QEMU WRAPPERS" dans
invités(3) pour comprendre ce que cela fait):

LIBGUESTFS_HV=/chemin/vers/qemu-wrapper guestfish -a /dev/null -v run

Cela devrait s'arrêter juste après le lancement de qemu. Dans une autre fenêtre, attachez-vous à qemu à l'aide de gdb :

$gdb
(gdb) définir l'architecture i8086
L'architecture cible est supposée être i8086
(gdb) cible à distance : 1234
Débogage à distance en utilisant : 1234
0x0000fff0 dans ?? ()
(gdb) suite

À ce stade, vous pouvez utiliser des techniques gdb standard, par exemple. appuyer sur "^C" pour interrompre le démarrage
et "bt" obtiennent une trace de pile, définissant des points d'arrêt, etc. Notez que lorsque vous avez dépassé le
BIOS et dans le noyau Linux, vous voudrez changer l'architecture en 32 ou 64
bit.

Utilisez guestfs-performance en ligne à l'aide des services onworks.net