Gravações lentas para VM no Xen?

2

Eu tenho um servidor rodando o Xen e algumas VMs. Estou tentando configurar uma matriz RAID dedicada a uma das VMs em particular, que será usada para várias finalidades intensivas de armazenamento. Atualmente, estou tendo uma queda de desempenho muito estranha ao escrever a partir do domU, que é um convidado de PV do Debian com bastante vcpus e memória.

Neste momento, a configuração é que eu tenho três discos rígidos WD Red de 3 TB dispostos em um array RAID 5 (software) no dom0. Atualmente, o dom0 está expondo o bloco /dev/mdX como /dev/xvdb na máquina virtual (a VM possui /dev/xvda de um volume LVM). O bit relevante da configuração xen:

disk = [ <LVM stuff for xvda>, 'phy:/dev/md0,xvdb,w' ]

O /dev/md0 tem um sistema de arquivos ext4, com as opções noatime, nodiratime em uso. Quando eu faço um teste de velocidade no sistema de arquivos do domU, recebo algo assim:

# dd if=/dev/zero of=a_file bs=1M count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 16.2694 s, 66.0 MB/s
# dd if=some_other_noncached_file of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 26.379 s, 163 MB/s

No entanto, no dom0, recebo:

# dd if=/dev/zero of=a_file_somewhere bs=1M count=1024 conv=fsync
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 6.80677 s, 158 MB/s

... que, claramente, é uma diferença de velocidade muito grande. Enquanto 66 MB / s deve ser bom o suficiente por enquanto, eu realmente aprecio se alguém pode chegar a uma explicação para o porquê eu estou perdendo 60% do meu desempenho de gravação? Eu estaria expectante de 10% ou mais, mas não 60%.

Não é a fome de recursos dom0, porque eu tenho dado a ela significativamente mais recursos do que deveria requerer e o problema ainda ocorre. Também não é fome de recursos domU, e eu prevei CPUs para ficarem no mesmo nó NUMA, e a mesma coisa resulta.

Veja algumas coisas possivelmente relevantes de xl info :

host                   : <hostname>
release                : 3.16.0-4-amd64
version                : #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04)
machine                : x86_64
nr_cpus                : 24
max_cpu_id             : 63
nr_nodes               : 2
cores_per_socket       : 6
threads_per_core       : 2
cpu_mhz                : 2660
hw_caps                : bfebfbff:2c100800:00000000:00003f00:029ee3ff:00000000:00000001:00000000
virt_caps              : hvm
total_memory           : 24573
free_memory            : 12011
sharing_freed_memory   : 0
sharing_used_memory    : 0
outstanding_claims     : 0
free_cpus              : 0
xen_major              : 4
xen_minor              : 4
xen_extra              : .1
xen_version            : 4.4.1
xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 
xen_scheduler          : credit
xen_pagesize           : 4096
platform_params        : virt_start=0xffff800000000000
xen_changeset          : 
xen_commandline        : placeholder dom0_mem=8192M dom0_max_vcpus=8 dom0_vcpus_pin
cc_compiler            : gcc (Debian 4.9.2-10) 4.9.2
cc_compile_by          : ultrotter
cc_compile_domain      : debian.org
cc_compile_date        : Thu Jun 11 18:24:17 EEST 2015
xend_config_format     : 4

Se houver mais alguma coisa que possa ser útil, avise-nos e atualizarei a pergunta.

Obrigado!

    
por Ethereal 02.09.2015 / 21:30

2 respostas

1

Mais algumas investigações revelaram que esse não é um problema exclusivo (veja, por exemplo, o link ). Seguindo algumas sugestões, uma investigação mais aprofundada com iostat mostrou que o tamanho médio de gravação no domU estava abaixo de 128KiB, enquanto no dom0 era de aproximadamente 512KiB (encontrado dividindo wkB/s / w/s ).

Alguns pesquisaram o fato de que esse é um problema conhecido, com um patch enviado em dezembro para "consertar" o problema aumentando o valor padrão do parâmetro do módulo do kernel xen_blkfront.max de 32 para 128. Substituindo o valor padrão eu mesmo (na configuração do GRUB para a VM), a velocidade de gravação na domU saltou de cerca de 65 MiB / s para cerca de 115 MiB / s, o que é o suficiente de um bônus que eu não vou procurar muito mais.

Então, enquanto ainda há mais território para cobrir (de 115 MiB / s para a velocidade dom0 de 150 MiB / s), a maior parte chata foi corrigida, então estou marcando isso como a solução (quando possível) . Eu atualizarei com mais ajustes ou algo que eu ache que forneça um impacto significativo.

    
por 03.09.2015 / 05:20
1

Eu já vi quase o desempenho do disco nativo com PV guests, com o trabalho do MD sendo feito nos níveis dom0 e domU.

Se puder, tente configurar o convidado como paravirtualizado (PV) em vez de uma máquina virtual de hardware (HVM).

Além disso, para PV ou HVM, tente atribuir as unidades inteiras ao convidado e fazer com que ele manipule o material RAID (MD).

Veja o que funciona melhor para você.

    
por 03.09.2015 / 03:11

Tags