guestfs-performance - Online na nuvem

PROGRAMA:

NOME

guestfs-performance - libguestfs de engenharia para melhor desempenho

DESCRIÇÃO

Esta página documenta como obter o melhor desempenho de libguestfs, especialmente quando
você espera usar libguestfs para manipular milhares de máquinas virtuais ou imagens de disco.

Três áreas principais são cobertas. Libguestfs executa um aparelho (uma pequena distribuição Linux)
dentro do qemu / KVM. As duas primeiras áreas são: minimizar o tempo necessário para iniciar este
aparelho, e o número de vezes que o aparelho deve ser iniciado. A terceira área é
encurtando o tempo necessário para a inspeção de VMs.

LINHA DE BASE MEDIÇÕES

Antes de fazer alterações em como você usa libguestfs, faça medições de linha de base.

Linha de base: Comece que o utensílio
Em uma máquina descarregada, cronometrar quanto tempo leva para inicializar o aparelho:

tempo guestfish -a / dev / null run

Execute este comando várias vezes seguidas e descarte as primeiras execuções, para que você seja
medindo um caso típico de "cache quente".

Explicação

Este comando inicia o dispositivo libguestfs em um disco nulo e, em seguida, fecha imediatamente
para baixo. Na primeira vez que você executar o comando, ele criará um dispositivo e o armazenará em cache
(geralmente sob /var/tmp/.guestfs-*) As execuções subsequentes devem reutilizar o dispositivo em cache.

Esperado resultados

Você deve esperar tempos de menos de 6 segundos. Se as vezes que você vê em um
máquina descarregada estão acima disso, consulte a seção "RESOLUÇÃO DE PROBLEMAS DE DESEMPENHO FRACO"
abaixo.

Linha de base: Executando inspeção of a convidado
Para este teste, você precisará de uma máquina descarregada e pelo menos um convidado real ou imagem de disco.
Se você está planejando usar libguestfs apenas contra convidados X (por exemplo, X = Windows), use
um convidado X aqui seria mais apropriado. Se você está planejando executar libguestfs contra
uma mistura de convidados e, em seguida, use uma mistura de convidados para testar aqui.

Tempo quanto tempo leva para realizar a inspeção e montar os discos do convidado. Use o
primeiro comando se você for usar imagens de disco, e o segundo comando se você for
usando libvirt.

tempo guestfish --ro -a disk.img -i sair

tempo guestfish --ro -d GuestName -i sair

Execute o comando várias vezes em uma linha e descarte as primeiras execuções, para que você seja
medindo um caso típico de "cache quente".

Explicação

Este comando inicia o dispositivo libguestfs na imagem de disco nomeada ou libvirt guest,
executa a inspeção libguestfs nele (veja "INSPEÇÃO" em convidados(3)), monta o convidado
discos, descarta todos esses resultados e desliga.

Na primeira vez que você executar o comando, ele criará um dispositivo e o armazenará em cache (geralmente
para /var/tmp/.guestfs-*) As execuções subsequentes devem reutilizar o dispositivo em cache.

Esperado resultados

Você deve esperar tempos ≤ 5 segundos maiores do que os medidos na primeira linha de base
teste acima. (Por exemplo, se o primeiro teste de linha de base foi executado em 5 segundos, então este teste
deve ser executado em ≤ 10 segundos).

COMPREENSÃO A UTENSÍLIO E QUANDO IT IS CONSTRUÍDO / CACHEADO

Na primeira vez que você usar libguestfs, ele criará e armazenará em cache um dispositivo. Isso geralmente é
in /var/tmp/.guestfs-*, a menos que você tenha definido $ TMPDIR ou $ LIBGUESTFS_CACHEDIR, caso em que
ele estará sob esse diretório temporário.

Para obter mais informações sobre como o aparelho é construído, consulte "APARELHOS DE SUPERMINA" em
superminuto(1).

Cada vez que o libguestfs é executado, ele verifica se nenhum arquivo host usado pelo aparelho tem
mudado. Se houver, o aparelho foi reconstruído. Isso geralmente acontece quando um pacote
é instalado ou atualizado no host (por exemplo, usando programas como "yum" ou "apt-get"). o
razão para reconstruir o aparelho é a segurança: o novo programa que foi
instalado pode conter uma correção de segurança e, portanto, queremos incluir o programa corrigido no
aparelho automaticamente.

Estas são as implicações de desempenho:

· O processo de construção (ou reconstrução) do dispositivo em cache é lento e você pode
evite que isso aconteça usando um aparelho fixo (veja abaixo).

· Se não estiver usando um aparelho fixo, esteja ciente de que atualizar o software no host causará
uma reconstrução única do aparelho.

· / var / tmp (ou $ TMPDIR, $ LIBGUESTFS_CACHEDIR) deve estar em um disco rápido e ter bastante
de espaço para o aparelho.

USANDO A FIXO UTENSÍLIO

Para controlar totalmente quando o aparelho é construído, você pode construir um aparelho fixo. Esse
aparelho deve ser armazenado em um disco local rápido.

Para construir o aparelho, execute o comando:

libguestfs-make-fixed-appliance

substituindo " "com o nome de um diretório onde o aparelho será armazenado
(normalmente você nomearia um subdiretório, por exemplo: / usr / local / lib / guestfs / appliance or
/ dev / shm / appliance).

Em seguida, defina $ LIBGUESTFS_PATH (e certifique-se de que esta variável de ambiente está definida em seu libguestfs
programa) ou modifique seu programa para que ele chame "guestfs_set_path". Por exemplo:

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

Agora você pode executar programas libguestfs, ferramentas virt, guestfish etc. normalmente. Os programas
usará seu dispositivo fixo e nunca criará, reconstruirá ou armazenará em cache o seu próprio
aparelho.

(Para obter informações detalhadas sobre este assunto, consulte: libguestfs-make-fixed-appliance(1)).

Performance of que o fixado utensílio
Em nossos testes, não descobrimos que o uso de um aparelho fixo forneceu qualquer
benefício de desempenho, mesmo quando o dispositivo estava localizado na memória (ou seja, ligado / dev / shm).
No entanto, existem dois pontos a serem considerados:

1. Usar um dispositivo fixo impede que libguestfs reconstrua o dispositivo, o que significa
que libguestfs terá tempos de inicialização mais previsíveis.

2. O aparelho é carregado sob demanda. Um teste simples como:

tempo guestfish -a / dev / null run

não carrega muito o aparelho. Um programa libguestfs real usando complicado
As chamadas de API exigiriam muito mais do dispositivo. Ser capaz de armazenar o
dispositivo em um local especificado torna o desempenho mais previsível.

REDUZINDO A NÚMERO OF TEMPOS A UTENSÍLIO IS LANÇADO

De longe o mais eficaz, embora nem sempre a maneira mais simples de obter um bom desempenho seja
para garantir que o aparelho seja iniciado o número mínimo de vezes. Isso provavelmente
envolve a mudança de seu aplicativo libguestfs.

Tente chamar "guestfs_launch" no máximo uma vez por máquina virtual alvo ou imagem de disco.

Em vez de usar uma instância separada de peixe convidado(1) para fazer uma série de mudanças no
mesmo convidado, use uma única instância de guestfish e / ou use o guestfish --ouço opção.

Considere escrever seu programa como um daemon que mantém um convidado aberto enquanto faz uma série
de mudanças. Ou marque todas as operações que deseja realizar antes de abrir o convidado.

Você também pode tentar adicionar discos de vários convidados a um único dispositivo. Antes de tentar
isso, observe os seguintes pontos:

1. Adicionar vários convidados a um dispositivo é um problema de segurança porque pode permitir um
convidado para interferir com os discos de outro convidado. Só faça isso se você confiar em todos os
convidados, ou se você pode agrupar convidados por confiança.

2. Há um limite rígido para o número de discos que você pode adicionar a um único dispositivo. Ligar
"guestfs_max_disks" em convidados(3) para obter esse limite. Para mais informações veja
"LIMITS" em convidados(3).

3. Usar libguestfs dessa forma é complicado. Os discos podem ter interações inesperadas: para
exemplo, se dois convidados usam o mesmo UUID para um sistema de arquivos (porque foram clonados),
ou ter grupos de volumes com o mesmo nome (mas consulte "guestfs_lvm_set_filter").

virt-df(1) adiciona vários discos por padrão, então o código-fonte para este programa seria um
bom lugar para começar.

ENCURTANDO A TIME OCUPADO PARA INSPEÇÃO OF VMs

O conselho principal é óbvio: não faça inspeção (que é cara) a menos que você precise
os resultados.

Se você já realizou inspeção no convidado, pode ser seguro armazenar em cache e
reutilize os resultados da última vez.

Alguns discos não precisam ser inspecionados: por exemplo, se você estiver criando um disco
imagem, ou se a imagem do disco não é uma VM, ou se a imagem do disco tem um layout conhecido.

Mesmo quando a inspeção básica ("guestfs_inspect_os") é necessária, inspeção auxiliar
operações podem ser evitadas:

· A montagem de discos só é necessária para obter mais informações sobre o sistema de arquivos.

· Listar aplicativos ("guestfs_inspect_list_applications") é uma operação cara
no Linux, mas quase gratuito no Windows.

· Gerar um ícone de convidado ("guestfs_inspect_get_icon") é barato no Linux, mas caro
no Windows.

PARALELO APARELHOS

Os dispositivos Libguestfs são principalmente ligados a E / S e você pode iniciar vários dispositivos em
paralelo. Desde que haja memória livre suficiente, deve haver pouca diferença no
lançando 1 dispositivo vs N dispositivos em paralelo.

Em um laptop de 2 núcleos (4 threads) com 16 GB de RAM, usando o teste (não especialmente realista)
Script Perl abaixo, o gráfico a seguir mostra excelente escalabilidade quando executado entre 1
e 20 aparelhos em paralelo:

12 ++ --- + ---- + ---- + ---- + ----- + ---- + ---- + ---- + ---- + - - ++
+ + + + + + + + + + + *
| |
| * |
11++++
| |
| |
| * * |
10++++
| * |
| |
e | |
9++++
e | |
| * |
c | |
8++*++
o | * |
| |
n7++++
| * |
e | * |
| |
s6 ++ ++
| * * |
| * |
| |
5++++
| |
| * |
| * * |
4++++
| |
| |
+ * * * + + + + + + + + +
3 ++ - * - + ---- + ---- + ---- + ----- + ---- + ---- + ---- + ---- + - - ++
0 2 4 6 8 10 12 14 16 18 20
número de aparelhos paralelos

É possível executar muitos mais de 20 aparelhos em paralelo, mas se você estiver usando o
backend da libvirt, então você deve estar ciente de que, fora da caixa, a libvirt limita o número de
conexões de cliente para 20.

O script Perl simples abaixo foi usado para coletar os dados para o gráfico acima, mas há
muito mais informações sobre este assunto, incluindo scripts de teste e gráficos mais avançados,
disponível nas seguintes postagens de 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

use estrito;
usar fios;
use avisos;
use Sys :: Guestfs;
use Time :: HiRes qw (time);

subteste {
meu $ g = Sys :: Guestfs-> novo;
$ g-> add_drive_ro ("/ dev / null");
$ g-> lançar ();

# Você poderia adicionar algum trabalho para libguestfs fazer aqui.

$ g-> close ();
}

# Coloque tudo no cache.
teste (); teste (); teste ();

para meus $ nr_threads (1..20) {
meu $ start_t = time ();
meus @threads;
foreach (1 .. $ nr_threads) {
push @threads, threads-> criar (\ & teste)
}
foreach (@threads) {
$ _-> join ();
if (meu $ err = $ _-> erro ()) {
die "lançamento falhou com $ nr_threads threads: $ err"
}
}
meu $ end_t = tempo ();
printf ("% d% .2f \ n", $ nr_threads, $ end_t - $ start_t);
}

USANDO MODO DE USUÁRIO LINUX

Desde libguestfs 1.24, é possível usar o backend do User-Mode Linux (uml)
em vez de KVM (ver "BACKEND LINUX DO MODO DE USUÁRIO" em convidados(3)). Esta seção faz alguns
comentários gerais sobre este back-end, mas é altamente aconselhável para medir o seu próprio
carga de trabalho em UML, em vez de confiar em comentários ou intuição.

· UML geralmente executa o mesmo ou ligeiramente mais lento do que KVM, no baremetal.

· No entanto, UML frequentemente executa o mesmo na virtualização e no baremetal,
enquanto o KVM pode ser executado muito mais devagar na virtualização (uma vez que a aceleração de virtualização de hardware
não está disponível).

· Upload e download são 10 vezes mais lentos em UML do que em KVM. Libguestfs envia
esses dados sobre a porta serial emulada UML, que é muito menos eficiente do que o KVM
virtio-serial.

· UML carece de alguns recursos (por exemplo, suporte a qcow2), portanto, pode não ser aplicável de forma alguma.

Para alguns números reais, consulte:
http://rwmj.wordpress.com/2013/08/14/performance-of-user-mode-linux-as-a-libguestfs-backend/# Content

PROBLEMAS POBRE PERFORMANCE

Garantir Hardwares virtualização is disponível
Use / proc / cpuinfo e esta página:

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

para garantir que a virtualização de hardware esteja disponível. Observe que pode ser necessário habilitá-lo
em sua BIOS.

Hardware virt não está geralmente disponível dentro de VMs, e libguestfs será executado lentamente dentro
outra máquina virtual, faça o que fizer. A virtualização aninhada não funciona bem em nosso
experiência e certamente não é um substituto para a execução de libguestfs no baremetal.

Garantir KVM is disponível
Certifique-se de que o KVM esteja habilitado e disponível para o usuário que executará libguestfs. Deveria
esteja seguro definir as permissões 0666 em / dev / kvm e a maioria das distribuições agora faz isso.

Processadores para evitar
Evite processadores que não têm virtualização de hardware e alguns processadores que são
simplesmente muito lento (AMD Geode é um ótimo exemplo).

Xen dom0
No Xen, dom0 é uma máquina virtual e, portanto, a virtualização de hardware não está disponível.

DETALHADO TEMPOS USANDO TS

Use o ts(1) comando (de moreutils) para mostrar tempos detalhados:

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

Os carimbos de data / hora são segundos (incrementalmente desde a linha anterior).

DETALHADO TEMPOS USANDO SYSTEMTAP

Você pode usar o SystemTap (stap(1)) para obter tempos detalhados de programas libguestfs.

Salve o seguinte script como hora.stap:

último global;

função display_time() {
agora = gettimeofday_us ();
delta = 0;
se (último> 0)
delta = agora - último;
último = agora;

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

início da sonda {
último = 0;
printf ("pronto \ n");
}

/ * Exibir todas as chamadas para marcadores estáticos. * /
processo de sondagem ("/ usr / lib* / libguestfs.so.0 ")
.provider ("guestfs"). mark ("*")? {
tempo de exibição();
printf ("\ t% s% s \ n", $$ nome, $$ parms);
}

/ * Exibir todas as chamadas para funções guestfs_ *. * /
processo de sondagem ("/ usr / lib* / libguestfs.so.0 ")
.function ("guestfs_ [az] *")? {
tempo de exibição();
printf ("\ t% s% s \ n", probefunc (), $$ parms);
}

Execute-o como root em uma janela:

#stap time.stap
pronto

Ele imprime "pronto" quando o SystemTap carrega o programa. Execute seu programa libguestfs,
guestfish ou uma ferramenta virt em outra janela. Por exemplo:

$ guestfish -a / dev / null run

Na janela stap, você verá uma grande quantidade de saída, com o tempo gasto para cada
etapa mostrada (microssegundos entre parênteses). Por exemplo:

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): lançamento_início
[etc]

Você precisará consultar, e até mesmo modificar, o código-fonte do libguestfs para entender completamente
a saída.

DETALHADO DEPURAÇÃO USANDO GDB

Você pode conectar ao BIOS / kernel do dispositivo usando gdb. Se você sabe o que está fazendo,
essa pode ser uma maneira útil de diagnosticar regressões de inicialização.

Em primeiro lugar, você deve alterar o qemu para que ele seja executado com as opções "-S" e "-s". Essas opções
faz com que o qemu pause na inicialização e permite que você conecte um depurador. Leitura qemu(1) para mais
em formação. Libguestfs invoca qemu várias vezes (para verificar a saída de ajuda e assim por diante)
e você só quer a invocação final do qemu para usar essas opções, então use um invólucro qemu
script como este:

#!/ bin / bash -

# Defina para apontar para o binário qemu real.
qemu = / usr / bin / qemu-kvm

if ["$ 1"! = "-global"]; então
# Digitalização de saída de ajuda, etc.
exec $ qemu "$ @"
outro
# Realmente executando o qemu.
exec $ qemu -S -s "$ @"
fi

Agora execute guestfish ou outra ferramenta libguestfs com o invólucro qemu (veja "QEMU WRAPPERS" em
convidados(3) para entender o que isso está fazendo):

LIBGUESTFS_HV = / caminho / para / qemu-wrapper guestfish -a / dev / null -v run

Isso deve pausar logo após o lançamento do qemu. Em outra janela, anexe ao qemu usando gdb:

$ gdb
(gdb) definir arquitetura i8086
A arquitetura de destino é considerada i8086
(gdb) remoto de destino: 1234
Depuração remota usando: 1234
0x0000fff0 em ?? ()
(gdb) continua

Neste ponto, você pode usar técnicas padrão do gdb, por exemplo. pressionando "^ C" para interromper a inicialização
e "bt" obtém um rastreamento de pilha, definindo pontos de interrupção, etc. Observe que quando você tiver passado do
BIOS e no kernel do Linux, você vai querer mudar a arquitetura de volta para 32 ou 64
pouco.

Use guestfs-performance online usando serviços onworks.net