Qemu schlechte Performance

R

rootieX4

New Member
Hallo,

da ich jetzt schon oft den Hoster wechseln musste und keine Lust mehr habe immer alles neu aufzusetzen, habe ich angefangen meine Minecraft-Server in eine VM zu kopieren. Zur Virtualisierung verwende ich Qemu, in Kombination mit virsh. Bei etwa 130 Spielern auf dem Minecraft Server fängt es schon an zu Laggen, auf echter HW hat es erst bei 180-200 angefangen. Ich denke, es liegt an der Virtualisierung der CPU, da Qemu aufgrund falscher Einstellung die CPU Anweisungen zu oft umschreiben muss und somit viel Leistung verschenkt.

Startparameter:
Code: 
/usr/bin/kvm -S -M pc-1.1 -cpu SandyBridge,+osxsave,+pdcm,+xtpr,+tm2,+est,+smx,+vmx,+ds_cpl,+monitor,+dtes64,+pbe,+tm,+ht,+ss,+acpi,+ds,+vme -enable-kvm -m 28672 -smp 6,sockets=6,cores=1,threads=1 -name Minecraft -uuid ed7e6bda-2e9f-3895-2ff8-c52c54db588f -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/Minecraft.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/ssd/vm/Minecraft/boot.img,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive file=/srv/vm/Minecraft/data.img,if=none,id=drive-virtio-disk1,format=raw -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk1,id=virtio-disk1 -drive 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 -netdev tap,fd=20,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:49:93:3c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:1 -k de -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

Host CPU:
Code: 
Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz

Htop Host:
MOD: Anhang.

Htop VM:
MOD: Anhang.
 

Attachments

  • host.png
    host.png
    21.7 KB · Views: 227
  • vm.png
    vm.png
    19.6 KB · Views: 218
Die CPU scheint er richtig umzuschreiben (cpu type = host); in diesem Fall versucht libvirt eine CPU + einige Befehlssätze auszuwählen, die deiner Host-CPU an nächstem kommen.

Ich denke nicht, dass dies dein Bottleneck ist.
Einige Tipps:
  • virtio für Disk
  • virtio für Netz
  • Mehrere vCPUs zuweisen -> das gibt mehr Computing-Time vom I/O-Schedulers des Hosts
 
virtio verwende ich bereits, vCPUs sind 6 zugewiesen. Minst du, dass die hohe CPU Last durch das Filesystem verursacht, wird da es ja doppelt verwaltet werden muss, einmal in der VM und auf dem Host.
 
Ich weiß nicht, wie viel die Server-Variante von Mine Craft an Last verursacht.
Was sagt sar auf dem Host und auf der VM (sar gehört zu sysstat).
 
Host:
Code: 
21:10:30        CPU     %user     %nice   %system   %iowait    %steal     %idle
21:10:32        all     11,76      0,00      0,88      0,00      0,00     87,36
21:10:34        all     10,12      0,00      0,44      0,44      0,00     89,00
21:10:36        all     10,77      0,00      0,81      0,44      0,00     87,98
21:10:38        all      9,39      0,00      0,75      0,50      0,00     89,36
21:10:40        all     10,16      0,00      0,75      0,13      0,00     88,96
21:10:42        all     10,09      0,00      0,38      0,00      0,00     89,53
21:10:44        all     10,00      0,00      0,50      0,31      0,00     89,18
21:10:46        all     11,01      0,00      0,69      0,06      0,00     88,24
21:10:48        all     10,13      0,00      0,76      0,25      0,00     88,86
21:10:50        all     10,11      0,00      0,44      0,06      0,00     89,38
Durchschn.:     all     10,36      0,00      0,64      0,22      0,00     88,78

VM:
Code: 
23:11:31        CPU     %user     %nice   %system   %iowait    %steal     %idle
23:11:33        all      8,99      0,00      3,24      0,08      0,08     87,60
23:11:35        all      9,48      0,00      3,74      0,00      0,17     86,61
23:11:37        all      8,67      0,00      2,78      0,51      0,17     87,88
23:11:39        all      8,33      0,00      4,33      0,00      0,08     87,26
23:11:41        all      7,47      0,00      3,44      1,09      0,08     87,92
23:11:43        all      9,30      0,00      3,52      0,42      0,25     86,50
23:11:45        all      6,80      0,00      3,69      0,00      0,00     89,51
23:11:47        all      7,62      0,00      3,18      0,59      0,08     88,53
23:11:49        all      8,30      0,00      3,98      0,00      0,00     87,72
23:11:51        all      8,71      0,00      3,27      0,75      0,08     87,19
Average:        all      8,37      0,00      3,52      0,34      0,10     87,67

Um diese Uhrzeit Laggt es allerdings nicht, da nur noch 30 Spieler Online seind.
 
Hört sich nach einem I/O Problem an. Ich kann dir nur empfehlen qcow2 für das HDD Image zu nutzen, habe damit in der Arbeit (Proxmox Cluster) sehr gute Erfahrungen gemacht.
 
Für solche Umgebungen wäre imho nicht eine Paravirtualisierung wie KVM die richtige Wahl sondern OpenVZ. Dadurch bist du ausreichend von der Hardware abgekoppelt als dass ein Transfer leicht wird, aber der Leistungsverlust von mehreren Betriebssystemen bleibt erspart.

Alternativ - noch leichter - wäre ein simpler chroot-Container, dann brauchst du nicht mal ein entsprechendes System auf den Host zu bügeln. Sicherheit in Form von Ausbruch sowie CPU-Begrenzung ist in deinem Fall ja kein Problem.

Hört sich nach einem I/O Problem an.
Click to expand...
Die IO-Wait kratzt knapp mal an 0.5%. Nichtdestotrotz solltest du sicher stellen dass bei Host und virtuellem Image der Mount-Parameter noatime gesetzt ist und ggf danach vergleichen.
Das Problem könnte imho aber eher am Scheduling liegen.
 
d4f said:
Für solche Umgebungen wäre imho nicht eine Paravirtualisierung wie KVM die richtige Wahl sondern OpenVZ. Dadurch bist du ausreichend von der Hardware abgekoppelt als dass ein Transfer leicht wird, aber der Leistungsverlust von mehreren Betriebssystemen bleibt erspart.
Click to expand...

Werde ich mir mal ansehen.

d4f said:
Alternativ - noch leichter - wäre ein simpler chroot-Container, dann brauchst du nicht mal ein entsprechendes System auf den Host zu bügeln. Sicherheit in Form von Ausbruch sowie CPU-Begrenzung ist in deinem Fall ja kein Problem.
Click to expand...
Wenn ich kein System habe kann ich ja auch kein extra Mysql-Server und Java installation in dem Container haben oder?

d4f said:
Die IO-Wait kratzt knapp mal an 0.5%. Nichtdestotrotz solltest du sicher stellen dass bei Host und virtuellem Image der Mount-Parameter noatime gesetzt ist und ggf danach vergleichen.
Das Problem könnte imho aber eher am Scheduling liegen.
Click to expand...

noatime Ist beim Host als auch in der VM gesetzt.
 
You must log in or register to reply here.
Back
Top