9
Tiered Storage Spaces Performance Problem in virtueller Maschine
Hallo,
ich habe ein kleines Performance Problem mit einer recht winzigen Hyper-V / TSS Umgebung.
Hier eine "primitive" Auswertung der Performance (TSS 2x120GB SSD + 4x2TB HDD mirror):
Auf dem Hyper-V. Sieht ganz gut aus. Auch wenn so ein Test direkt auf einem TSS nicht wirklich präzise ist, das ist mir klar:
Und hier innerhalb der VM. die VHXD (60 GB) ist übrigens komplett an den SSD Tier gepinnt und angeblich optimiert, also ergibt das doppelt keinen Sinn:
Reproduzierbar, sieht immer sehr Ähnlich aus, die Hotspots sind immer an gleicher stelle.
Es laufen noch vier andere VMs auf dem Hyper-V, ebenfalls auf dem TSS Volume. Diese sind so weit ohne Performance-Probleme bzw. haben nix zu tun und brauchen keine Power. Getestet hab ich die jetzt nicht.
Wenn ich jetzt innerhalb der VM wenigstens annähernd an die Performance des HDD Tiers käme, wäre das ja mal schon was. Aber wie zu sehen ist, habe ich entweder SSD Speed an den Hotspots und außerhalb davon 50-75 MB/s. Wenn ich wenigstens um die 150 bekäme... Allerdings wird mir innerhalb der VM 0,4ms Zugriffszeit angezeigt, was dafür spricht, dass wir uns komplett auf dem SSD Tier bewegen. Der komplette TSS hat 15ms.
Vieleicht weniger wichtig, aber ich erwähne es mal:
Auf der besagten VM läuft eine Software namens Orgamax, im Hintergrund nutzt diese wohl eine Firebird-DB. Und die ist brechend langsam. Alle VMs wurden von Hardware portiert. Die besagte war vorher auch schon nicht wirklich schnell bei der DB, wohl aus anderen Gründen. Ansonsten ist die Maschine recht normal performant. Auch die hohe CPU Last durch die DB habe ich versucht zu kompensieren, von 2 Cores über 3 auf 4 (was ja auch manchmal kontraproduktiv ist bei so vielen VMs, ich weis). Nur minimaler Gewinn...
Ich bin am Überlegen, ob ich diese VM komplett auf einen zusätzlichen SSD RAID1 lege... Aber das soll ja nicht im Sinne des Erfinders sein... Woher kommen meine Einbrüche (immer an den gleichen stellen)?
Danke schon mal!
ich habe ein kleines Performance Problem mit einer recht winzigen Hyper-V / TSS Umgebung.
Hier eine "primitive" Auswertung der Performance (TSS 2x120GB SSD + 4x2TB HDD mirror):
Auf dem Hyper-V. Sieht ganz gut aus. Auch wenn so ein Test direkt auf einem TSS nicht wirklich präzise ist, das ist mir klar:
Und hier innerhalb der VM. die VHXD (60 GB) ist übrigens komplett an den SSD Tier gepinnt und angeblich optimiert, also ergibt das doppelt keinen Sinn:
Reproduzierbar, sieht immer sehr Ähnlich aus, die Hotspots sind immer an gleicher stelle.
Es laufen noch vier andere VMs auf dem Hyper-V, ebenfalls auf dem TSS Volume. Diese sind so weit ohne Performance-Probleme bzw. haben nix zu tun und brauchen keine Power. Getestet hab ich die jetzt nicht.
Wenn ich jetzt innerhalb der VM wenigstens annähernd an die Performance des HDD Tiers käme, wäre das ja mal schon was. Aber wie zu sehen ist, habe ich entweder SSD Speed an den Hotspots und außerhalb davon 50-75 MB/s. Wenn ich wenigstens um die 150 bekäme... Allerdings wird mir innerhalb der VM 0,4ms Zugriffszeit angezeigt, was dafür spricht, dass wir uns komplett auf dem SSD Tier bewegen. Der komplette TSS hat 15ms.
Vieleicht weniger wichtig, aber ich erwähne es mal:
Auf der besagten VM läuft eine Software namens Orgamax, im Hintergrund nutzt diese wohl eine Firebird-DB. Und die ist brechend langsam. Alle VMs wurden von Hardware portiert. Die besagte war vorher auch schon nicht wirklich schnell bei der DB, wohl aus anderen Gründen. Ansonsten ist die Maschine recht normal performant. Auch die hohe CPU Last durch die DB habe ich versucht zu kompensieren, von 2 Cores über 3 auf 4 (was ja auch manchmal kontraproduktiv ist bei so vielen VMs, ich weis). Nur minimaler Gewinn...
Ich bin am Überlegen, ob ich diese VM komplett auf einen zusätzlichen SSD RAID1 lege... Aber das soll ja nicht im Sinne des Erfinders sein... Woher kommen meine Einbrüche (immer an den gleichen stellen)?
Danke schon mal!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 325552
Url: https://administrator.de/contentid/325552
Printed on: April 24, 2024 at 12:04 o'clock
9 Comments
Latest comment
Gerade noch mal gegengecheckt bei einer anderen VM:
OK, thin provision, klar, was hier so schnell ist, rennt durch den Cache. Aber auch die langsamen Bereiche sind schneller als bei der anderen VM.
Die HDD der besagten ist zwar auch thin provisioned, aber eigentlich voll, also 50 GB belegt. (auch durch gelöschte Dateien, innerhalb der VM ist Platz).
Das sieht mir hier fast so aus, als ob das anpinnen an den SSD Tier nicht funktioniert. Vieleicht muss ich mein problem auch ganz wo anders suchen. Aber btte nicht davon abhalten lassen, mir Tipps zu geben
OK, thin provision, klar, was hier so schnell ist, rennt durch den Cache. Aber auch die langsamen Bereiche sind schneller als bei der anderen VM.
Die HDD der besagten ist zwar auch thin provisioned, aber eigentlich voll, also 50 GB belegt. (auch durch gelöschte Dateien, innerhalb der VM ist Platz).
Das sieht mir hier fast so aus, als ob das anpinnen an den SSD Tier nicht funktioniert. Vieleicht muss ich mein problem auch ganz wo anders suchen. Aber btte nicht davon abhalten lassen, mir Tipps zu geben
Mahlzeit,
wer auch immer Du bist.
Hast Du mit dem Hersteller der Software abgeklärt, ob diese in einer VM läuft, bzw. ob das supportet ist ?
Ich hab auf der Herstellerseite etwas geschaut, aber keine Angaben gefunden, das virtualisierung unterstützt wird.
Wenn vom Hersteller nicht unterstützt, warum sollte das performant funktionieren ?
Gruß
Anton
wer auch immer Du bist.
Hast Du mit dem Hersteller der Software abgeklärt, ob diese in einer VM läuft, bzw. ob das supportet ist ?
Ich hab auf der Herstellerseite etwas geschaut, aber keine Angaben gefunden, das virtualisierung unterstützt wird.
Wenn vom Hersteller nicht unterstützt, warum sollte das performant funktionieren ?
Gruß
Anton
Hi,
sorry, ich bin der Matthias
Ja, wurde sogar vom Support gelobt, dass ich es so umgesetzt habe... Aber ansonsten sind die auch Ideelos...
naja, selbst wenn der Hersteller es nicht unterstützen würde, ist das ja noch keine Gegenanzeige für performantes Laufen, denke ich...
Gruß,
Matthias
sorry, ich bin der Matthias
Ja, wurde sogar vom Support gelobt, dass ich es so umgesetzt habe... Aber ansonsten sind die auch Ideelos...
naja, selbst wenn der Hersteller es nicht unterstützen würde, ist das ja noch keine Gegenanzeige für performantes Laufen, denke ich...
Gruß,
Matthias
Sers,
Sorry, aber Orgamax & Virtualisierung beissen sich leider massiv.
Ich betreibe selbst seit über 5 Jahren mehrere Mandanten, über mehrere Systeme verteilt.
Die Version 17 habe ich bisher noch nicht angerührt. Als langjähriger Anwender musste man leider lernen zumindest bis März mit dem produktiven Einsatz zu warten ....
Werde sie wohl auch nicht mehr anrühren, da wir aktuell ein Nachfolgesystem einführen, aber das ist am Thema vorbei.
In den 5 Jahren habe ich Orgamax auf folgenden Systemen betrieben bzw. getestet:
Auf den T100, 2900, und T320ern lief Orgamax nativ, auf den R720 und R730ern lief es als VM (OS 2008R2, 2012R2).
Im Falle der VMs lagen die Festplatte in VHDX Dateien, und nicht direkt als LUNs durchgeleitet (notwendig wg. Snapshots, Hyper-V Replica, etc.)
Das unerwartete Ergebnis: Am schnellsten rennt der noch immer im Einsatz befindliche T100. Und der ist auch noch ein kleiner RDSH on top.
Was ist da also los? Orgamax strukturiert seine DB Abfragen und Zugriffe absolut seriell. Bei IOPS und CPU Messungen sind also NUR Single Thread Zugriffe relevant. Und da immernoch viel zu viele Berechnungen auf den Clients stattfinden ist auch die Netzwerkbandbreite und vor allem Latenz (auch hier serielle Abarbeitung!) relevant.
Auch findet ein Lese-Caching kaum bis überhaupt nicht statt. Über Caching bei Schreibvorgängen reden wir erst garnicht.
Beim Verändern der Firebird Einstellungen verweigert Deltra den Support, ist also auch keine Lösung.
Am Besten wäre es, Orgamax überhaupt nicht zu virtualisieren. Wenn du es virtualisieren musst, dann solltest du dir überlegen eine PCIe SSD anzuschaffen, und diese direkt in die Orgamax VM durchzureichen. Bitte dran denken, dass Orgamax seit Version 16 (bzw. 15.8 oder so) seine Nutzdaten standardmäßig unter C:\ProgramData ablegt.
Mein Rat: Schaff dir einen kleinen Server an, mit viel GHz, ausreichend RAM, und einem flotten SSD Unterbau.
Wirklich perfekt lief Orgamax 16 als ich es zum Spaß nativ auf einem der R730 mit 2x E5-2637v und 2x PX04SM SSD im Raid 1 auf Windows Server 2012R2 installierte, auf diesem Server dann noch die RDSH Rolle aktivierte, und den Orgamax Client als RemoteApp bereitstellte. Damit viel dann nämlich auch noch die Netzwerklatenz weg.
Grüße,
Philip
Sorry, aber Orgamax & Virtualisierung beissen sich leider massiv.
Ich betreibe selbst seit über 5 Jahren mehrere Mandanten, über mehrere Systeme verteilt.
Die Version 17 habe ich bisher noch nicht angerührt. Als langjähriger Anwender musste man leider lernen zumindest bis März mit dem produktiven Einsatz zu warten ....
Werde sie wohl auch nicht mehr anrühren, da wir aktuell ein Nachfolgesystem einführen, aber das ist am Thema vorbei.
In den 5 Jahren habe ich Orgamax auf folgenden Systemen betrieben bzw. getestet:
- Xeon X3323 mit 16GB RAM und einem Raid 10 (Perc6 mit 256MB) aus 4x 146GB 15k SAS HDDs auf Windows Server 2008, 2008R2, und 2012 (Dell T100)
- Xeon 2x E5450 mit 24GB RAM und einem Raid 5 (Perc5 mit 256MB) auf 8x 300GB 15k SAS HDDs auf Windows Server 2008, 2012 und 2012R2 (Dell 2900)
- Xeon 2x E5-2630 mit 64GB RAM, als Hyper-V VM auf einem Raid1 (Perc710 mit 1GB) aus 2x Samsung 240GB SM843T SSDs auf Hyper-V Server 2012, 2012R2 und 2016 (Dell R720)
- Xeon 2x E5-2637v4 mit 128GB RAM, als Hyper-V VM auf einem Clustered Tiered Storage Spaces Pool aus 4x PX04SM 800GB (2w-Mirror) und 16x 2TB NL-SAS (3w-Mirror) auf Basis Windows Server 2012R2 und 2016 (Dell R730 & MD1420)
Auf den T100, 2900, und T320ern lief Orgamax nativ, auf den R720 und R730ern lief es als VM (OS 2008R2, 2012R2).
Im Falle der VMs lagen die Festplatte in VHDX Dateien, und nicht direkt als LUNs durchgeleitet (notwendig wg. Snapshots, Hyper-V Replica, etc.)
Das unerwartete Ergebnis: Am schnellsten rennt der noch immer im Einsatz befindliche T100. Und der ist auch noch ein kleiner RDSH on top.
Was ist da also los? Orgamax strukturiert seine DB Abfragen und Zugriffe absolut seriell. Bei IOPS und CPU Messungen sind also NUR Single Thread Zugriffe relevant. Und da immernoch viel zu viele Berechnungen auf den Clients stattfinden ist auch die Netzwerkbandbreite und vor allem Latenz (auch hier serielle Abarbeitung!) relevant.
Auch findet ein Lese-Caching kaum bis überhaupt nicht statt. Über Caching bei Schreibvorgängen reden wir erst garnicht.
Beim Verändern der Firebird Einstellungen verweigert Deltra den Support, ist also auch keine Lösung.
Am Besten wäre es, Orgamax überhaupt nicht zu virtualisieren. Wenn du es virtualisieren musst, dann solltest du dir überlegen eine PCIe SSD anzuschaffen, und diese direkt in die Orgamax VM durchzureichen. Bitte dran denken, dass Orgamax seit Version 16 (bzw. 15.8 oder so) seine Nutzdaten standardmäßig unter C:\ProgramData ablegt.
Mein Rat: Schaff dir einen kleinen Server an, mit viel GHz, ausreichend RAM, und einem flotten SSD Unterbau.
Wirklich perfekt lief Orgamax 16 als ich es zum Spaß nativ auf einem der R730 mit 2x E5-2637v und 2x PX04SM SSD im Raid 1 auf Windows Server 2012R2 installierte, auf diesem Server dann noch die RDSH Rolle aktivierte, und den Orgamax Client als RemoteApp bereitstellte. Damit viel dann nämlich auch noch die Netzwerklatenz weg.
Grüße,
Philip
Nette Abhandlung, danke Dir!
Also ne extra PCIe SSD wäre vieleicht noch eine Option, und / oder Orgamax dann auf dem Hyper-V lokal installiert, ist Gott sei Dank kein Core... Remoteapp fällt flach bei uns, Lizenzrechtlich. Obwohl, ggf. ein paar RDP Lizenzen wären ja machbar.
Aber nichts desto Trotz habe ich ja meine "dilletantischen" Performance Tests der Festplatten, welche doch echt merkwürdig aussehen...
Gruß,
Matthias
Also ne extra PCIe SSD wäre vieleicht noch eine Option, und / oder Orgamax dann auf dem Hyper-V lokal installiert, ist Gott sei Dank kein Core... Remoteapp fällt flach bei uns, Lizenzrechtlich. Obwohl, ggf. ein paar RDP Lizenzen wären ja machbar.
Aber nichts desto Trotz habe ich ja meine "dilletantischen" Performance Tests der Festplatten, welche doch echt merkwürdig aussehen...
Gruß,
Matthias
Ein paar Fragen:
- was sind das für SSDs?
- Cache Config der Disks?
- Wie hast du die SSD Kapa aufgeteilt?
- Laufen die SSDs als Mirror? (PowerShell: Get-StorageTier)
- Write Cache Config? (PowerShell: Get-VirtualDisk | ft FriendlyName,Size,ReadCacheSize,WriteCacheSize)
1. Die SSDs sind zwei Samsung PM863 Enterprise SSDs
2. einmal Std. also 1 GB wenn wir da nicht aneinander vorbeireden
3. + 4. Voll, mirror. Sind auch als SSD Template angelegt
5. 1 GB
Einen T100 hab ich hier auch noch stehen, mit 32 GB RAM und nem X3323, aber ohne Platten
Bin gerade dabei, eine native Install auf dem Hyper-V vorzunehmen... Aber diese Volltextsuchindizierung ist schon unglaublich langsam, bin da nicht so guter Dinge...
Eine DB der Mandanten ist auch tatsächlich 1 GB groß... Weiß nicht, ist das viel? Kommt mir mächtig vor...
2. einmal Std. also 1 GB wenn wir da nicht aneinander vorbeireden
3. + 4. Voll, mirror. Sind auch als SSD Template angelegt
5. 1 GB
Einen T100 hab ich hier auch noch stehen, mit 32 GB RAM und nem X3323, aber ohne Platten
Bin gerade dabei, eine native Install auf dem Hyper-V vorzunehmen... Aber diese Volltextsuchindizierung ist schon unglaublich langsam, bin da nicht so guter Dinge...
Eine DB der Mandanten ist auch tatsächlich 1 GB groß... Weiß nicht, ist das viel? Kommt mir mächtig vor...
Jetzt kommt es ans Licht. Die haben keine überragende Schreibleistung.
http://www.storagereview.com/samsung_pm863_ssd_review
Die mini kleine 120GB Variante bringt kaum 120MB/s Schreibleistung, bzw. 10k IOPS. Schlechte Wahl, sorry.
Eine DB der Mandanten ist auch tatsächlich 1 GB groß... Weiß nicht, ist das viel? Kommt mir mächtig vor...
1GB DB Größe bedeutet seit Version 16 gar nichts mehr. Der Volltextindex allein hat meine Datenbanken grob auf das dreifache wachsen lassen.
http://www.storagereview.com/samsung_pm863_ssd_review
Die mini kleine 120GB Variante bringt kaum 120MB/s Schreibleistung, bzw. 10k IOPS. Schlechte Wahl, sorry.
2. einmal Std. also 1 GB wenn wir da nicht aneinander vorbeireden
3. + 4. Voll, mirror. Sind auch als SSD Template angelegt
5. 1 GB
Die Werte, die du ermittelt hast passen eigentlich zur verbauten Hardware.3. + 4. Voll, mirror. Sind auch als SSD Template angelegt
5. 1 GB
Einen T100 hab ich hier auch noch stehen, mit 32 GB RAM und nem X3323, aber ohne Platten
Versuchen schadet nicht. Alte (brauchbare) 15k SAS Platten gibts in der Bucht zu hauf. Perc5 oder 6 mit RAM und BBU dazu, eventuell noch einen 4x2,5"zu1x5,25" Käfing rein und gut isses.Bin gerade dabei, eine native Install auf dem Hyper-V vorzunehmen... Aber diese Volltextsuchindizierung ist schon unglaublich langsam, bin da nicht so guter Dinge...
Aufbau vom Volltextindex braucht ewig bei Orgamax. Nimm die Zeit nicht als Benchmark. Auch Backup und Restore dauern ewig, weil nur 1 CPU Thread erstellt wird.Eine DB der Mandanten ist auch tatsächlich 1 GB groß... Weiß nicht, ist das viel? Kommt mir mächtig vor...
Jo, bin inzwischen durch... Alle DBs an den SSD Tier gepinnt und bereits optimiert.
Also der 1 GB Mandant ist zäh, die anderen 5 Mandanten sind kleiner (50-100 MB), da läufts ganz gut.
Bis auf Platten hab ich alles da, Plattenkäfig, Ne Hand voll verschiedener Percs (muss ma gucken ob da einer mit RAM dabei is) hab ich auch noch... Hab auch 4 15k Platten, aber die sind urururururalt... Ich kann ja mal spielen...
Allerdings der Vorteil der Install auf dem Hyper-V ist natürlich, dass ich an die (virtuellen) Clients mit 10 GBit angebunden bin.
Ich hau andere SSDs rein, hab noch billige Patriots hier liegen Mal gucken was geht...
Ich meine, wir haben hier bei meinem Kunden lediglich 3(!) Nutzer von dem Orgamax, nicht irgendwie zig Leute... Also eigentlich echt eine "Spielzeug" Umgebung.
Das einzige was nicht so toll ist, ist die Tatsache, dass wir keinen echten Server einsetzen, und dann auch noch AMD Prozessor (6-Core). Aber hey, 3 Leute...
Wenn wir über 20-50 User sprächen, ja dann würde ich ganz anders an die Sache herangehen...
Hintergrund der Virtualisierung war folgender: Wenig Budget, 2 XP Clients mussten weg (durch "Thinclients" ersetzt), der PC auf dem Orgamax installiert war, war am auseinanderfallen, Der DC (WSE2012R2) war etwas schwächlich. Also den fettesten PC vor Ort genommen, 2 kleine HDDs (Raid1), 2 SSDs rein, 4 große HDDs rein. RAID1 und die dicken HDDs hängen an nem PERC. Den Arbeitsplatz vom PC auch durch "Thinclient" ersetzt. 3 x Windows 10, den DC und den Orgamax-PC virtualisiert.
Das läuft alles super, bis auf Orgamax. Die CPU langweilt sich in der Regel, die anderen VMs sind super schnell. Als "Thinclients" dienen alte PCs mit Lubuntu und Remmina...
Ich weiss, wie man das alles sehen kann, bitte keine all zu abwertenden Kommentare. Ich denke wir haben das Beste daraus gemacht. Wie gesagt, Useranzahl beachten.
Also der 1 GB Mandant ist zäh, die anderen 5 Mandanten sind kleiner (50-100 MB), da läufts ganz gut.
Bis auf Platten hab ich alles da, Plattenkäfig, Ne Hand voll verschiedener Percs (muss ma gucken ob da einer mit RAM dabei is) hab ich auch noch... Hab auch 4 15k Platten, aber die sind urururururalt... Ich kann ja mal spielen...
Allerdings der Vorteil der Install auf dem Hyper-V ist natürlich, dass ich an die (virtuellen) Clients mit 10 GBit angebunden bin.
Ich hau andere SSDs rein, hab noch billige Patriots hier liegen
Mal gucken was geht...Ich meine, wir haben hier bei meinem Kunden lediglich 3(!) Nutzer von dem Orgamax, nicht irgendwie zig Leute... Also eigentlich echt eine "Spielzeug" Umgebung.
Das einzige was nicht so toll ist, ist die Tatsache, dass wir keinen echten Server einsetzen, und dann auch noch AMD Prozessor (6-Core). Aber hey, 3 Leute...
Wenn wir über 20-50 User sprächen, ja dann würde ich ganz anders an die Sache herangehen...
Hintergrund der Virtualisierung war folgender: Wenig Budget, 2 XP Clients mussten weg (durch "Thinclients" ersetzt), der PC auf dem Orgamax installiert war, war am auseinanderfallen, Der DC (WSE2012R2) war etwas schwächlich. Also den fettesten PC vor Ort genommen, 2 kleine HDDs (Raid1), 2 SSDs rein, 4 große HDDs rein. RAID1 und die dicken HDDs hängen an nem PERC. Den Arbeitsplatz vom PC auch durch "Thinclient" ersetzt. 3 x Windows 10, den DC und den Orgamax-PC virtualisiert.
Das läuft alles super, bis auf Orgamax. Die CPU langweilt sich in der Regel, die anderen VMs sind super schnell. Als "Thinclients" dienen alte PCs mit Lubuntu und Remmina...
Ich weiss, wie man das alles sehen kann, bitte keine all zu abwertenden Kommentare. Ich denke wir haben das Beste daraus gemacht. Wie gesagt, Useranzahl beachten.
