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!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 325552
Url: https://administrator.de/forum/tiered-storage-spaces-performance-problem-in-virtueller-maschine-325552.html
Ausgedruckt am: 23.12.2024 um 05:12 Uhr
9 Kommentare
Neuester Kommentar
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
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
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...