XEN Enterprise / Vmware performence verschil

[WilloW]

Heren,

Sinds dat wij een Equallogic hebben staan met lekker veel capaciteit en verschillende clusters wat betreft VMware ESX 3.5 en XEN Enterprise zijn mij een paar dingen opgevallen.

De disk performence verschilt heel erg met elkaar. Ik heb een paar testjes uitgevoerd.

Disk performence test op basis van Seeker
-----------------------------------------
XEN Enterprise
-----------------------------------------
./seeker /dev/xvda1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/xvda1 [101MB], wait 30 seconds..............................
Results: 947 seeks/second, 1.06 ms random access time
-----------------------------------------
VMWARE ESX3.5
-----------------------------------------
./seeker /dev/sda1
Seeker v2.0, 2007-01-15, http://www.linuxinsight.com/how_fast_is_your_disk.html
Benchmarking /dev/sda1 [29996MB], wait 30 seconds..............................
Results: 107 seeks/second, 9.33 ms random access time



Disk performence test op basis van dd
-----------------------------------------
XEN Enterprise
-----------------------------------------
time dd if=/dev/zero of=bigfile bs=1M count=500

500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 1.45755 seconds, 360 MB/s

-----------------------------------------
VMWARE ESX3.5
-----------------------------------------
time dd if=/dev/zero of=bigfile bs=1M count=500

500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 8.11062 s, 64.6 MB/s


Iemand enig idee waarom de XEN Enterprise zoveel sneller is wat betreft disk? Alles staat via 2Gbit naar Equallogic verbonden

[DutchTSE]

Wat betreft de seeker meting: die via Xen is 100 mb groot, en die van VMWare 30 GB, nu ken ik seeker niet maar kan me voorstellen dat dit verschil uit maakt.

Verder inderdaad een raar verschijnsel, heb er zelf geen verklaring voor.

[WilloW]

Hoi,


Wat betreft de seeker meting: die via Xen is 100 mb groot, en die van VMWare 30 GB, nu ken ik seeker niet maar kan me voorstellen dat dit verschil uit maakt.

Verder inderdaad een raar verschijnsel, heb er zelf geen verklaring voor.

Het verschil kwa disk bij seeker had ik eerlijk gezegt nog niet gezien maar ik denk dat dit eventueel wel het verschil zou verklaren met seeker.

[xabin]

Hoi,



Het verschil kwa disk bij seeker had ik eerlijk gezegt nog niet gezien maar ik denk dat dit eventueel wel het verschil zou verklaren met seeker.

Maar 'dd' heeft ook een groot verschil, dus er moet zeker wel iets zijn.

[mxcreep]

Je dd komt uit op 360MB/s voor Xenserver terwijl je maar 2Gbit aan lijntjes hebt...oftewel er is sprake van caching in het OS... Als ik storage benchmark zorg ik er altijd voor dat het OS op een minimum aan RAM draait en dat de blokken die je leest/schrijft altijd ruim groter zijn dan in RAM past... Tevens bieden veel tools ook wel de optie om te zorgen dat je de cache niet gebruikt.

Test je overigens vanuit een VM ?

Wat ook uitmaakt in Xenserver is de ioscheduler die je gebruikt...de cfq scheduler is degene die je moet gebruiken om de QOS optie te kunnen gebruiken, maar wij gebruiken meestal de deadline scheduler aangezien die lekkerder blijkt te werken met SAN storage.

[LogiTouch]

Eventueel kan er op architecturaal vlak ook een verschil zijn. Stel dat je de testen doet vanuit de console bij de esx en dom0 (als ik me niet vergis) bij xen, dan kan je mss nog een beetje appelen en peren aan't vergelijken zijn. Dit met de veronderstelling dat de console van esx aanzien wordt als een "guest" en waar de "dom0" als basishost aanzien wordt.

Verder heb ik ooit eens gehoord dat het dd commando vanuit een esx console uitvoeren gelimiteerd kan zijn, desondanks hoe snel de onderliggende storage laag is.

(disclaimer : het bovenstaande gaat voornamelijk wat ik tijdens pot & pint heb opgevangen en niet zo zeer uit persoonlijke technische ervaring)

[fossie]

Ik heb net een test gedaan, ESXi (heb geen XenServer), met 1 VM (CentOS 5.2), geen VMWare tools geïnstalleerd, local storage; (Dell PE R200, twee standaard disks in Raid 1 (SATAII 250 Gb) en kom uit op normalere resultaten:
dd if=/dev/zero of=bigfile
bs=1M count=500 : 1.53216s => 342 MB/s
bs=100K count=5000 : 1.57239s => 326 MB/s
bs=10K count=50000 : 1.26598s => 404MB/s
bs=1K count= 500000 : 2.56117s => 200MB/s

Dit maar ter info.

Groetjes,
Fossie

[gjtje]

400MB/s op 2 disks die simultaan moeten schrijven en nog geen 100MB/s aan kunnen. Dat is dus voornamelijk de memory cache van de host die je getest hebt.