Verständnisfrage pCPU und vCPU / Performance Probleme WS08R2

[nemail]

Hi!

stehe momentan etwas auf der Leitung - ich habe folgende Hardware:

HP ProLiant ML350 G5
2x Intel Xeon E5440 @ 2.83 GHz (also insg. 8 CPU Kerne)
18 GB RAM
4x 146GB 10k SAS Festplatten im RAID 10 an einem Smart Array P400 Controller mit 512 MB BBWC

Darauf läuft ein ESXi 4.1 Build 348481 mit den HP NMI Sourcing Treibern und den HP CIM Providern.

Als Gast habe ich eine virtuelle Maschine mit Windows Server 2008 R2, welche als Terminalserver fungiert und habe dort bei 20 Usern bereits massive CPU Performance Probleme. Ich habe der VM testweise zwei und vier vCPUs verpasst, bei vier vCPUs ist die Performance wesentlich besser.

Die CPU Auslastung im Gast steht die meiste Zeit im Bereich um 100%, in der Hostübersicht im VI Client sehe ich, dass immer nur ca. 25% (2 vCPUs) oder 50% (4 vCPUs) der gesamten CPU Leistung verwendet werden. Hieß es nicht mal dass auch zwei vCPUs alle verfügbaren CPU Kerne auslasten können weil der ESXi die Last auf alle verfügbaren CPUs aufteilt? Je nach Anzahl der vCPUs liegen 4-6 Kerne des Servers brach und stehen nicht zur Verfügung.

Hat jemand eine Idee warum nur max. vier der acht verfügbaren Kerne genutzt werden?

Danke und viele Grüße

[Tschoergez]

Hi!
Der ESX scheduled jede vCPU auf genau einem phys. Kern => eine VM mit 4 vCPU lastet max 4 physikalische Kerne (sog. logische CPUs lCPUs) aus.
Für details:
http://www.vmware.com/files/pdf/techpap ... le_ESX.pdf
(Oder das VMware Manage for Performance Training )


viele grüße,
jörg

[nemail]

danke für deine antwort! warum wird dann so oft empfohlen, einer vm nur 2 vcpus zu geben? wenn damit die hardware gar nicht richtig ausgelastet wird...?

[Tschoergez]

weil die vcpus einer VM immer gleichzeitig gescheduled werden (genau: ziemlich gleichzeitig, siehe kapitel relaxed co-scheduling).
Das bedeutet, eine 2vCPu-VM belegt jedesmal, wenn sie dran is mit rechnen 2 kerne, eine 4vcpu-VM 4 kerne. ganz egal, ob diese Kerne im Gast-OS überhaupt genutzt werden.

wenn Du also ne 4cpu VM baust, und die applikation darin aber nur einen Kern nutzt, verschenkst Du resourcen.

Eine Terminalserver-VM nutzt aber im normalfall mehrere Kerne ganz gut, drum ist das hier nicht so tragisch.
Probier aber doch mal, anstatt einer großen TS-VM mehrere kleine VMs zu bauen und die Benutzer darauf zu verteilen....
Das skaliert im Normalfall besser (scale-out instead of scale-up für die google recherche)

viele grüße,
jörg

[nemail]

das leuchtet ein, danke. zu dem schluss mit mehreren kleineren ts vms bin ich auch schon gekommen und ich fürchte, das wird auch die lösung mit dem geringsten aufwand sein um die performance probleme in den griff zu bekommen... oder fällt dir noch was ein? macht hyper-v das vielleicht anders bzw. für meine bedürfnisse besser? oder ist das bei allen hypervisoren in etwa gleich?

danke nochmal für deine hilfe!

[Tschoergez]

Ich denke nicht, dass Hyper-V sonderlich besser funktioniert... Auch das ist ein komplett virtualisierender Hypervisor (keine Paravirtualisierung), da wird performancetechnisch nicht viel um sein.

Es gibt noch ein paar Sachen, die bei Terminalserver evtl. für bessere Performance sorgen (aber bitte nur machen, wenn Du weißt, was Du tust und die "Nebenwirkungen" verstehst):
Memory Reservation setzen, Balloon-Treiber deaktivieren, ...
Es gibt auch ein paar Seiten im Internet darüber, die aber meist für alte ESX-Versionen gelten (und nicht mehr zwingend für die aktuelle 4.1er).
Die bekannteste ist wohl vom TS-"Guru" Brian Madden:
http://www.brianmadden.com/blogs/jeroen ... ase-2.aspx
http://virtrix.blogspot.com/2007/03/vmw ... oying.html

und ne passende VMworld session:
http://download3.vmware.com/vmworld/2006/med0115.pdf
(da gibts vielleicht was aktuelleres, einfach mal auf www.vmworld.com suchen (kostenlosen account anlegen) )

viele grüße,
jörg

[mangold]

vielleicht solltest du auch mal analysieren, warum dein Terminal Server auch bei 4 vCPUs es schafft auf 100% zu kommen, also welche Prozesse daran "schuld" sind. Dieses Verhalten ist untypisch (und unerwünscht) bei einem Terminal Server. Bei 20 Usern ist meist der Speicherverbrauch ein Problem, eher selten die CPUs, auch wenn sporadische CPU Spitzen immer da sein können. Hängt natürlich alles von den Anwendungen ab.

[Torsten.E]

Ich bin auch gerade dabei einen TS aufzusetzen, soll für ca. 10 - 12 User sein. Hauptnutzen klar Office-Programme. Da Excel und Access ziemlich Ressourcen ziehen, habe ich mal 64 GB RAM in die Kiste gebaut und ca. 40 für TS sowie 4 vCPU's vorgesehen.

Meine Frage ist (ohne Performance-Test), was kann ich noch so alles einstellen, veranlassen, dass der TS einfach flott läutt.

[Tschoergez]

Hi!

Meine Frage ist (ohne Performance-Test)

Die Antwort ist (ohne Performance-Test): It depends

Im Ernst, erstmal brauchen wir Infos: Wie groß ist der ESX, wie groß und wie viele VMs laufen sonst noch, HA/DRS im Einsatz, Storage, ...

Erst dann lässt sich das besser abschätzen. Aus dem Bauch raus würde ich die VM als viel zu groß ansehen (2vCPU und 24 GB zum Anfang, größer machen kostet ja nur einen Neustart).
Große VMs laufen nur gut, wenn die drunterliegenden ESX entsprechend groß sind, ansonsten ist das kontraproduktiv.

Lies Dir dazu mal das hier durch:
http://frankdenneman.nl/2010/12/impact- ... es-part-1/
(Der blog gehört überhaupt in den Feedreader )

Viele Grüße,
Jörg

[Torsten.E]

Gadacht ist eigentlich folgendes

2 baugleiche Kisten

Eine Kiste für Terminal-Server und Domain-Controller
auf der anderen Kiste SQL-Server, Exchange Server, CRM-Server, Fax-Server

Baugleich deshalb, dass wenn eine Kiste ausfällt, die andere Kiste solange alles komplett stemmen kann. Eventuell mit Performance-Verlusten für Terminal-Server, aber das ist bei 10-15 Leuten zu verkraften. D.h. Exchange- und SQL-Server sind sowieso nie augelastet. Auch brauch auch kein HA innerhalb der ESX. Mit einer max. Ausfallzeit von einem Tag kann ich leben. D.h. VM's auf der anderen Kiste manuell starten und wenn dann alles wieder läuft ist doch gut. Die VM's sollen alle auf einer SUN liegen, eben wegen dem Ausfall einer Kiste.

Bei der Dimensionierung für TS habe ich jetzt einfach mal in die "Vollen" gegriffen, da ich ja genug Ressourcen zur Verfügung habe (viel hilft viel) - war so mein 1. Ansatz, da mir ja auch niemand irgendwie sagen kann, was "vernünftig" ist.

Wenn 2 vCPU und 24 GB ausreichen, ist es mir auch recht, ich hab da nix dagegen.

[Torsten.E]

Kann es sein, dass wenn die vCPU's blöd aufgeteilt werden, dass diese praktisch dann Kerne von beiden CPU's verwendet und damit über den Front-Side Bus ziemlich langsam wird ?

Ich weis ja nicht wie die Kerne verwaltet werden, aber für mich währe sowas eine logische Erklärung.

[ch-hunn]

Ich habe die Erfahrung gemacht, dass mehrere kleinere TS auf dem selben Host spürbar besser performen als ein fetter.
Schon alleine wegen dem CPU Scheduling. Eine VM mit 4 CPUs kommt diese erst dann auch zugeiteilt, wenn auch wirklich 4 CPUs frei sind. Das heisst, je mehr CPUs eine VM hat, je grösser ist die Wahrscheinlichkeit, dass es hier Wartezeiten gibt.
Mehrere TS haben auch den Vorteil der besseren Wartbarkeit: Connectionbroker davorschalten und du kannst einen RD Sessionhost für Wartungszwecke offline nehmen ohne dass die User das mitbekommen.
Wenn ein User CPU lastige Dinge in seiner Session betreibt, beeinflusst dies alle anderen Sessions auf dem Sessionhost, jedoch nicht die Sessions auf weiteren Sessionhosts.

Besser scale-out als scale-up.

Gruss
Chregu

[Torsten.E]

Kann man die Kerne den vCPU's nicht fest zuordnen ?

Kern 1 u. 2 der 1. CPU an 1. vCPU
Kern 3 u. 4 der 1. CPU an 2. vCPU

und Kerne 1 bis 4 der 2 CPU an 3. vCPU

Dann ist das ganze Scheduling-Gedöns hinfällig

[Dayworker]

Könnte man, aber bist du dir über die Nebenwirkungen auch im klaren?
Eine 2v.CPU-VM wird nämlich erst dann Rechenzeit bekommen, wenn diese Kerne auch wieder frei sind. Ohne Affinität würde eine 2vCPU-VM ansonsten die nächsten 2 freien Kerne bekommen. Wenn du nicht gerade mehr Kerne als laufende VMs und vergebene CPU-Kerne im Einsatz hast, würdest du dir damit immer ein unnützes Nadelöhr schaffen und die VMs würden noch weit häufiger stocken.

Auf meinem VMserver1-Host mache ich das zwar, da ich für Boinc auf 3 CPU-Kernen auf Volllast rechne und auf dem vierten nur 2 Leerlauf-VMs habe. Damit sinkt die komplette Systemleistung nicht ab, da das Host-OS immer noch genügend freie CPU-Ressourcen hat. Aber sämtliche weitere auf diesen Kernen gestartete SW oder VM läuft dann im Zeitlupentempo ab während es ohne diese Affinität nicht dazu kommen würde.
Beim ESX(i) sieht es da natürlich etwas anders aus, da der große OS-Unterbau fehlt. Aber auch hier braucht der ESX(i) etwas an Rechner-Ressourcen. Nur fällt das beim normalen Round-Robin nicht auf...

[Torsten.E]

Jetzt überfordert es mich ohne Taschenrechner.
Also wie sollten die Kerne und vCPU's eingerichtet sein, bzw. auf was geachtet werden ?

Kannst Du mal ein Beispiel aufzeigen, oder noch besser, eines wo es falsch eingestellt ist und eines wo es richtig/besser eingerichtet ist ?

[Tschoergez]

Die CPU-Affinität sollte nicht (oder nur in ganz wenigen Ausnahmefällen) verwenden (macht u.a. vMotion unmöglich).

Der ESX verteilt automatisch die vCPUs so auf die logischen Kerne, dass das alles super funktioniert. Wenn notwendig, wird eine vCPU alle 20ms auf einen anderen Kern "umgezogen". Dabei werden vom ESX/ESXi auch Speicheranbindung, NUMA und Cache-Effekte einbezogen.

Lies Dir mal die ganzen Links durch, die in diesem Thread oben genannt wurden, v.a. das Whitepaper von VMware.

Viele Grüße,
Jörg

[Torsten.E]

Also einfach ein Rund-um-Sorglos-Packet, einfach nutzen und fertig, VMware schuftet es korrekt ab.

[Tschoergez]

Genau.
Nur eben mit den VMs so klein wie möglich anfangen (siehe Blogserie von Frank Denneman, Links oben).
Dann funktionieren die Mechanismen vom ESX (CPU und Memory!) am besten, weil der ESX am besten "jonglieren" kann mit kleinen VMs.

Die ganzen Mechanismen, vCPUs vs. pCPUs, virtual SMP Hyperthreading, CPU-Loadbalancing, Numa, Reservation&Limits und auch die für Speicher (außer Memory compression) gibts übrigens mindestens schon seit ESX 2.0.
D.h. die Mechanismen sind ausgereift. (Das Thema war der Grundgedanke bei der Gründung von VMware)

Viele Grüße,
Jörg

[ch-hunn]

Also einfach ein Rund-um-Sorglos-Packet, einfach nutzen und fertig, VMware schuftet es korrekt ab.

Jep. Ich würde behaupten, in 99.9 % aller Fälle ist das so.

Allerdings kann - vor allem bei RD Hosts - noch eine Menge herausgeholt werden:
- Virenschutz so konigurieren, dass nicht jede Session eine Instanz startet
- Unnötigen Schnikschnak in den Office Paketen deaktivieren
- Bei Roaming Profiles korrekte Folderredirection
- Wenn nicht wirklich benötigt, die Such - und Indexierungs Funktionen deaktivieren
- Multimedia Zeugs einschränken
etc pp

Gruss
Chregu

[Torsten.E]

Das habe ich mir schon auch so gedacht.

Virenschutz wie am besten einrichten ?
Welche Schnickschnacks sind das in den Office Paketen ?
Wo macht man da den Fehler bei den Folderredirections ?
Multimedia und Index ist klar.

Im Grunde genommen, jeden unnötigen Hintergrundbalast unterdrücken.

[Torsten.E]

Genau.
Nur eben mit den VMs so klein wie möglich anfangen (siehe Blogserie von Frank Denneman, Links oben).

Was ist "klein"
Wenn ich einen Terminal-Server für ca. 10-15 Leute brauche mit 2 vCPU und ca. 24 GB RAM ist das dann noch klein ?

[Tschoergez]

jo, ist noch klein!
Es gibt da keine festen Zahlen, es geht um die Methodik:
Klein anfangen. Und wenns zu langsam ist, die VM ein bisschen größer machen. Kostet nur einen Neustart...

Und nicht: Der ESX ist ja dick ausgestattet, also bau ich auch vorsichtshalber mal dicke VMs. das ist kontraproduktiv.

viele grüße,
jörg

[Torsten.E]

Da ich mit den Leistungsdaten noch nicht vertraut bin, welche Werte sollte ich wo beobachten und welchen Max-Bereich sollten diese Werte nicht übersteigen ?

Gibt es da etwas für "Einsteiger" und nicht gleich Formel 1 - Super-Diagnose-Abfragen

[ch-hunn]

Das habe ich mir schon auch so gedacht.

Virenschutz wie am besten einrichten ?

Das kommt auf den Virenschutz an. Z.B. kann bei TrendMicro das GUI bzw das "Steuerprogramm" in der Taskleiste deaktiviert werden.

Welche Schnickschnacks sind das in den Office Paketen ?

Das KlammerHundGummibärchen (OK, gibts nicht mehr) aber Z.B. Smart Tags, automatische Formatierungsvorschau, Cachemodus in Outlook deaktivieren, Uploadcenter etc

Wo macht man da den Fehler bei den Folderredirections ?

Auch die Benutzerordner umleiten und am besten noch eine Quota einrichten

Multimedia und Index ist klar.

Im Grunde genommen, jeden unnötigen Hintergrundbalast unterdrücken.

Genau. Je nach Applikation bieten sich hier weitere Möglichkeiten. Frag den Lieferanten.

hth
Chregu

EDIT: Typo