18
Geschwindigkeit VM Ware Maschinen
Hallo,
bei einer von uns genutzten Oracle DB Anwendung, die auf unseren virtuellen Windows 2003 R2 Maschinen (VM Ware Vsphere 5.1) als File und Aplicationserver läuft kommt es immer wieder zu Geschwindigkeitsproblemen. Jetzt stellt sich die Frage, ob es an der DB oder an der Hardware liegt. Ich habe mir die entscheidenen Komponenten angesehen und nachfolgende Werte erhalten :
VM Ware Anzeige Leistung
RAM 10 GB konfiguriert - genutzt werden im Durchschnitt 11,11 % bzw. 16,553 % (Betrachtung letzter Monat)
CPU 4vCPU konfiguriert - genutzt werden im Durchschnitt 9,23 % bzw. 12,31 % (Betrachtung letzter Monat)
Virtuelle Festplatten - Schreibrate von Max. 1254 KB/s / Latenz Schreibvorgänge 0 / Leserate Max 106 KB/s Latenz Lesevorgänge 3,539 Millisekunde
Schreibrate von Max. 5965 KB/s / Latenz Schreibvorgänge 0,167 / Leserate Max 154006 KB/s Latenz Lesevorgänge 3,706 Millisekunde
Platten 600 GB HP 6G SAS 10k im Host als local Storage.
Ich würde RAM und CPU als Bremse ausschließen, da mehr als genug vorhanden und nur gering in Nutzung.
Was habt ihr für Werte mit euren Platten ? Gibt es noch Sinnvolle Möglichkeiten per Konfiguration der VM etwas zu machen ? Resourcen reservieren etc. .... ?
Vielen Dank im Voraus.
nov
bei einer von uns genutzten Oracle DB Anwendung, die auf unseren virtuellen Windows 2003 R2 Maschinen (VM Ware Vsphere 5.1) als File und Aplicationserver läuft kommt es immer wieder zu Geschwindigkeitsproblemen. Jetzt stellt sich die Frage, ob es an der DB oder an der Hardware liegt. Ich habe mir die entscheidenen Komponenten angesehen und nachfolgende Werte erhalten :
VM Ware Anzeige Leistung
RAM 10 GB konfiguriert - genutzt werden im Durchschnitt 11,11 % bzw. 16,553 % (Betrachtung letzter Monat)
CPU 4vCPU konfiguriert - genutzt werden im Durchschnitt 9,23 % bzw. 12,31 % (Betrachtung letzter Monat)
Virtuelle Festplatten - Schreibrate von Max. 1254 KB/s / Latenz Schreibvorgänge 0 / Leserate Max 106 KB/s Latenz Lesevorgänge 3,539 Millisekunde
Schreibrate von Max. 5965 KB/s / Latenz Schreibvorgänge 0,167 / Leserate Max 154006 KB/s Latenz Lesevorgänge 3,706 Millisekunde
Platten 600 GB HP 6G SAS 10k im Host als local Storage.
Ich würde RAM und CPU als Bremse ausschließen, da mehr als genug vorhanden und nur gering in Nutzung.
Was habt ihr für Werte mit euren Platten ? Gibt es noch Sinnvolle Möglichkeiten per Konfiguration der VM etwas zu machen ? Resourcen reservieren etc. .... ?
Vielen Dank im Voraus.
nov
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 287403
Url: https://administrator.de/forum/geschwindigkeit-vm-ware-maschinen-287403.html
Ausgedruckt am: 22.12.2024 um 08:12 Uhr
18 Kommentare
Neuester Kommentar
Ist die Frage jetzt erledigt oder warum hast du sie selber gleich auf "Gelöst" geklickt ?! 
Hallo,
was laufen denn alles für VM auf dem Vsphere?
Sind alle VM auf dem selben physischen Speicher abgelegt?
Was die Virtuellen Platten für lese und Schreibwerte haben ist zweitrangig, die Frage ist haben die einen dedizierten physischen Plattenverbund oder müssen die sich mit anderen VMs den physischen Plattenverbund teilen?
Wenn die sich den teilen müssen, ist die Frage was da noch drauf läuft.
Wenn die Platten ausgelastet sind ist das ganze System nicht zu gebrauchen.
Die Frage ist auch ob die Systemplatten der VM einen geteilten oder dedezierten Physischen Verbund haben.
Gruß
Chonta
was laufen denn alles für VM auf dem Vsphere?
Sind alle VM auf dem selben physischen Speicher abgelegt?
Was die Virtuellen Platten für lese und Schreibwerte haben ist zweitrangig, die Frage ist haben die einen dedizierten physischen Plattenverbund oder müssen die sich mit anderen VMs den physischen Plattenverbund teilen?
Wenn die sich den teilen müssen, ist die Frage was da noch drauf läuft.
Wenn die Platten ausgelastet sind ist das ganze System nicht zu gebrauchen.
Die Frage ist auch ob die Systemplatten der VM einen geteilten oder dedezierten Physischen Verbund haben.
Gruß
Chonta
Hallo,
es laufen insgesamt vier Maschinen auf dem Host. Die beiden oben genannten Windows 2003 Server, ein Exchange Server und ein Terminalserver. Sonst nichts weiter. Alle Maschinene liegen auf den gleichen lokalen Platten, es ist ein großer Datenspeicher mit ca. 3,3 TB davon 2 TB noch frei.
es laufen insgesamt vier Maschinen auf dem Host. Die beiden oben genannten Windows 2003 Server, ein Exchange Server und ein Terminalserver. Sonst nichts weiter. Alle Maschinene liegen auf den gleichen lokalen Platten, es ist ein großer Datenspeicher mit ca. 3,3 TB davon 2 TB noch frei.
Hi,
eine Oracle DB auf einem Win2003 R2 als VM unter VMware? Ich wusste gar nicht, dass das von Oracle freigegeben war.
Die von Dir genannten Latenzen lesen sich erstmal nicht kritisch. Wobei man natürlich sagen muss, dass Exchange und TS zu den IOpS-Giganten gehören. Das hängt jetzt aber von der Nutzerzahl ab. Trotzdem würde ich es unbedingt vermeiden wollen, dass eine Oracle DB sich einen Storage mit einem Exchange oder einem TS teilen muss.
Weiterhin:
Die CPU-Angaben sind u.U. irreführend. Wenn da mehrere VM parallel auf einem Host laufen, was i.A. die Regel ist, dann sind die CPU Ready Zeiten viel interessanter. Eine VM mit 4vCPU muss u.U. lange auf CPU Zeit warten, weil sie diese erst bekommt, wenn 4 Core gleichzeitig verfügbar sind. Das tritt besonders dann ein, wenn man die physisch verfügbaren Core (ohne HT) durch die Summe aller vCPU überbelegt hat.
Suche mal nach "VMware CPU ready time".
eine Oracle DB auf einem Win2003 R2 als VM unter VMware? Ich wusste gar nicht, dass das von Oracle freigegeben war.
Die von Dir genannten Latenzen lesen sich erstmal nicht kritisch. Wobei man natürlich sagen muss, dass Exchange und TS zu den IOpS-Giganten gehören. Das hängt jetzt aber von der Nutzerzahl ab. Trotzdem würde ich es unbedingt vermeiden wollen, dass eine Oracle DB sich einen Storage mit einem Exchange oder einem TS teilen muss.
Weiterhin:
Die CPU-Angaben sind u.U. irreführend. Wenn da mehrere VM parallel auf einem Host laufen, was i.A. die Regel ist, dann sind die CPU Ready Zeiten viel interessanter. Eine VM mit 4vCPU muss u.U. lange auf CPU Zeit warten, weil sie diese erst bekommt, wenn 4 Core gleichzeitig verfügbar sind. Das tritt besonders dann ein, wenn man die physisch verfügbaren Core (ohne HT) durch die Summe aller vCPU überbelegt hat.
Suche mal nach "VMware CPU ready time".
Die Maschinen sind von den CPU 2 Sockets und 2 Kerne = 4 konfiguriert. Der Host hat 12 CPUs 2 Sockets 24 logische Prozessren. Insgesamt sind auf die Maschinene 20vCPUs verteilt. Unter VM Ware Leistung Messung CPU Bereit bekomme ich auf den letzten Monat einen Durchschnittswert von 92750,552 Millisekunden (Min 72999 / Max 136689), das ist bei beiden AS/FS ziemlich gleich.
Hallo,
alles auf dem selben Plattenspeicher und da wunderst Du Dich das die Performance teilweise einbricht?
Von was für einem Raidlevel reden wir?
Von wieviel Platten reden wir?
Du kannst höchstens versuchen noch das Caching der Datenbanken zu optimieren, das die so gut wie nie von der Platte lesen wollen...
Gruß
Chonta
alles auf dem selben Plattenspeicher und da wunderst Du Dich das die Performance teilweise einbricht?
Von was für einem Raidlevel reden wir?
Von wieviel Platten reden wir?
Du kannst höchstens versuchen noch das Caching der Datenbanken zu optimieren, das die so gut wie nie von der Platte lesen wollen...
Gruß
Chonta
8 Platten a. 600GB Raid 5 eine Spare
Ok, was ist dann schneller verfügbar, wenn ich bei der Anzahl der vCPUs bleiben will ?
2 virutelle Sockets mit 2 Kerne oder
1 virtueller Socket mit 4 Kernen ?
macht eine Erhöhung auf 1 /6 oder 2 / 3 denn überhaupt noch Sinn, wenn er erst auf die Resourcen warten muss ?
Es ist jedoch keine Resource überbelegt......
2 virutelle Sockets mit 2 Kerne oder
1 virtueller Socket mit 4 Kernen ?
macht eine Erhöhung auf 1 /6 oder 2 / 3 denn überhaupt noch Sinn, wenn er erst auf die Resourcen warten muss ?
Es ist jedoch keine Resource überbelegt......
Das Blech hat 2x 6-Core-CPU, richtig? HT darfst Du nicht mitrechnen, wenn man über Optimierung bzgl CPU ready time redet.
Also 12 physische Core.
Wenn Deine VM's insgesamt 20 vCPU belegen, dann ist das allein noch kein Problem. Nur wenn da mehrere VM's mit mit mehr als 2 vCPU sind, dann muss man hier aufpassen.
Also 12 physische Core.
Wenn Deine VM's insgesamt 20 vCPU belegen, dann ist das allein noch kein Problem. Nur wenn da mehrere VM's mit mit mehr als 2 vCPU sind, dann muss man hier aufpassen.
Ja 2 Sockets a. 6 Kerne. Exchange hat 2vCPU (1 / 2) die beiden Server mit der DB je 4 vCPU (beide 2 Sockets / 2 Kerne)
Hier halt meine Frage, ist es da besser das so mit 2 Sockets x 2 Kerne zu lassen oder würde 1 Socket x 4 Kerne besser sein ?
Oder sollte ich darüber nachdenken die beiden Server mit der DB auch auf 2vCPU runterzustufen, weniger vielleicht mehr ?
Hier halt meine Frage, ist es da besser das so mit 2 Sockets x 2 Kerne zu lassen oder würde 1 Socket x 4 Kerne besser sein ?
Oder sollte ich darüber nachdenken die beiden Server mit der DB auch auf 2vCPU runterzustufen, weniger vielleicht mehr ?
Hier halt meine Frage, ist es da besser das so mit 2 Sockets x 2 Kerne zu lassen oder würde 1 Socket x 4 Kerne besser sein ?
Nach meinem Kenntnisstand macht das keinen großen Unterschied, solange - jetzt sind wir wieder an diesem Punkt - das unter Berücksichtigung der konkreten Konfiguration aller anderen VM's passt.Auch hinsichtlich Lizenzierung kann das helfen. Manche Hersteller, deren Software per CPU lizenziert wird, akzeptieren es, wenn man die VM auf eine bestimmte Anzahl Sockets limitiert. Andere akzeptieren das nicht und sagen, es zählt nur, was das Blech hat. Oder man hat eine Anwendung, die entsprechend ihrer Lizenz komplett den Dienst verweigert, wenn die Socket-Anzahl überschritten wird. Hier kann mit dieser Einstellung zumindest rein technisch anpassen. Ob das dann auch rechtlich so Bestand hat, ist eine andere Frage.
Grundsätzlich: Ihr habt einen "Fileserver" für Eure Anwendung. Einen reinen Fileserver? Falls ja: Braucht der tatsächlich 4 vCPU?
2x "Oracle" á 4 macht 8 vCPU
1x Exchange á 2 macht 2 vCPU
Insgesamt also 10 vCPU
Wie sind die restlichen 10 belegt?
1x TS mit 4vCPU / 6 restlichen auf einzelne kleine Maschinen (Win7test / Win10test/VM vam/vm io analyser...) die aber zur Zeit nicht laufen, bzw. nur mal sporadisch um was zu testen...
1x TS mit 4vCPU
Auch 2x2 oder 1x4?
auch 2x2
Und in den VM-Eigenschaften unter "Ressourcen" steht bei "Erweiterte CPU" das HT-Sharing auf Standard, also "Alle" (oder "any")?
Ja genau, unter Ressourcen wurden keine Prioritäten für irgendwelche Maschinen eingetragen
Wenn da tatsächlich nur diese 4 genannten VM's laufen (die anderen sind ja aus, wenn ich das richtig verstanden habe), dann hättest Du von daher erstmal kein Problem mit der Core Überbuchung, es sein denn, da ist eine VM bei, welche exzessiv viel CPU beansprucht und diese teilt sich mit der betroffenen Oracle VM die HT "Cores" eines Cores. Dann kommt folgendes ins Spiel:
Rein theoretisch würden die drei 4-vCPU-VM's gleichmäßig über die Cores verteilt werden können, weil Du dafür genau 12 brauchst und eben 2x 6 Core hast. Solange es keine anderen Anforderungen gibt, versucht VMware die vCPUs der VM's genau so über die verfügbaren physischen Cores zu verteilen. Spätestens wenn der Exchange (1x2 vCPU) in Betrieb geht, wird er auch die zweiten HT "Cores" mitbenutzen. Dann teilen sich also jeweils 2 vCPU einen physischen Core. Und mit Teilen ist jetzt nicht das gemeint, dass (kontrolliert von VMware) abwechselnd je eine vCPU "Sprechzeit" bekommt. Nein, sie quatschen gleichzeitig jeweils in ihren HT "Core" rein und der physische Core darunter muss sehen wie er damit klar kommt. Das kann bei hochlastigen VM's schon mal dazu führen, dass eben eine ins Stottern kommt.
Wenn Du jetzt noch die anderen VM's (1x1 vCPU) alle anschaltest, dann sind die logischen Cores überbucht und es beginnt das "reguläre" CPU sharing von VMware. Dann kommt noch zusätzlich ins Spiel, dass nicht einzelne vCPU kurzzeitig angehalten werden sondern immer eine ganze VM. Wenn die VM dann wieder Redezeit bekommen soll, dann müssen dafür für jeder ihrer vCPU ein logischer Core (HT "Core") frei sein. Wenn nicht, dann muss die VM solange warten, bis das eben wieder gegeben ist. Diese Wartezeit läuft unter "ready time".
Angenommen, es ist die TS-VM, welche da Stress macht, dann wäre es eine Option, diese in zwei 2-vCPU-VM's aufzuteilen. Eine 2-vCPU-VM hat eine größere Wahrscheinlichkeit "dran zu kommen" und ist deshalb mit höherer Wahrscheinlichkeit schneller aus der Warteschlange raus. Dadurch kämen andere VM's wieder eher zum Zuge. usw. usw.
Langer Rede kurzer Sinn: Experimentiere mal mit der Anzahl der vCPU in den verschiedenen VM's. Du wärst nicht der Erste, der im guten Glauben mit der Aufstockung der Anzahl der vCPU eine VM effektiv verlangsamt hat.
E.
Rein theoretisch würden die drei 4-vCPU-VM's gleichmäßig über die Cores verteilt werden können, weil Du dafür genau 12 brauchst und eben 2x 6 Core hast. Solange es keine anderen Anforderungen gibt, versucht VMware die vCPUs der VM's genau so über die verfügbaren physischen Cores zu verteilen. Spätestens wenn der Exchange (1x2 vCPU) in Betrieb geht, wird er auch die zweiten HT "Cores" mitbenutzen. Dann teilen sich also jeweils 2 vCPU einen physischen Core. Und mit Teilen ist jetzt nicht das gemeint, dass (kontrolliert von VMware) abwechselnd je eine vCPU "Sprechzeit" bekommt. Nein, sie quatschen gleichzeitig jeweils in ihren HT "Core" rein und der physische Core darunter muss sehen wie er damit klar kommt. Das kann bei hochlastigen VM's schon mal dazu führen, dass eben eine ins Stottern kommt.
Wenn Du jetzt noch die anderen VM's (1x1 vCPU) alle anschaltest, dann sind die logischen Cores überbucht und es beginnt das "reguläre" CPU sharing von VMware. Dann kommt noch zusätzlich ins Spiel, dass nicht einzelne vCPU kurzzeitig angehalten werden sondern immer eine ganze VM. Wenn die VM dann wieder Redezeit bekommen soll, dann müssen dafür für jeder ihrer vCPU ein logischer Core (HT "Core") frei sein. Wenn nicht, dann muss die VM solange warten, bis das eben wieder gegeben ist. Diese Wartezeit läuft unter "ready time".
Angenommen, es ist die TS-VM, welche da Stress macht, dann wäre es eine Option, diese in zwei 2-vCPU-VM's aufzuteilen. Eine 2-vCPU-VM hat eine größere Wahrscheinlichkeit "dran zu kommen" und ist deshalb mit höherer Wahrscheinlichkeit schneller aus der Warteschlange raus. Dadurch kämen andere VM's wieder eher zum Zuge. usw. usw.
Langer Rede kurzer Sinn: Experimentiere mal mit der Anzahl der vCPU in den verschiedenen VM's. Du wärst nicht der Erste, der im guten Glauben mit der Aufstockung der Anzahl der vCPU eine VM effektiv verlangsamt hat.
E.
1
