Qemu + libvirt + kvm atraso significativo de desempenho em VMs

3

Estou solucionando problemas de desempenho ruim em nossa nova máquina host de VM, que é um Dell PowerEdge R415 com hardware RAID.

Temos cerca de 20 VMs funcionando assim:

qemu-system-x86_64 \
  -enable-kvm \
  -name rc.stb.mezzanine -S \
  -machine pc-0.12,accel=kvm,usb=off \
  -m 2048 \
  -realtime mlock=off \
  -smp 2,sockets=2,cores=1,threads=1 \
  -uuid 493d519c-8bb5-2cf8-c037-1094a3c48a7a \
  -no-user-config \
  -nodefaults \
  -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rc.stb.monitor,server,nowait \
  -mon chardev=charmonitor,id=monitor,mode=control \
  -rtc base=utc \
  -no-shutdown \
  -boot strict=on \ 
  -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \
  -drive file=/dev/vg-raid/lv-rc,if=none,id=drive-virtio-disk0,format=raw \
  -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 \
  -drive file=/var/lib/libvirt/images/ubuntu-14.04-server-amd64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw \
  -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 \
  -netdev tap,fd=32,id=hostnet0 \
  -device e1000,netdev=hostnet0,id=net0,mac=52:54:df:26:15:e9,bus=pci.0,addr=0x3 \
  -chardev pty,id=charserial0 \
  -device isa-serial,chardev=charserial0,id=serial0 \
  -vnc 127.0.0.1:1 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 \
  -device ES1370,id=sound0,bus=pci.0,addr=0x4 \
  -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

O host da VM usa uma configuração LTS do Ubuntu 14.04 com uma interface de ponte na frente do libvirt + qemu.

O problema é basicamente que as VMs estão experimentando um "atraso" esporádico. É experimentado como sérios problemas de desempenho pelos usuários. Às vezes, dificilmente é notado, mas às vezes uma única VM pode ter dificuldades para responder ao ping no tempo, conforme mostrado abaixo (testado do host da VM para eliminar quaisquer problemas relacionados à rede).

root@vm-host-1:~# ping rc
PING rc (192.168.200.7) 56(84) bytes of data.
64 bytes from rc (192.168.200.7): icmp_seq=1 ttl=64 time=0.202 ms
64 bytes from rc (192.168.200.7): icmp_seq=2 ttl=64 time=0.214 ms
64 bytes from rc (192.168.200.7): icmp_seq=3 ttl=64 time=0.241 ms
64 bytes from rc (192.168.200.7): icmp_seq=4 ttl=64 time=0.276 ms
64 bytes from rc (192.168.200.7): icmp_seq=5 ttl=64 time=0.249 ms
64 bytes from rc (192.168.200.7): icmp_seq=6 ttl=64 time=0.228 ms
64 bytes from rc (192.168.200.7): icmp_seq=7 ttl=64 time=0.198 ms
64 bytes from rc (192.168.200.7): icmp_seq=8 ttl=64 time=3207 ms
64 bytes from rc (192.168.200.7): icmp_seq=9 ttl=64 time=2207 ms
64 bytes from rc (192.168.200.7): icmp_seq=10 ttl=64 time=1203 ms
64 bytes from rc (192.168.200.7): icmp_seq=11 ttl=64 time=203 ms
64 bytes from rc (192.168.200.7): icmp_seq=12 ttl=64 time=0.240 ms
64 bytes from rc (192.168.200.7): icmp_seq=13 ttl=64 time=0.271 ms
64 bytes from rc (192.168.200.7): icmp_seq=14 ttl=64 time=0.279 ms
^C
--- rc.mezzanine ping statistics ---
14 packets transmitted, 14 received, 0% packet loss, time 13007ms
rtt min/avg/max/mdev = 0.198/487.488/3207.376/975.558 ms, pipe 4

Os comandos locais executados nas respectivas VMs também são ocasionalmente lentos, por exemplo correr 'ls' pode levar uma fração de segundo, mas ocasionalmente leva um segundo ou dois. Claramente, algo não é saudável.

Eu tenho perseguido esse problema por vários dias. Os discos do host da VM são saudáveis e o uso de memória não é ruim, como pode ser visto em:

virt-top 10:24:10 - x86_64 12/12CPU 3000MHz 64401MB
20 domains, 20 active, 20 running, 0 sleeping, 0 paused, 0 inactive D:0 O:0 X:0
CPU: 0.0%  Mem: 28800 MB (28800 MB by guests)

e

root@vm-host-1:~# free -m
             total       used       free     shared    buffers     cached
Mem:         64401      57458       6943          0      32229        338
-/+ buffers/cache:      24889      39511
Swap:         7628        276       7352

Esse servidor é perfeitamente capaz de executar essa quantidade de VMs, especialmente considerando que elas não são VMs de carga alta - mas, principalmente, ociosas.

Qual é o procedimento para solucionar isso? Eu suspeito que uma das máquinas virtuais está se comportando mal, causando efeitos de ondulação que afetam todas as VMs, mas ainda tenho que determinar qual é a VM, devido às ocorrências esporádicas do problema.

O hardware host da VM por si só é perfeitamente saudável - e não gera problemas quando executado sem VMs, então suspeito que esse seja um problema do qemu / libvirt / kvm - talvez acionado por uma VM com comportamento inadequado.

Saída de slabtop:

 Active / Total Objects (% used)    : 17042162 / 17322929 (98.4%)
 Active / Total Slabs (% used)      : 365122 / 365122 (100.0%)
 Active / Total Caches (% used)     : 69 / 125 (55.2%)
 Active / Total Size (% used)       : 1616671.38K / 1677331.17K (96.4%)
 Minimum / Average / Maximum Object : 0.01K / 0.10K / 14.94K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
9326928 9219652  98%    0.10K 239152       39    956608K buffer_head
6821888 6821559  99%    0.06K 106592       64    426368K kmalloc-64
465375 369738  79%    0.05K   5475       85     21900K shared_policy_node
260689 230992  88%    0.55K   4577       57    146464K radix_tree_node
 65280  63353  97%    0.03K    510      128      2040K kmalloc-32
 46494  45631  98%    0.19K   1107       42      8856K dentry
 45936  23865  51%    0.96K   1392       33     44544K ext4_inode_cache
 44136  43827  99%    0.11K   1226       36      4904K sysfs_dir_cache
 29148  21588  74%    0.19K    694       42      5552K kmalloc-192
 22784  18513  81%    0.02K     89      256       356K kmalloc-16
 19890  19447  97%    0.04K    195      102       780K Acpi-Namespace
 19712  19320  98%    0.50K    616       32      9856K kmalloc-512
 16744  15338  91%    0.57K    299       56      9568K inode_cache
 16320  16015  98%    0.04K    160      102       640K ext4_extent_status
 15216  14690  96%    0.16K    317       48      2536K kvm_mmu_page_header
 12288  12288 100%    0.01K     24      512        96K kmalloc-8
 12160  11114  91%    0.06K    190       64       760K anon_vma
  7776   5722  73%    0.25K    244       32      1952K kmalloc-256
  7056   7056 100%    0.09K    168       42       672K kmalloc-96
  5920   4759  80%    0.12K    185       32       740K kmalloc-128
  5050   4757  94%    0.63K    101       50      3232K proc_inode_cache
  4940   4046  81%    0.30K     95       52      1520K nf_conntrack_ffffffff81cd9b00
  3852   3780  98%    0.11K    107       36       428K jbd2_journal_head
  3744   2911  77%    2.00K    234       16      7488K kmalloc-2048
  3696   3696 100%    0.07K     66       56       264K ext4_io_end
  3296   2975  90%    1.00K    103       32      3296K kmalloc-1024
    
por T.K. 08.06.2015 / 10:31

2 respostas

1

Nós mergulhámos no mesmo problema.

Causada pelo kernel do Ubuntu 14.04 bug .

Solução # 1: Atualize o Kernel para 3.13.0-33.58 (ou mais recente)

Solução # 2: Desative o KSM

    
por 24.03.2016 / 08:52
3

-device e1000,netdev=hostnet0

Isso. Mude para o virtio_net antes de tentar qualquer outra coisa.

segunda etapa: tente jogar com as configurações de descarga do NIC usando ethtool -K , desative o TSO, LSO, LRO, veja se obtém resultados diferentes.

etapa três: experimente uma distro diferente. O Ubuntu é notório pelos bugs relacionados ao KVM, então mude para o CentOS ou até mesmo o Fedora como um teste.

    
por 09.06.2015 / 15:27