Onderwerp: Slechte performance vm's?

Howdy,

Ik heb van het weekend eens gespeeld met wat virtualisatie producten zoals vmware server 1.x en Xen maar het valt me op dat ik een behoorlijk slechte performance zie.

Gezien ik eerst met VMware heb gespeeld dacht ik dat het zou kunnen liggen aan dat ik had gekozen om de disk ruimte niet direct aan te maken maar zodra het nodig is.

Host OS is Ubuntu Hardy. Guest is ook Hardy op zowel VMware server (disk grows as we go along), VMWare server (disk compleet aangemaakt) en Xen. Altijd alle CPU's toegekend aan de vm en 2 Gb aan geheugen.

En met een simpele Apache Benchmark test zie ik daar:

Apache direct op het ijzer:

Requests per second: 6322.59 [#/sec] (mean)

Apache in een vm:

Requests per second: 248.41 [#/sec] (mean)

Welke VM maakt op zich niet zo gek veel uit het zijn altijd rond deze waardes.

Ik verwacht wel een performance hit bij een VM maar niet een zodanige. En ik gok er op dat je met wat tweaking en tuning ook nog wel een betere performance uit welk virtualisatie product dan ook kan halen maar van 248 requests naar 6000 (or for that matter naar 3000) is nog wel een heel eind weg.

Doe ik hier iets fout of moet je echt naar de ESX'en van deze wereld gaan kijken om ongeveer dezelfde performance uit je machine te halen?

Ik probeer overigens geen wetenschappelijk onderbouwde performance test te doen. En was voornamelijk nieuwsgierig naar wat de performance was ongeveer out-of-the-box. Vandaar een simpele apache benchmark op een plain html pagina.

heb je een virtuele schijf, of een partitie toegewezen aan de vm?

Oorspronkelijk geplaatst door VinceSTM

heb je een virtuele schijf, of een partitie toegewezen aan de vm?

Een virtuele schijf.

Oorspronkelijk geplaatst door Pur

Een virtuele schijf.

Als extra heb op 2 systemen getest beide systemen:

Host:
- Hardy
- 2 x 15K RPM disken in Raid 1
- / op ext3 en daar weer het guest os op
- Geen LVM
- 2 x Xeon 2.8 Ghz CPU's
- 4 Gb aan memory

Op het 2e systeem heb ik nog 4 extra disken die ik wel vrij kan maken in een raid 1+0 setup. Maar imho zou direct op de disk eigenlijk van 5000 naar 6000 requests per second moeten uitmaken en niet van 255 naar 5000 ofzo

Gebruik _geen_ diskimages. Het aanmaken ervan (dd if=/dev/....) duurt uren en het is traag. Gebruik lekker LVM, makkelijk te resizen en te backuppen.

Voorbeeldje voor LVM onder Ubuntu.

Code:

xen-create-image --lvm=/dev/XEN --hostname=vps38.vpshost.nl --swap=256Mb --ide \
--ip=10.0.0.38 --netmask=255.255.255.0 --gateway=10.0.0.1 --force \
--memory=1024Mb --size=120000 --arch=i386 --kernel=/boot/vmlinuz-2.6.22-14-server \
--initrd=/boot/initrd.img-2.6.22-14-server --debootstrap --dist=dapper \
--mirror=http://ubuntu.apt-get.eu/ubuntu --passwd

mod-alert: editrechten staan uit in dit subforum?

Oorspronkelijk geplaatst door Randy

mod-alert: editrechten staan uit in dit subforum?

Zou nu wel moeten werken.

pur, hoeveel vpssen heb je actief op hoeveel cpu cores? Overbooking in dit geval kan veel schelen op je performance. En hoeveel fysiek geheugen heb je beschikbaar? Hoeveel heb je aan vpssen totaal toegewezen? Als je host het ramgeheugen van de vpssen gaat swappen stort je performance ook neer als een vliegtuig zonder vleuges.

Ik gebruik in principe 1 VPS op een 4 core machines met 4 GB geheugen waarvan ik 2 aan de VPS alloceer.

De situatie is nu nog wat waziger geworden...

Host 1 heeft dus maar 2 disken dus ik moet daar wel met images werken:

Op het ijzer: 2700 rps
Op de VM: 249 rps

Host 2 heeft 2 disken voor / en nog 4 disken in raid 1+0

Op het ijzer: 6800 rps
Voorheen op de VM: ~ 250 rps
Nu op een VM op LVM: 3900 rps
Nu op een VM op disk image op raid 1+0: 3800 rps
Nu op een VM op disk image op /: 3700 rps

Ik dacht dat het te maken had wellicht met de gebruikte opties voor xen-create-image maar blijkbaar niet.

Het is alleen jammer dat ik nou net met de 1e server kleinschalig wat diensten wil gaan virtualiseren :-)

Overigens duurt het creeeren van images geen uren bij mij maar minuten. En volgens deze tests blijkt dat er relatief weinig verschil zit tussen LVM en image. Nu zal dat ongetwijfeld op een drukke server wel anders zijn gezien dat deze servers nu niks doen.

Ik zal morgen nog eens wat tests met bijv. bonnie doen om te kijken hoe het met de i/o performance zit.

- 2 x Xeon 2.8 Ghz CPU's

Dit zien er mijn geen processors uit die hardware VT ondersteunen. Ondersteuning voor hardware virtualization kan een wereld van verschil uitmaken.

Oorspronkelijk geplaatst door Pur

... En volgens deze tests blijkt dat er relatief weinig verschil zit tussen LVM en image. Nu zal dat ongetwijfeld op een drukke server wel anders zijn gezien dat deze servers nu niks doen.

Ik zal morgen nog eens wat tests met bijv. bonnie doen om te kijken hoe het met de i/o performance zit.

LVM geeft hoe dan ook weinig overhead; het zijn lineaire translaties die gebeuren, geen ingewikkelde bewerkingen. Na de vertaling wordt de opdracht verder doorgesluisd naar de onderliggende disks.

Je resultaten lijken we wat vreemd, normaal zou Xen een kleine performantiehit moeten geven, maar geen 50% zoals in jou resultaten. Is in je tests de hoeveelheid geheugen (en mogelijk caching van het bestandssysteem) gelijk? Wat veroorzaakt precies de load?

Oorspronkelijk geplaatst door GlennMatthys

Dit zien er mijn geen processors uit die hardware VT ondersteunen. Ondersteuning voor hardware virtualization kan een wereld van verschil uitmaken.

Maar niet in dit geval. Xen maakt gebruik van paravirtualisatie, waarbij het guest-OS een kernel met Xen support draait en dus direct via de xen kernel op de host toegang heeft tot de hardware.

Ik ben ook wel nieuwsgierig waar precies de bottleneck zit tijdens het draaien van zo'n apache test. Laat eens een xm top op het host-os meedraaien en een vmstat op het guest os.

Oorspronkelijk geplaatst door wonko

LVM geeft hoe dan ook weinig overhead; het zijn lineaire translaties die gebeuren, geen ingewikkelde bewerkingen. Na de vertaling wordt de opdracht verder doorgesluisd naar de onderliggende disks.

Je resultaten lijken we wat vreemd, normaal zou Xen een kleine performantiehit moeten geven, maar geen 50% zoals in jou resultaten. Is in je tests de hoeveelheid geheugen (en mogelijk caching van het bestandssysteem) gelijk? Wat veroorzaakt precies de load?

Zowel op server 1 & 2 draait alleen apache (kaal gecompileerd, met de default config). Alle VM's zijn gelijk behalve dan dat er 1 draait op LVM, 1 op 4 disk raid en 1 op een 2 disk raid. Tijdens het moment van testen draait er maar 1 vm. Tijdens het testen van de host draait ook 1 VM maar die wordt dan dus verder niet belast. En tijdens het belasten van de VM wordt dus de host ook niet apart nog belast.

Zowel VM als Host heeft verder niks te doen. En load wordt veroorzaakt door een apache benchmark test met bijv concurrency van 10 en # Requests van 10000. Dat levert dan afhankelijk van hoe goed de test gaat een paar seconde load op tot een kleine minuut.

Oorspronkelijk geplaatst door hostlogic.nl

Maar niet in dit geval. Xen maakt gebruik van paravirtualisatie, waarbij het guest-OS een kernel met Xen support draait en dus direct via de xen kernel op de host toegang heeft tot de hardware.

Ik ben ook wel nieuwsgierig waar precies de bottleneck zit tijdens het draaien van zo'n apache test. Laat eens een xm top op het host-os meedraaien en een vmstat op het guest os.

Ik ben niet zo'n held qua uitlezen van vmstat maar dit is de output van de langzaamste vm (die dus 250 requests doet):

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 1651660 142284 246288 0 0 0 0 250 7 0 0 100 0
0 0 0 1651660 142284 246288 0 0 0 0 257 7 0 0 100 0
0 0 0 1651660 142284 246288 0 0 0 0 255 7 0 0 100 0
1 0 0 1651660 142284 246292 0 0 0 778 706 760 0 0 100 0
2 0 0 1651660 142284 246376 0 0 0 5006 2862 4701 0 0 97 3
2 0 0 1651412 142284 246464 0 0 0 5054 2869 4737 0 0 95 4
2 0 0 1651056 142284 246548 0 0 0 4818 2847 4616 0 0 96 4
2 0 0 1650792 142284 246636 0 0 0 5054 2808 4737 0 0 96 3
2 0 0 1650420 142284 246720 0 0 0 5051 2951 4737 0 0 96 3
2 0 0 1650064 142284 246808 0 0 0 5013 2824 4706 0 0 96 3
2 0 0 1649676 142284 246892 0 0 0 5054 2830 4737 0 0 96 3
0 0 0 1649180 142284 246980 0 0 0 4482 2628 4234 0 0 97 3
0 0 0 1649180 142284 246980 0 0 0 0 250 7 0 0 100 0

disk- ------------reads------------ ------------writes----------- -----IO------
total merged sectors ms total merged sectors ms cur sec
xvda2 4990 1503 194354 38104 1057272 496770 12432336 322796 0 238
xvda2 4990 1503 194354 38104 1057272 496770 12432336 322796 0 238
xvda2 4990 1503 194354 38104 1057272 496770 12432336 322796 0 238
xvda2 4990 1503 194354 38104 1057274 496778 12432416 322796 0 238
xvda2 4990 1503 194354 38104 1057274 496778 12432416 322796 0 238
xvda2 4990 1503 194354 38104 1057274 496778 12432416 322796 0 238
xvda2 4990 1503 194354 38104 1057280 496780 12432480 322796 0 238
xvda2 4990 1503 194354 38104 1057484 496853 12434696 323068 0 238
xvda2 4990 1503 194354 38104 1059296 497347 12453144 323208 0 238
xvda2 4990 1503 194354 38104 1061280 497880 12473280 323232 0 238
xvda2 4990 1503 194354 38104 1063244 498406 12493200 323248 0 238
xvda2 4990 1503 194354 38104 1065241 498942 12513464 323248 0 238
xvda2 4990 1503 194354 38104 1067130 499450 12532640 323296 0 238
xvda2 4990 1503 194354 38104 1068860 499927 12550296 323416 0 238
xvda2 4990 1503 194354 38104 1070856 500460 12570528 323416 0 238
xvda2 4990 1503 194354 38104 1072853 500996 12590792 323416 0 238
xvda2 4990 1503 194354 38104 1074756 501509 12610120 323512 0 238
xvda2 4990 1503 194354 38104 1076751 502045 12630368 323520 0 239
xvda2 4990 1503 194354 38104 1078712 502573 12650280 323532 0 239
xvda2 4990 1503 194354 38104 1080590 503080 12669360 323588 0 239
xvda2 4990 1503 194354 38104 1082357 503562 12687352 323688 0 239
xvda2 4990 1503 194354 38104 1084353 504098 12707608 323688 0 239
xvda2 4990 1503 194354 38104 1086240 504605 12726760 323720 0 239
xvda2 4990 1503 194354 38104 1088207 505134 12746728 323728 0 239
xvda2 4990 1503 194354 38104 1090141 505655 12766368 323756 0 239
xvda2 4990 1503 194354 38104 1092061 506170 12785848 323784 0 239
xvda2 4990 1503 194354 38104 1094057 506707 12806112 323784 0 239
xvda2 4990 1503 194354 38104 1095948 507216 12825312 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239
xvda2 4990 1503 194354 38104 1096399 507337 12829888 323812 0 239

Op ons esx platform met een directadmin kist op debian krijg ik het volgende terug:
Requests per second: 321.24 [#/sec] (mean)
5000 requests 200 per keer.

Oorspronkelijk geplaatst door Randy

Gebruik _geen_ diskimages. Het aanmaken ervan (dd if=/dev/....) duurt uren en het is traag. Gebruik lekker LVM, makkelijk te resizen en te backuppen.

Gisteren even naar het datacenter gereden om de langzaamste bak opnieuw te installeren met LVM. Maar ook dat heeft uiteindelijk niet geholpen want hij geeft nog steeds een performance van rond de 250 rps of het nou een image is of op een lvm.