Univention Bugzilla – Bug 19249
Xen Performance - xenhopt per UCR
Last modified: 2010-08-31 13:20:37 CEST
Mit der aktuellen Xen-Version in UCS ist der Start der Xen-Instanzen relativ langsam. Es müsste geprüft werden, ob das das Standard-Xen Verhalten ist. Folgende Punkte sollten geprüft werden: - NUMA: http://wiki.debian.org/Xen#NUMAwithxen3.4 - Ballooning deaktivieren
- http://wiki.xensource.com/xenwiki/XenBestPractices $ grep xenhopt /boot/grub/menu.lst # xenhopt=dom0_mem=512M
Derzeit wird pygrub ohne -q aufgerufen, dadurch gibt es erhebliche Verzögerungen beim Start. Das behebt Philipp gerade.
Da inzwischen PyGrub für Xen-PV-Maschinen benutzt wird, ist hier PyGrub in das innerhalb von /boot/grub/menu.cfg definierte Timeout von 60 Sekunden gelaufen, um das Image zu extrahieren. Das Xen-CLI-Tool "xm" implementiert deshalb extra eine Logik in <file:xen-3.4.3/tools/python/xen/xm/create.py>, die immer den interaktiven Modus von PyGrub per '-q' deaktiviert (außer es wird die Xen-Console direkt per "xm create -c ..." gefordert.) UVMMd erzeugt jetzt ebenfalls den Eintrag <bootloader_args>-q</bootloader_args> in der Konfigurationsdateien.
Ich sehe im Moment zwei Möglichkeiten: - tap:aio anstatt file zu verwenden, vom GefÌhl her reagiert die Dom0 dann besser, siehe auch Xen-Mailingliste: http://lists.xensource.com/archives/html/xen-devel/2010-05/msg01502.html - die Optionen fÌr den Dom0-Speicher und fÌr die CPU-Zuweisung root@master:~# grep xenhopt /boot/grub/menu.lst # xenhopt=dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin @Philipp, womit hattest du die Plattenzugriffe auf den KVM-Systemen getestet?
(In reply to comment #4) > - tap:aio anstatt file zu verwenden, vom GefÃŒhl her reagiert die Dom0 dann > besser, siehe auch Xen-Mailingliste: Dazu hatte Bastian schon mal Performance-Untersuchungen angestellt: <https://billy.knut.univention.de/uniwiki/index.php/Bastian_swap2> Ergebnis war, das tap:aio langsamer war, aber das kann natürlich prinzipbedingt dadurch zustande kommen, daß eben nicht der Cache der dom0 genutzt wird. Auch war das eine einzelne domU, interessant ist ja auch das Verhalten, wenn mehrere domUs gleichzeitig laufen und um IO konkurrieren. Probleme sind mir dabei mit Xen-PV-Instanzen und der Verwendung mit den PV-Blockdevices (/dev/xvd[a-z]) aufgefallen: Mit tap:aio konnte PyGrub den Kernel und die InitRamFs nicht extrahieren. Soll nicht heißen daß es nicht geht, ich habe jedenfalls keine weitere Zeit darin investiert, weil es mit file: ging. > @Philipp, womit hattest du die Plattenzugriffe auf den KVM-Systemen getestet? adduser bonnie ; bonnie++ -d /home/bonnie -s 1g -u bonnie bzw. time dd if=/dev/hda bs=64k of=/dev/null wobei /dev/hda das 8 GiB Image der VM ist. Je nach Kernel auch /dev/sda oder /dev/xvda.
Insgesamt scheint die Platten-Performance derzeit unter KVM besser zu sein, als unter Xen. Zumindest auf der Hardware. Durch die Änderungen an den Xen 3.4.3 Paketen ist die Reaktion der Dom0 aber zumindest schon mal besser geworden. # Xen 3.4.3 vollvirtualisiert tap:aio # xenhopt=dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin bonnie++ -d /home/bonnie -s 512m -u bonnie base,512M,25768,61,19987,6,16711,20,23292,89,89793,49,178.2,10,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ base,512M,23134,50,27755,9,14516,17,23308,90,97535,46,213.3,13,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ # Xen 3.4.3 vollvirtualisiert file base2,512M,36290,79,34149,11,15151,18,19202,75,62411,35,158.8,9,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,++ base2,512M,22965,52,26965,9,16604,21,16368,69,60059,33,166.9,10,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ # Xen 4.0.0 vollvirtualisiert tap:aio # xenhopt=dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin bonnie++ -d /home/bonnie -s 512m -u bonnie base,512M,25150,56,24335,8,17707,21,24306,87,100801,48,203.9,11,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ base,512M,25636,56,27621,9,19831,23,22803,83,97382,45,213.7,12,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ # Xen 4.0.0 vollvirtualisiert file # xenhopt=dom0_mem=512M dom0_max_vcpus=1 dom0_vcpus_pin bonnie++ -d /home/bonnie -s 512m -u bonnie base2,512M,22790,52,23433,8,17194,21,18403,66,48886,33,169.0,8,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ base2,512M,25796,61,24705,8,16285,19,20956,81,49065,32,186.3,10,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ # Xen 4.0.0 vollvirtualisiert tap:aio # xenhopt= bonnie++ -d /home/bonnie -s 512m -u bonnie base,512M,23007,55,24477,8,16274,20,20780,65,230432,91,1811.5,71,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ base,512M,31506,71,40553,14,16517,19,23097,79,167728,66,2451.7,80,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ # Xen 4.0.0 vollvirtualisiert file # xenhopt= bonnie++ -d /home/bonnie -s 512m -u bonnie base2,512M,20364,50,20104,6,18170,21,23375,78,88210,32,1431.5,45,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ base2,512M,31287,69,40662,14,16837,20,18199,59,90336,34,2779.6,63,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ # Xen 3.4.3 vollvirtualisiert tap:aio 2.6.18 # xenhopt= bonnie++ -d /home/bonnie -s 512m -u bonnie base,512M,25159,59,26351,8,29109,34,31738,95,264717,32,3022.6,59,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++
As I said in my previous mail - it is meaningless to compare performance of tap:aio with file: One writes data to disk when you ask it to (blktap) the other postpones the writes indefinitely (file). Of course the one which doesn't actually write your data to disk is faster - but that's not useful because upon crash you can say goodbye to your data. It is doubly meaningless to compare the performance when using sparse files. Every write to a sparse file which requires extra blocks to be allocated will hit the journal - this destroys performance. If you want to look at performance, use non-sparse files with blktap, and compare against phy: Any comparison against file: is completely bogus. Quelle: http://lists.xensource.com/archives/html/xen-users/2007-02/msg00680.html
(In reply to comment #7) > As I said in my previous mail - it is meaningless to compare performance > of tap:aio with file: One writes data to disk when you ask it to (blktap) > the other postpones the writes indefinitely (file). Of course the one which > doesn't actually write your data to disk is faster - but that's not useful > because upon crash you can say goodbye to your data. > > It is doubly meaningless to compare the performance when using sparse > files. Every write to a sparse file which requires extra blocks to be > allocated will hit the journal - this destroys performance. If you want > to look at performance, use non-sparse files with blktap, and compare > against phy: Any comparison against file: is completely bogus. Meine Tests waren reines Lesen, von daher ist der 2. Absatz irrelevant; bis auf den Ausreißer ganz am Anfang mit VM-Lesen >> Hardware-Lesen, was dadurch zu erklären ist, daß von den 8 GiB der Anfang noch im Cache der dom0 war, so daß die ersten "dom0-Cache-Size" Bytes sehr schnell gelesen werden konnten; bei allen weiteren Caches hat das Caching dann nichts geholfen, da die 8 GiB Images >> 4 GiB RAM der Maschine waren. > Quelle: > http://lists.xensource.com/archives/html/xen-users/2007-02/msg00680.html Bekannt: <https://billy.knut.univention.de/uniwiki/index.php/Xen#Xen-Performance> Es wird öfters empfohlen, der dom0 eine höher Priorität / ein höheres Gewicht zu geben, da darin die qemu-dm's laufen, die für die IO zuständig sind: xm sched-credit -d 0 -w 512 Auf jeden Fall reagiert die dom0 dann lange nicht so träge, wenn eine domU läuft. Diese Einstellung ist nicht persistent und muß nach jedem Neustart (z.B. in /etc/rc.local) gemacht werden. Einstellungen für domUs müssen nach jedem deren Start erneut gemacht werden.
Weitere Links: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=992
Das hat Philipp durch die PAE-Option gleich mitgelöst, ein Test ohne grub-Optionen mit einem System: base1,1G,48586,72,82653,19,70751,19,62596,90,486215,58,13215.0,53,16,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++,+++++,+++ *** This bug has been marked as a duplicate of bug 19120 ***
Ich hatte einen weiteren Fall, bei dem nach dem Start zwei Windows Instanzen das System nicht mehr reagierte. Nach dem Setzen von xenhopt=dom0_mem=1536M dom0_max_vcpus=1 dom0_vcpus_pin reagierte das System wieder sehr gut. Die Variable in der grub/menu.lst sollte per UCR-Variable gesetzt werden können. Per Default sollte die Variable leer bleiben.
Die UCR-variable grub/xenhopt wurde eingefügt und dokumentiert: [grub/xenhopt] Description[de]=Weitere durch den Grub-Bootloader übergebene Xen-Hypervisor Optionen Description[en]=Additional Xen hypervisor options passed by the Grub boot loader ChangeLog-Eintrag: \item Im Template von \ucsName{grub} können nun auch Optionen für die \ucsUCRV{grub/xenhopt} Optionen für den Xen Hypervisor spezifiziert werden. Weiterhin wurden einige doppelt vorhandene Optionen aufgeräumt, die Dokumenation der \ucsUCR{} Variablen verbessert und ein Beispiel eingefügt, wie man das Boot-Menu um eigenen Einträge erweitern kann (\ucsBug{19249}, \ucsBug{9985}, \ucsBug{10650}, \ucsBug{10555}).
Optionen können über die UCR-Variable gesetzt werden.
UCS 2.4 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".