Performanceverlust durch Virtualisierung

[NilsK 2.957]

Moin,

 

wie sind denn die Disks in dem Host konfiguriert?

 

Gruß, Nils

[Weingeist 159]

Das einzige was ich gefunden habe um das Problem zu fassen wäre ein fehlerhaftes Allignment oder Blocksize der SSDs in Bezug auf die VMs.

Leider stecke ich da nicht so wirklich drin im Thema und bräuchte eure Hilfe, falls es das Problem sein sollte.

Die SSDs haben laut Raidcontroller eine Logical Sector Size von 512B und eine Physikal Sector Size von 4KB und gelten damit als 512e Laufwerke.

Angeblich kann es genau in dieser Konstellation , besonders beim Einsatz von SSDs (512e), Probleme mit der Performance geben , Stichwort RMW (read-modify-write) .

Vielen Dank schon einmal im voraus für jeden hilfreichen TIPP oder Ansatz der zu Lösung meines Problems führt !

 

Gruß

Michael

Naja, wie kamst den auf die Traumwerte? Mit dem gleichen Raid-Set oder? Also dürfte das eigentlich auszuschliessen sein.

 

Was ich mir noch vorstellen könnte: War vor HyperV auf dem Volume vielleicht das Schreibcache aktiviert und nun deaktiviert? Findest Du unter Laufwerke>Entsprechendes Laufwerk>Eigenschaften>Richtlinien. Das kann einen enormen Unterschied ausmachen.

 

Des weiteren spielt es noch eine Rolle ob dein vorhergenender Test ein Random-Zugriff oder vielleicht nicht doch ein Sequentieller Zugriff war und Du da was verwechselt hast. ;)

 

 

Dann gibts von vereinzelten Hersteller auch noch eine Drosselung der IO-Leistung durch den Controller die man nur aufheben kann, wenn man ne Zusatzlizenz kauft. Da ist die vielleicht nimmer aktiviert sofern vorhanden gewesen.

bearbeitet 4. September 2015 von Weingeist

[KingKompass 0]

Moin,

 

wie sind denn die Disks in dem Host konfiguriert?

 

Gruß, Nils

 

Hallo,

in dem Host werkeln:

 

2x100GB SSD Intel S3700 als Raid 1       => Parent Partition

4x400GB SSD Intel S3700 als Raid 10     => Child Partition (mit den 2VMs)

 

Der Controller ist auf Write Back mit BBU gestellt , also arbeite mit Cache und Backup Batterie.

 

Gruß

Michael

[NilsK 2.957]

Moin,

 

also, beim nächsten Mal sparst du dir die SSDs für die Parent Partition. Dort brauchst du keine I/O-Performance.

 

Ich denke, das ist auf jeden Fall etwas für den Support. Aus den Beschreibungen ist nichts erkennbar, was den Durchsatz so einschränken sollte.

 

Gruß, Nils

[KingKompass 0]

Naja, wie kamst den auf die Traumwerte? Mit dem gleichen Raid-Set oder? Also dürfte das eigentlich auszuschliessen sein.

 

Was ich mir noch vorstellen könnte: War vor HyperV auf dem Volume vielleicht das Schreibcache aktiviert und nun deaktiviert? Findest Du unter Laufwerke>Entsprechendes Laufwerk>Eigenschaften>Richtlinien. Das kann einen enormen Unterschied ausmachen.

 

Des weiteren spielt es noch eine Rolle ob dein vorhergenender Test ein Random-Zugriff oder vielleicht nicht doch ein Sequentieller Zugriff war und Du da was verwechselt hast. ;)

 

 

Dann gibts von vereinzelten Hersteller auch noch eine Drosselung der IO-Leistung durch den Controller die man nur aufheben kann, wenn man ne Zusatzlizenz kauft. Da ist die vielleicht nimmer aktiviert sofern vorhanden gewesen.

 

Hallo,

ja, das ist das gleiche Raid Set und auch auf dem gleichen Host, es hat sich nichts an der Hardware geändert.

Der Server wurde im Mai beim Kunden aufgebaut und eingerichtet (noch ohne HyperV Rolle), also Laufwerk C: Raid 1 (2x100GB SSD) und Laufwerk D: Raid 10 (4x400GB SSD)

kurz danach habe ich den PingFile Test der Datev durchgeführt und diese "Traumwerte" erreicht und war zufrieden und habe mir über das Storage keine weiteren Sorgen mehr gemacht.

In den folgenden Wochen kam dann die HyperV Rolle dazu und ich habe die beiden VMs eingerichtet (VM1: reiner DC / VM2: Datevserver File&SQL).

Habe bei der Einrichtung der beiden VMs nicht negatives gemerkt , habe aber auch keine weiteren Benchmarks laufen lassen.  

Dann kam letzte Woche der finale Umzug der Datevsoftware und die Leistung war im Keller, habe es aber auch erst bemerkt als die Benutzer über starke Verzögerungen beim Aufrufen der Progs berichteten.

Der Schreibcache des Controller war und ist die ganze Zeit aktiviert gewesen auf beiden Arrays.

Der Schreibcache in den Windowseinstellungen  ist sowohl auf dem Host als auch in den VMs aktiv.

Es wäre schön wenn ich mich bei der Geschichte vertan hätte, aber es ist exakt der gleiche Test einmal ohne HyperV Rolle und einmal mit.

Ich hatte die Ergebnisse in einem der Posts vorher schon gepostet und dort auch die Werte vom Server ohne HyperV Rolle also Stand Mai mit aufgeführt. 

Das mit der Lizenz wäre noch eine kleine Möglichkeit , aber die knapp 2000 Mbit/s sind auch im Vergleich zu zwei anderen Systemen extrem niedrig (7000 und 8000 Mbit/s mit normalen SAS Platten).

Trotzdem Danke für die Anregungen !

 

Gruß

Michael

Moin,

 

also, beim nächsten Mal sparst du dir die SSDs für die Parent Partition. Dort brauchst du keine I/O-Performance.

 

Ich denke, das ist auf jeden Fall etwas für den Support. Aus den Beschreibungen ist nichts erkennbar, was den Durchsatz so einschränken sollte.

 

Gruß, Nils

 

Hallo,

ich glaube das würde ich mir wirklich beim nächsten Mal sparen , wir wollten nur absolut kein Risiko eingehen.

Ich habe heute mit der Datev telefoniert und am kommenden Mittwoch wird das System komplett vom Datevsupport unter die Lupe genommen.

Vielleicht haben die noch eine bahnbrechende Idee oder Erklärung.

Wie gesagt die Sektorgrößenproblematik ist das einzige was ich gefunden habe was passen könnte , leider bin ich da noch nicht so ganz durchgestiegen.

Trotzdem vielen Dank für deine Unterstützung.

Falls der Fehler gefunden wird gibt es natürlich ein Feedback.

 

Gruß

Michael

Hallo,

werde auf jedenfall noch eure Empfehlung mit den 4vCPUSs und 32GB RAM für

die Datev VM umsetzten, leide hatte ich noch nicht die Möglichkeit die VM herunterzufahren.

Ich denke das ich das am Wochenende schaffen werde und berichte dann.

Schön wäre es ja, wenn diese Änderung einen Performanceschub bringen würde

und der Benchmark vielleicht einfach nur falsche Ergebnisse anzeigt.

 

Gruß und ein schönes Wochenende

Michael

[testperson 1.707]

Hi,

 

sollte man bei SSDs nicht eher auf Write Through anstelle auf Write Back setzen? Wobei das hier aber auch nicht auf die Performance schlagen sollet.

Finde grade leider die Quelle nicht mehr wo ich das gelesen hatte.

 

Gruß

Jan

[KingKompass 0]

Moin,

 

mehr als 4 vCPU würde ich der VM jedenfalls nicht geben.

 

Und, wie gesagt, schau nach der VMQ-Konfiguration.

 

Gruß, Nils

 

Hallo,

am Wochenende konnte ich die VM herunterfahren und ihr anstatt 6vCPUs nur 4vCPUs zuordnen und

auch den Arbeitsspeicher habe ich von 50GB RAM auf 30GB RAM heruntergeschraubt.

Am Montag habe ich dann die ersten Feedbacks der User bekommen und der Tenor war eindeutig ,

es ist spürbar langsamer geworden.

Der Kunde wünscht sich wieder auf die Datevempfehlung (6vCPU / 50 GB RAM) zurückzukehren und wir

warten bis sich am Mittwoch der Datevsupport aufschaltet.

Ich werde dann berichten.

 

Gruß

Michael

Hi,

 

sollte man bei SSDs nicht eher auf Write Through anstelle auf Write Back setzen? Wobei das hier aber auch nicht auf die Performance schlagen sollet.

Finde grade leider die Quelle nicht mehr wo ich das gelesen hatte.

 

Gruß

Jan

Hallo,

ich kenne das von magnetischen Platten nur so, das der Performancegewinn durch "Write Back" erzielt wird , so das nicht immer erst

die Daten zurückgeschrieben und quittiert werden müssen, sondern das diese Aktion mit dem Cache überbrückt wird.

Ich dachte das wäre bei SSDs das gleiche Prinzip, da der Cache wahrscheinlich immer noch schneller ist als die SSDs.

Werde es aber zur Sicherheit auch noch einmal gegenprüfen.

Danke !

 

Gruß

Michael

[DocData 85]

Wie hoch sind die CPUs getaktet?

[Nobbyaushb 1.475]

Wenn ich die Eckdaten der VM für die Datev lese, finde ich das schon stark überzogen.

 

Gut, die neue Version ist nicht der Renner, aber unser (virtueller) Server läuft mit 6 vCPU und 24G RAM absolut flüssig.

 

Hast du an der virtuellen Hyper-V Netzwerkkarte mal das Offloading abgeschaltet? Das wird der Techniker auch prüfen.

 

Wir haben einen weiteren Server (auch VM) als RDS Host nur für die Datev laufen, der hat 8 vCPU und 16G RAM

 

;)

 

PS: früher war das mit ähnlichen Eckdaten physisch, seit der Virtualisierung ist das gefühlt 3* so schnell.

 

Achja - da arbeiten 16 User drauf.

bearbeitet 8. September 2015 von Nobbyaushb

[KingKompass 0]

Wie hoch sind die CPUs getaktet?

 

Hallo,

das sind 2x Intel Xeon E5-2623 v3 (Quadcore mit 3,0GHz und im Turbo bei 3,5GHz).

Ich hatte mir gedacht lieber einen höheren Taktwert pro Kern als zu viele Kerne mit sehr niedriger Taktfrequenz. 

 

Gruß Michael

Wenn ich die Eckdaten der VM für die Datev lese, finde ich das schon stark überzogen.

 

Gut, die neue Version ist nicht der Renner, aber unser (virtueller) Server läuft mit 6 vCPU und 24G RAM absolut flüssig.

 

Hast du an der virtuellen Hyper-V Netzwerkkarte mal das Offloading abgeschaltet? Das wird der Techniker auch prüfen.

 

Wir haben einen weiteren Server (auch VM) als RDS Host nur für die Datev laufen, der hat 8 vCPU und 16G RAM

 

;)

 

PS: früher war das mit ähnlichen Eckdaten physisch, seit der Virtualisierung ist das gefühlt 3* so schnell.

 

Achja - da arbeiten 16 User drauf.

 

Hallo,

das Offloading hatte ich noch nicht probiert.

In der Kanzlei hier arbeiten 48 Benutzer auf drei RDS Hosts, alle noch physischer Natur, verteilt. 

 

Gruß

Michael

Hallo,

hatte heute den geplanten Termin mit der Datev und durch Zufall habe ich in der Mittagspause (Wartungsfenster in der Kanzlei)

den Host noch einmal durchgestartet , da ich mir alle BIOS Einstellungen anschauen und abfotografieren wollte, um für eventuelle

Nachfragen gerüstet zu sein.

Die Fotos habe ich dann alle gemacht (HT deaktiviert , Energiesparmodus auf Performance , ...) und der Host ist wieder hochgefahren,

nur reagierte das System merklich performanter als zehn Minuten davor.

Da ich noch fünf Minuten hatte, bis die User sich wieder anmeldeten, habe ich den PingFile Test der Datev noch einmal laufen

lassen , eigentlich ohne große Erwartung, aber siehe da, der Wert lag bei 13.402 MBit/s (Vortag noch bei 1.953 MBit/s) und damit völlig im oder über Soll.

Der sehr nette  Datevmitarbeiter meldete sich dann auch 20 Minuten später bei mir und wollte mir sagen, dass er Anhand der gesammelten Logs sehen kann, das mit den Leistungswerten des Storages etwas nicht stimmt, hat aber leider selbst keine passende Erklärung oder Lösung parat, eventuell noch einmal einen aktuellen Treiber und Firmware für den Raid-Controller aufspielen.

Nach ein paar Sekunden Gespräch konnte ich ihm dann auch endlich Entwarnung geben und habe ihm den heutigen Ablauf erklärt.

Zur Sicherheit haben wir noch einen Rechnungswesen Leistungsindex laufen lassen (Minibenchmark - eines der Hauptprogramme der Kanzlei) und auch diese Werte waren wieder sehr gut und über Norm. Falls diese Kennzahlen jemand zum Vergleich haben möchte,

bitte einfach melden. Ich bin dann noch eine Runde durch die Kanzlei gelaufen und die einzelnen Teams gefragt, ob sie etwas merken und von vielen kam tatsächlich das Feedback das es wesentlich schneller läuft und solche Nachrichten höre ich sonst sehr selten , gerade in

Bezug auf Datevsoftware :-)

Der einzige Wehrmutstropfen ist, dass ich noch nicht den Grund für diesen Aussetzer des Storagesystems kenne, denn einen Neustart

des Hosts hatte ich bereits direkt nach dem Serverumzug durchgeführt und der hatte noch nicht zu einer Besserung geführt.

Der zweite Neustart hat jetzt aber die gewünschte Besserung gebracht,  die auch dringend nötig war.

Am  Freitag kommt schon das nächste größere Datevupdate (DVD9.0), dann kann ich den Server noch einmal herunterfahren und

die letzten Logs per UEFI auslesen und an Intel schicken, vielleicht haben die noch eine Erklärung für das Verhalten des Storagesystems.

Danach werde ich dann zur Sicherheit noch einmal den Benchmark laufen lassen, aber ich bin vorsichtig optimistisch.

 

Noch einmal vielen Dank an alle, die bei der Fehlersuche mitgeholfen haben und mich mit vielen wichtigen Infos und Lösungsvorschlägen versorgt haben. :jau:  :jau:  :jau:  :thumb1:  :thumb1:  :thumb1:

 

Gruß

vom "glücklichen" Michael :D

[NorbertFe 2.061]

Wäre jetzt ja mal interessant, wenn du der VM nicht diese "wahrscheinlich" überzogenen Datev-Ressourcen zugestehst, wie es dann aussieht. ;)

[testperson 1.707]

Ich behaupte es läuft ähnlich flüssig und wird sich kaum ändern wenn man der VM wieder mehr CPU / RAM zuteitl ;) Zumindest wird es nicht derart schneller, dass es das mehr an Ressourcen rechtfertigt. (Sofern man einige hier im Thread benannte Dinge beachtet).

[Dominik Weber 19]

Das Problem mit den Energieeinstellungen ... da ist schon mancher drübergestolpert ...

[KingKompass 0]

Wäre jetzt ja mal interessant, wenn du der VM nicht diese "wahrscheinlich" überzogenen Datev-Ressourcen zugestehst, wie es dann aussieht. ;)

 

Hallo,

ich kann noch nicht sagen ob ich am Wochenende dazu komme , aber ich werde es mal in einer ruhigen Minute ausprobieren und dann den Rechnungswesen Leitungsindex vergleichen bzw die gefühlte Geschwindigkeit.

 

Gruß

Michael

Ich behaupte es läuft ähnlich flüssig und wird sich kaum ändern wenn man der VM wieder mehr CPU / RAM zuteitl ;) Zumindest wird es nicht derart schneller, dass es das mehr an Ressourcen rechtfertigt. (Sofern man einige hier im Thread benannte Dinge beachtet).

 

Hallo,

ich schließe es auch nicht aus , es wäre um so besser , so könnte ich eventuell noch einen weiteren WTS auf diesem Host laufen lassen :-)

 

Gruß

Michael

Das Problem mit den Energieeinstellungen ... da ist schon mancher drübergestolpert ...

 

Hallo,

nur um das noch einmal klarzustellen , die Energieeinstellungen im BIOS und auch in Windows waren bereits richtig eingestellt, 

es war lediglich der zweite Neustart des Hosts der die Besserung brachte.

 

Gruß

Michael

[testperson 1.707]

Ich meine mich an Server zu erinnern, die nach Anpassung der Energie- / Prozessorkonfiguration (Bzw. gewisser Einstellungen im BIOS) zwingend noch einen Reboot oder gar ein Power-Off / Power-On brauchten ;)