UCS als KVM-Gast, Samba langsam

german

#1

Hallo zusammen,

ich bin nicht sicher ob es ein UCS-Problem ist, mit KVM zusammenhängt oder eine Kombination aus beidem. Evtl kann mir jemand einen Wink in die richtige Richtung geben.

Ich betreibe den UCS als Gast in KVM. Die Hardware ist ein Supermicro Dual-Opteron mit 2xAMD Opteron™ Processor 4386 und 32GB-RAM. Das Host-System ist ein Debian8 als minimales System. Für KVM habe ich folgende Anpassungen vorgenommen:

/etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=deadline transparent_hugepage=always"

/etc/sysctl.conf: kernel.sched_min_granularity_ns=10000000 kernel.sched_wakeup_granularity_ns=15000000 vm.dirty_ratio=10 vm.dirty_background_ratio=5 vm.swappiness=0

/etc/modprobe.d/vhost-net.conf: options vhost_net experimental_zcopytx=0

/etc/default/irqbalance ENABLED="1" ONESHOT="0" OPTIONS="--hintpolicy=ignore"

Auf dem Host die LVM als Container um die virtuellen Festplatten (LV’s) der Gäste aufzunehmen. Die Konfig des UCS sieht folgendermaßen aus:

[code]/etc/libvirt/qemu/TUX.xml:

TUX 2b6e6869-d85b-4e16-8942-61875fae625f 8388608 8388608 32 hvm destroy restart restart /usr/bin/kvm [/code]

Im UCS habe ich folgenden angepasst:

[code]/etc/default/grub:

GRUB_CMDLINE_LINUX_DEFAULT=" quiet loglevel=0 rootdelay=5 splash elevator=noop transparent_hugepage=always"[/code]

/etc/sysctl.conf: vm.swappiness=0

/etc/fstab: UUID=4ae7424b-2790-42da-8991-ac677edbb228 / btrfs defaults 0 1 UUID=3fc78459-9d09-4cc5-b929-8a65acc03bfe /boot ext4 defaults,user_xattr 0 2 UUID=8fe3b11d-b00f-4b07-9f3b-e0d372c17950 /home btrfs defaults 0 2 UUID="05632109-9108-4b8d-b542-3011c188b304" /data btrfs defaults 0 2 UUID=57b9afde-95e7-4e41-b1bb-258fbf0f7107 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 tmpfs /var/cache/apt/archives tmpfs size=15%,defaults 0 0

Die Freigabe habe im UCS habe ich wie folgt angelegt:

Share -> Neu

** Allgemein **

Name: test3
Pfad: /data/test3
Besitzer: Administrator
Gruppe: Domain Users

Dateiberechtigungen für das Wurzelverzeichnis der Freigabe: Besitzer rwx, sonst nichts.

** Samba **

Benutzer mit Schreibrechten dürfen die Berechtigungen verändern: aktiv

** Erweiterte Einstellungen **

  • Samba Rechte *

Erzwungener Benutzer: Administrator
Erzwungene Gruppe: Domain Users

Neue Dateien und Verzeichnisse erhalten den Besitzer des übergeordneten Verzeichnisses: aktiv
Neue Dateien und Verzeichnisse erhalten die Zugriffsrechte des übergeordneten Verzeichnisses: aktiv

** Optionen **

Für NFS-Clients exportieren (NFSv3 und NFSv4): deaktiviert

Netzwerk ist Gigabit. Ich habe den Client testweise direkt mit Patchkabel in den Switch am Server gesetgt. Die Serverkarte läuft auch mit 1000Mbit Full-Duples (ethtool). Wenn ich nun Daten vom Client in die Freigabe kopiere (ca 5GB / 2000 Dateien) läuft dies die meiste Zeit unter 10 MB/Sec.

Hat jemand einen Tipp wo ich ansetzen kann?

Viele Grüße
pixel


Update 4.1 -> 4.2 bricht ab. System in undefiniertem Zustand
Win7Pro-VM auf UCS, HD und/oder Netz unterirdisch langsam
#2

Moin,

testen Sie doch mal von unten nach oben richtig durch:

[ol][li]I/O-Performance auf dem Host-System (Debian), z.B. mit iozone[/li]
[li]I/O-Performance im KVM-Gast-System direkt auf dem Dateisystem, z.B. mit iozone[/li]
[li]Performance vom KVM-Gast-System zum KVM-Gast-System über Samba (mit smbclient, sehr große Datei transferieren, sollte größer als Hauptspeicher sein, um Caching-Effekte möglichst zu vermeiden)[/li]
[li]Performance von einem anderen Linux aus zum KVM-Gast-System über NFS (NFS hat deutlich weniger Overhead als Samba, außerdem sind es komplett andere Serverkomponenten; sehr große Datei transferieren, sollte größer als Hauptspeicher sein, um Caching-Effekte möglichst zu vermeiden)[/li]
[li]Performance von einem anderen Linux aus zum KVM-Gast-System über Samba (mit smbclient, sehr große Datei transferieren, sollte größer als Hauptspeicher sein, um Caching-Effekte möglichst zu vermeiden)[/li][/ol]

Das sollte Anhaltspunkte geben, welche der Komponenten genau langsam ist. Die Hardware? Die Virtualisierung? Der Samba-Server?

Gruß,
mosu


#3

So, etwas spät aber das Thema ist ja durchaus komplex. Ich habe mich mal soweit es mir möglich ist in iozone eingelesen und es auf einem Testsystem ausprobiert. Auf dem Tstsystem (Debian 8) musste ich in der sources.list “non-free” aktivieren. Wie komme ich unter UCS an das Paket?


#4
ucr set  repository/online/unmaintained=yes 
univention-install iozone
ucr set  repository/online/unmaintained=no

#5

Danke!

Bevor ich dass auf das Produktiv-System los lasse wollte ich die Sache vom prinzip her erst mal auf einem Testsystem durchspielen da ich die KVM-Sachen immer gleich einrichte auch wenn sich Hardware/OS unterscheiden. Als Testsystem nahm ich jetzt einfach mal einen Ubuntu-Server (16.04) und eine Debian8-VM. Da ich ja von unten nach oben testen sollte habe ich auf dem Testhost einfach mal angefangen. Der Aufruf:

iozone -s 25g -r 8k -i 0 -i 1 -i 2 /kvm_test/

läuft mehrere Stunden und dann heisst es irgendwan “abgebrochen”. Der Testhost hat insgesamt 18GB RAM, das Test-LV dass ich unter /kvm_test/ gemountet habe hat 35GB. Wie würde ein sinvoller Aufruf aussehen?


#6

Es gibt viele Blogposts, die beschreiben, wie iozone sinnvoll nutzbar ist, z.B. dieser hier. Beachten Sie primär Punkt 9 dort, und testen Sie erst mal mit den Standardgrößen (also ohne das »-s 25g«).


#7

Der Aufruf dort:

Aktuell (mit gestarteten VM’s sieht es auf dem Host so aus:

root@kvm01:~# free -h gesamt benutzt frei gemns. Puffer/Cache verfügbar Speicher: 17G 12G 1,9G 25M 3,3G 4,9G Auslagerungsspeicher: 951M 0B 951M

Bedeutet dass ich nehme den freien RAM mal drei:

iozone -a -g 6G -i 0

damit ich realistische Werte bekomme?


#8

Moin,

iozone ist schon sehr komplex. Vielleicht testen Sie erst mal mit einer wirklich einfachen Variante, nämlich »dd«. Auch dabei gibt’s durchaus Sachen zu bedenken. Hier ist eine gut verständliche Zusammenfassung. Nutzen Sie eine Blocksize (Parameter »bs«), die groß ist aber trotzdem komfortabel in den aktuell freien Speicher passt. In Ihrem Beispiel oben in der Ausgabe sind 1,9 GB frei; eine »bs=1G« sollte also gut funktionieren.

Als Größe (»bs * count«) vielleicht zuerst in Summe 1 GB. Die Testdauer sollte schon im Bereich mehrerer 10 Sekunden liegen, um aussagekräftig zu sein.

Das können Sie dann auf dem Virtualisierer und in den VMs machen. Achtung: die block size in den VMs muss natürlich an die Menge freien Speichers in der VM selber angepasst werden, nicht an den freien Speicher im Virtualisierer.

Gruß,
mosu


#9

So, jetzt habe ich es auf dem Produktiv-System um welches es ja geht getestet.

Auf dem Host:

root@kvm01:~# free -h total used free shared buffers cached Mem: 31G 27G 4,2G 40M 280K 9,4G -/+ buffers/cache: 17G 13G Swap: 951M 0B 951M ... root@kvm01:~# dd if=/dev/zero of=/root/testfile bs=3G count=1 oflag=dsync 0+1 Datensätze ein 0+1 Datensätze aus 2147479552 Bytes (2,1 GB) kopiert, 9,02007 s, 238 MB/s

Auf der VM (UCS):

root@tux:/data# free -h total used free shared buffers cached Mem: 7,8G 7,7G 115M 0B 116K 6,3G -/+ buffers/cache: 1,4G 6,4G Swap: 1,9G 0B 1,9G ... root@tux:/data# dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=dsync 1+0 Datensätze ein 1+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 3,05174 s, 352 MB/s

Ich habe bs=… dann eben an den freien RAM angepasst aber die VM hat einen höheren Durchsatz als der Host. Wie kann das sein?

Viele Grüße
pixel24


#10

Moin,

dann cachet der Host. Ich weiß gerade nicht, wie man das sinnvoll verhindert könnte.

LG,
mosu


#11

Ich bin jetzt nicht der Profi in Sachen Performance-Messung aber ich habe den Eindruck dass das Problem eher vom virtualisiertem Netzwerk her rührt. Kenn jemand eine gute und aktuelle Doku wie man unter KVM das Netzwerk am sinvollsten einrichtet.

Kann es u.U. an der Verwendung von BTRFS im UCS liegen?


#12

Moin,

Die schnellste Variante sowohl für Netzwerk als auch für I/O sind die para-virtualisierten Geräte und die dazugehörigen Treiber. Para-virtualisiert bedeutet, dass die nur halb emuliert werden. Diesen Typ muss man bei der Konfiguration der virtuellen Maschine für die Netzwerkkarte setzen. Ein Linux-Gast sollte dann den Typen automatisch erkennen und das dazugehörige Kernelmodul »virtio_net« laden.

Analog gilt das dann auch für die Blockgeräte, wobei das oftmals schon der Fall ist.

Halte ich spontan für eher unwahrscheinlich. Allerdings habe ich BTRFS unter UCS noch nicht eingesetzt. Auf anderen, Nicht-UCS-Servern performt es sehr gut. Aber das bedeutet nichts. Im Zweifelsfall: nicht raten, messen und mit anderen Dateisystemen vergleichen.

LG,
mosu


#13

Ich bin dabei verschiedene Einstellungen zu testen. Gerade aufgefallen. Am KVM-Host selbst (der in der auf tty1 steht) sehe ich folgende Meldungen:

perf interrupt took too long (2509 > 2500), lowering kernel.perf_event_max_sample_rate to 5000 device vnet4 entered promiscuous mode intern: port 5(vnet4) entered forwarding state intern: port 5(vnet4) entered forwarding state qemu-system-x86: sending ioctl 5326 to a partition qemu-system-x86: sending ioctl 80200204 to a partition intern: port 5(vnet4) entered forwarding state intern: port 5(vnet4) entered disable state device vnet4 left promiscuous mode intern: port 5(vnet4) entered forwarding state intern: port 5(vnet4) entered forwarding state qemu-system-x86: sending ioctl 5326 to a partition qemu-system-x86: sending ioctl 80200204 to a partition intern: port 5(vnet4) entered forwarding state intern: port 5(vnet4) entered disable state device vnet4 left promiscuous mode intern: port 5(vnet4) entered disable state

Evtl sind diese relevant?


#14

Moin,

haben Sie diese Meldungen auch noch mal mit Zeitstempeln? Die Meldungen zu den Ports sind prinzipiell harmlos, sofern sie nicht ständig und schnell hintereinander auftreten. Sie treten halt dann auf, wenn Interfaces zu Bridges hinzugefügt oder aus ihnen entfernt werden – z.B. wenn virtuelle Maschinen gestartet oder beendet werden.

Die qemu-Meldungen sind die einzigen, die mir erst mal nichts sagen. Googlen sagt, dass die Meldungen wohl daher stammen, wenn Programme testen, ob ein Device ein tape drive sind (anscheinend ist das in diesem konkreten Fall »mdadm«). Auch sie scheinen nach dem verlinkten E-Mail-Wechsel harmlos zu sein.

Gruß,
mosu