VMWare eSXi - Ontevreden over performance, slechts paar VM's

[chronoz]

Vorige maand heb ik een leuke server aangeschaft om ESXi op te installeren en om hier vervolgens virtuele servers op te gaan draaien. Het valt me alleen op dat de prestaties erg matig zijn. Het via SSH verbinden met Cerberus duurt op het momenteel bijvoorbeeld maar liefst 10 seconden... terwijl de load helemaal niet hoog lijkt te zijn.

Daarom ben ik ook op zoek naar manieren om de prestaties te verbeteren. In principe is dit nog alleen een test-server en draaien er slechts 50 domeinen op + mijn VOIP-server (1 telefoon), dus het zou supersnel moeten zijn. Zeker omdat CentOS op topsnelheid zou moeten draaien met een minimale installatie en 512mb geheugen, de Plesk- en DirectAdmin VM hebben zelfs 1GB, maar gebruiken meestal ook maar 300-400MB.



Cpu: http://i48.tinypic.com/oh1oxi.jpg
Memory: http://i50.tinypic.com/2i0ydk3.jpg
Disk: http://i45.tinypic.com/2e1ufpx.jpg
Network: http://i45.tinypic.com/1623e5h.jpg
System: http://i49.tinypic.com/9s9v9x.jpg

De provisioned en gebruikte disk ruimte van directadmin01 en plesk01 kloppen helemaal niet meer, maar dat komt denk ik omdat ik van thin provisioning 16gb naar 40gb ben gegaan en vervolgens in CentOS de LVM heb geüpgrade naar 40gb. Er is nu helaas weinig thin-provisioning meer aan bij plesk01.

De Wiki-pagina (MediaWiki) die ik heb geïnstalleerd op plesk01 voor het bijhouden van interne documentatie heeft bijvoorbeeld ook altijd 20-30 seconden nodig voordat hij klaar is met laden. De meeste sites op directadmin01 laden nog redelijk snel, al is een volle seconde voor het laden van een pagina met 1 regel in tekst (html placeholder) ook een stuk langzamer dan je zou ervaren bij fysieke machines.

[Verwijderd]

chronoz schreef op maandag 07 juni 2010 @ 18:28:
Het via SSH verbinden met Cerberus duurt op het momenteel bijvoorbeeld maar liefst 10 seconden... terwijl de load helemaal niet hoog lijkt te zijn.

Dit is in heel veel gevallen een DNS probleem

[Vorkie]

persoonlijk vind ik die 4GB wel erg karig voor deze opstelling hoor,

Hoe zijn je HDD's aangesloten?

[wasted247]

Met ^

Wat is idd de verdere exacte config van deze opstelling, inclusief netwerk, disks ed? Naast het screenshot zijn er nog een hoop specs te noemen

Edit: btw VMware tools in je guests?

[ Voor 11% gewijzigd door wasted247 op 07-06-2010 18:48 ]

[Predator]

Verwijderd schreef op maandag 07 juni 2010 @ 18:37:
[...]


Dit is in heel veel gevallen een DNS probleem

Dat lijkt het inderdaad.

Check eens de instellingen van je SSH server.
Wellicht is dat een rDNS check die time-out.
Gebruik eens

code:

UseDNS no

[chronoz]

Hierbij de hardware van mijn server:

ESX01 - Dell Inc. PowerEdge R210
PowerEdge R210 Chassis
Intel® Xeon® X3450, 2.66Ghz, 8MB Cache, Turbo, HT
4GB Memory, DDR3, 1333MHz (2x2GB Dual Ranked UDIMMs)
250GB, SATA, 3.5-inch, 7.2K RPM Hard Drive (Cabled)
16X DVD-ROM Drive SATA with SATA Cable
1Yr Basic Warranty - Next Business Day - Minimum Warranty
2/4-Post Static Rack Rails
C1 MST No Raid with On-board SATA Controller, Min. 1 Max. 2 SATA Only Drives
iDRAC6 Embedded BMC
+ 1TB Samsung F3 Spinpoint

Verwijderd schreef op maandag 07 juni 2010 @ 18:37:
[...]

Dit is in heel veel gevallen een DNS probleem

Je hebt gelijk dat het aanpassen van de resolv.conf een verbetering heeft gemaakt, al vind ik de snelheden nog steeds verre van optimaal.

De virtuele machine met plesk01 erop is echt enorm traag, ondanks dat ik deze 2 virtuele cpu's en 2GB geheugen had toegekend. De virtuele machine gebruikt slechts een paar honderd MB aan geheugen, maar is desondanks enorm traag.

wasted247 schreef op maandag 07 juni 2010 @ 18:44:
Met ^

Wat is idd de verdere exacte config van deze opstelling, inclusief netwerk, disks ed? Naast het screenshot zijn er nog een hoop specs te noemen

Edit: btw VMware tools in je guests?

Op mijn guests draaien geen VMWare Tools, maar alleen slechts op de Windows-guests, die vrijwel nooit zijn ingeschakeld. Dit komt omdat VMWare Tools bij mijn weten alleen verbeteringen heeft voor de grafische kanten?

Vorkie schreef op maandag 07 juni 2010 @ 18:39:
persoonlijk vind ik die 4GB wel erg karig voor deze opstelling hoor,

Hoe zijn je HDD's aangesloten?

4GB is inderdaad niet heel veel, maar het leek mij persoonlijk genoeg voor een test-server met slechts 6 virtuele Linux VM's. directadmin01 en plesk01 zijn de enige die meerdere services draaien en samen hosten ze nog geen 50 sites met maximaal 5000 bezoekers per dag.

De schijven zijn aangesloten via de SATA-kabels die al in de R210 zaten. Ik heb zelf een 1TB harde schijf toegevoegd, om back-ups op te zetten.

[ItsValium]

VMware houdt van RAM en DISK, hoe meer Ram hoe beter het performed, hoe sneller het disk subsysteem hoe beter het performed. Ik denk dat je
één piekt tegen de max hoeveelheid ram die esx kan gebruiken (net iets over de 3GB van de 4 aanwezig op de server gezien esx zelf een stuk reserveert voor zichzelf) en
twee piekt tegen de disks. gewone sata disken hebben niet zoveel IOPS en dat is wat je nodig hebben om meerdere vm's vloeiend naast elkaar te kunnen draaien op één machine.

[Mike2k]

Dude....jij moet echt meer gaan lezen over VMWare....

Punt 1: HT uitzetten. Google maar eens, meestal een performance verlies.

chronoz schreef op maandag 07 juni 2010 @ 19:16:
De virtuele machine met plesk01 erop is echt enorm traag, ondanks dat ik deze 2 virtuele cpu's en 2GB geheugen had toegekend. De virtuele machine gebruikt slechts een paar honderd MB aan geheugen, maar is desondanks enorm traag.

Het lukraak bijprikken van vCPU's is echt slecht.
Je moet eens kijken naar de cpu waittime.

Elke vm moet wachten totdat het aantal toegewezen cpu core's vrij is voor gebruik. Vergelijk het met IRQ's
Heb je dus een VM met 2 vCPU, dan wacht moet de vm wachten met uitvoeren van processor instructies totdat er 2 cores vrij zijn. Niet doen dus tenzij je echt 2 cores nodig hebt.

Op mijn guests draaien geen VMWare Tools, maar alleen slechts op de Windows-guests, die vrijwel nooit zijn ingeschakeld. Dit komt omdat VMWare Tools bij mijn weten alleen verbeteringen heeft voor de grafische kanten?

Wederom heb je een hoop te lezen aangezien VMWare Tools op elk OS verbeteringen aanbrengt zoals:
Betere vNic's, memory ballooning ed.

Lezen!

4GB is inderdaad niet heel veel, maar het leek mij persoonlijk genoeg voor een test-server met slechts 6 virtuele Linux VM's. directadmin01 en plesk01 zijn de enige die meerdere services draaien en samen hosten ze nog geen 50 sites met maximaal 5000 bezoekers per dag.

4Gb is gewoon weinig voor ESX. Mag best 8Gb zijn.

[Rolfie]

Mike2k schreef op maandag 07 juni 2010 @ 19:25:
lap met text.

1. zou ik inderdaad eens de vmware tools installeren.
2. Verdiep je idd eens in ESX. Boeken genoeg en documentie is er ook genoeg te vinden.
3. 4Gb is zeker niet veel, zelfs erg weinig => meer swap => Meer disk IO. En die wil je juist zoveel mogelijk NIET hebben.

[arjants]

7 Vm's op 2 SATA hardeschijven zonder raid op de onboard controller
Hoe is de verdeling over de schijven?
Denk dat daar wel redelijk een bottleneck te vinden is

[Parasietje]

Als je een virtuele server opstart, dan geef je die een stuk geheugen. Wat gebeurt er nu als je 10 linux-hosts start die elk 2Gb krijgen?

De linux hosts zullen erg veel cache gebruiken. Logisch, ze hebben 2Gb ter beschikking. Dit betekent erg veel geheugen-toegang, die eigenlijk uit de swap van je vmware host moet komen.

Wat gebeurt er met VMWare Tools? Je linux OS weet nu dat het in een virtuele omgeving draait. Het weet dat die 2Gb eigenlijk voor 90% in swap is gesmeten, omdat er nog 10 andere hosts elk 300Mb resident willen hebben. Het zal zijn cache policy aanpassen. Alle hosts zullen dus sneller werken.

Zie ook: Wikipedia: Hardware-assisted virtualization Wikipedia: Paravirtualization

[wasted247]

chronoz schreef op maandag 07 juni 2010 @ 19:16:
Op mijn guests draaien geen VMWare Tools, maar alleen slechts op de Windows-guests, die vrijwel nooit zijn ingeschakeld. Dit komt omdat VMWare Tools bij mijn weten alleen verbeteringen heeft voor de grafische kanten?

Zoals je hierboven leest hebben VMware tools dus wel degelijk invloed, ook op nix achtige Osen worden er optimalisaties doorgevoerd, voornamelijk m.b.t. memory management en de ethernet nic's, er zit idd nog een VGA driver in en wat tools voor synchronisatie met je host en what not.

VMware tools is ook hetgene wat jouw memory overcommitment draagbaar moet gaan maken, lees anders dit stukje even door.

Het valt me overigins nu pas op dat we hierover al eens eerder gebabbeld hebben. Je loopt nu dus zo goed als tegen je RAM (en IO?) limieten aan. Ik riep in dat topic al even dat ik voor vm's aanhoud RAM = RAM, dus geen overboeking. Al ging dat over een zakelijke omgeving, op mijn VMware server thuis houd ik hetzelfde aan, simpelweg omdat het swappen naar (SATA) disk vm's idd tergend traag maakt. Memory overcommitment kan je hierbij iig al een stuk opweg helpen, al heb ik zelf liever dedicated RAM voor mijn vm's.

Hier ook vast een stukje over VMware tools installaren op CentOS 5.

Mike2k schreef op maandag 07 juni 2010 @ 19:25:
Elke vm moet wachten totdat het aantal toegewezen cpu core's vrij is voor gebruik. Vergelijk het met IRQ's. Heb je dus een VM met 2 vCPU, dan wacht moet de vm wachten met uitvoeren van processor instructies totdat er 2 cores vrij zijn.

Hier wil ik toch even op reageren. Je VM kan deze threads prima afzondelijk aanspreken, het is niet zo wanneer er 1 thread in je vm uitgevoerd moet worden toch de twee cores op je host beschikbaar moeten zijn. Threads worden gewoon induvidueel gescheduled. Wel klopt het dat je het beste zo min mogelijk virtuele cpu's aan je VM kunt toevoegen. Gewoonweg omdat je hiermee minder overboeking op je host hebt.

Wat betreft hyperthreading, in ESX 3.x (en eerder) werdt aangeraden het uit te schakelen, of dit in de huidige vSphere versies ook zo is? Wat betreft cpuwaittime kan het alleen maar verbeteringen opleveren. Er dwalen verscheidenen berichten rond op internet, als ik zo gauw even zoek. In de KB van VMware wordt er niet meer over gerept (behalve de mogelijke performance issues bij v3.x)

[ Voor 6% gewijzigd door wasted247 op 08-06-2010 04:48 ]

[Microkid]

Ik zie aan je geheugengrafiekje dat je nu al aan het swappen bent,. 4GB is dus te weinig,. Investeer eens in 8GB en probeer het dan nog eens.
(en doe alles wat in de topics hierboven af genoemd is, met name de VMware tools installeren).

arjants schreef op maandag 07 juni 2010 @ 19:40:
7 Vm's op 2 SATA hardeschijven zonder raid op de onboard controller
Hoe is de verdeling over de schijven?
Denk dat daar wel redelijk een bottleneck te vinden is

Valt wel mee, Dat zal je met name merken tijdens opstarten. Uit de disk grafiek blijkt niet dat er een bottleneck op de disk zit op dit moment. Ik zet mijn centen op geheugengebrek door het ontbreken van VMware tools, waardoor er veel geswapt moet worden.

[ Voor 52% gewijzigd door Microkid op 08-06-2010 07:21 ]

[CherandarGuard]

wasted247 schreef op dinsdag 08 juni 2010 @ 04:36:

Hier wil ik toch even op reageren. Je VM kan deze threads prima afzondelijk aanspreken, het is niet zo wanneer er 1 thread in je vm uitgevoerd moet worden toch de twee cores op je host beschikbaar moeten zijn. Threads worden gewoon induvidueel gescheduled.

Weet je dat zeker? Mij werd bij de cursus verteld dat dat wel zo werkte, namelijk.

[wasted247]

CherandarGuard schreef op dinsdag 08 juni 2010 @ 09:01:
[...]
Weet je dat zeker? Mij werd bij de cursus verteld dat dat wel zo werkte, namelijk.

Mij is in de cursus andere dingen verteld, bron. Overigins is Relaxed CPU scheduling vanaf ESX 3.x ingevoerd.

It is worth noting that there is no co-scheduling overhead for an idle vCPU because the skew does not grow when a vCPU halts. For example, when a single threaded application runs in a 4-vCPU virtual machine resulting in three idle vCPUs, there is no co-scheduling overhead and it does not require four pCPUs to be available.

[ Voor 4% gewijzigd door wasted247 op 08-06-2010 11:49 ]

[deadlock2k]

-

[ Voor 100% gewijzigd door deadlock2k op 06-08-2021 16:11 ]

[Bor]

wasted247 schreef op dinsdag 08 juni 2010 @ 11:35:
[...]


Mij is in de cursus andere dingen verteld, bron. Overigins is Relaxed CPU scheduling vanaf ESX 3.x ingevoerd.


[...]

Mogelijk een optimalisatie die in vSphere 4 is doorgevoerd. In ESX 3.5 worden / moeten alle vCPUs gelijktijdig gescheduled worden op fysieke CPU's.

[ Voor 5% gewijzigd door Bor op 08-06-2010 18:45 ]

[wasted247]

Bor de Wollef schreef op dinsdag 08 juni 2010 @ 18:44:
[...]
Mogelijk een optimalisatie die in vSphere 4 is doorgevoerd. In ESX 3.5 worden / moeten alle vCPUs gelijktijdig gescheduled worden op fysieke CPU's.

Heb je de bron doorgelezen, en de aanverwante documentatie?

Back in the days of ESX Server 2.5, SMP VMs had to have their vCPUs co-scheduled at the same instant to begin running. Because only 2-way VMs were supported at this time, that meant that two CPU cores had to be available simultaneously to launch a 2-way VM. On a server with a total of only two cores, this meant that the VM could not be launched concurrently with any other process on the server. This would include the service console, the web interface, or any other process.

This requirement was reduced in ESX Server 3.0 through a process called relaxed co-scheduling. Effectively SMP VMs can have their vCPUs scheduled at slightly different times and idle vCPUs didn't necessarily have to be scheduled concurrently with running vCPUs

_{Bron: VMkernel Scheduler}

Strict coscheduling in ESX Server 2.x

Once any VCPU is skewed, all of its sibling VCPUs within the same SMP VM are forcibly descheduled ("co-stopped") to prevent additional skew. After a VM has been co-stopped, the next time any VCPU is scheduled, all of its sibling VCPUs must also be scheduled ("co-started"). This approach is called "strict" coscheduling, since all VCPUs must be scheduled simultaneously after skew has been detected.

_{Bron: Co-scheduling SMP VMs in VMware ESX Server}

Relaxed coscheduling in ESX Server 3.x

To be more precise, suppose an SMP VM consists of multiple VCPUs, including VCPUs A, B, and C. Suppose VCPU A is skewed, but VCPUs B and C are not skewed. Since VCPU A is skewed, VCPU B can be scheduled to run only if VCPU A is also co-started. This ensures that the skew between A and B will be reduced. But note that VCPU C need not be co-started to run VCPU B. As an optimization, the ESX scheduler will still try to co-start VCPU C opportunistically, but will not require this as a precondition for running VCPU B.

_{Bron: Co-scheduling SMP VMs in VMware ESX Server}

Hij zal het dus proberen om zodoende de virtuele hardware het idee te geven dat deze op dedicated fysieke hardware draait, maar het moet niet. Vanaf VMware ESX 3.x is het dus niet perse nodig om net zoveel fysieke cores beschikbaar te hebben als je VM aan cores heeft, al draait er maar één thread.

Mike2k schreef op maandag 07 juni 2010 @ 19:25:
Punt 1: HT uitzetten. Google maar eens, meestal een performance verlies.

Hier overigins nog wat informatie m.b.t. de werking van Hyperthreading in ESX Server.

Anyway: On topic, de TS al nieuws? VMware tools geholpen? Toch besloten er meer RAM in te gooien?

[ Voor 6% gewijzigd door wasted247 op 08-06-2010 21:35 ]

[Bor]

Als ik dat zo lees heb je gelijk idd. Vreemd gezien ik hier een tijd terug nog over heb gesproken met VMware Support waarbij mij het tegenovergestelde werd verteld. Ook in veel cursussen hoor je nog steeds dat alle vCPUs gelijktijdig gescheduled moeten worden.

[wasted247]

Bor de Wollef schreef op dinsdag 08 juni 2010 @ 22:26:
in veel cursussen hoor je nog steeds dat alle vCPUs gelijktijdig gescheduled moeten worden.

Klopt, mij is bij ESX 3.0 cursus ook verteld dat het zo is, terwijl de documentatie anders beweert.
_{Edit: het staat zelfs in het lesmatriaal van ESX 3.0.}

Overigens nog een interessante link met betrekking tot performance op ESX servers. Meer voor de TS

[ Voor 6% gewijzigd door wasted247 op 08-06-2010 23:10 ]