none
HP StoreVirtual 4330 and ISCSI -> IOPS Limit @1000 RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hi,

    we have a high available Hyper-V Cluster with two cluster nodes. As storage we have to StoreVirtual 4330 Nodes from HP. The Volumes are mirrored on each node. We have a database application based on TurboDB. This is a file system database. We want to migrate this database to Microsoft SQL Server. The Version does not matter at the moment. After Migration in a evaluation version of SQL Server 2014 the application was very slow. What we can see is that the database lying on a san volume is much slower than on a single local disk. We had a ticket with Hewlett Packard. They did a lot of tests in 3rd Level, but they also could not bring the IOPS Count much over 1000. All other applications are working fine and fast.

    We had a little bit Performance increasement when we mapped the volume as a passthrough disk. But not the same performance as in the TurboDB

    Do you have an idea, what to do?

    Kind regards

    Jan

    Mittwoch, 11. März 2015 08:49
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Jan

    da stellt sich zunächst die Frage: wie genau wurde gemessen?

    Und was diese "anderen Applikationen" angeht: schaffen diese "mehr als 1000 IOPS" oder benötigen diese einfach nicht so viel IO Performance? Der Vergleich Applikationsübergreifend ist halt schwierig, daher meine Frage, ob diese Aussage überhaupt in diesem Zusammenhang weiterhilft.

    Und zuguterletzt kommt es natürlich auf das Transaktionsdesign an. RDBMSse funktionieren nicht identisch und lassen sich daher seltenst mit den gleichen Mitteln tunen. Und in diesem Fall ist der Vergleich noch schwieriger. SQL Server spielt sicher in einer ganz anderen Liga, auch technologisch, als TurboDB. Sprich, ein für TurboDB optimales System muss lange nicht für SQL Server passen - wie es hier ja zu sein scheint.

    Aber vielleicht helfen uns die oben aufgeführten Fragen ja weiter.

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Mittwoch, 11. März 2015 17:04
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Jan,

    ich würde erst mal neutrale I/O Performance Tests mit dem SAN durchführen. Von MS gibt es das freie Tool SqlIo.exe, hat nicht wirklich was mit SQL Server zu tun, das Tool führt einfach nur bestimmte IO Zugriffe durch und liefert die Zeiten etc. als Ergebnis: SQLIO Disk Subsystem Benchmark Tool
    Ich hatte mal dafür ein PowerShell Skript geschrieben, dass das Tool mit diversen Parametern aufruft und das Ergebnis übersichtlich darstellt: Storage I/O Performance Tester

    Im SQL Server kann man auch einige I/O Statistiken abrufen: Various SQL Server IO Statistics

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 12. März 2015 07:44
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    erst einmal vielen Dank für die rasche Antwort.

    Zu den Fragen:
    Das Resultat der Tests ergab, dass der SQL Server ein anderes "IO-Design" verwendet, wenn ich als Volume ein SAN-Volume nehme. Läuft die Applikation (Datenbank) auf einer mit USB angeschlossenen 2,5" Platte, habe ich in etwas die gleiche Performance wie auf einem Volume, welches auf 8 Platten verteilt auf dem SAN liegt.

    Das größte Problem sind hier "kleine / vertikale" Abfragen. Wenn "größere" Abfragen mit mehr Spalten (horizontale Größe wächst) werden in der gleichen Zeit erledigt. Die Höhe der IOPs bleiben gleich, aber die Größe der einzelnen IOs steigen. Dieser Effekt ist auf einer lokalen Platte nicht in dem Ausmaß zu beobachten.

    Viele Grüße

    Jan

    Donnerstag, 12. März 2015 09:57
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    erstmal danke für die Antwort. Tests wurden zum einen mit IOMeter ausgeführt zum anderen mit einer Kopie der Live-Datenbank. Das Ergebnis des Microsoft Teams von HP war, dass MS SQL die SAN nicht im Rahmen der technischen Möglichkeiten nutzt. Sprich die Datenbank könnte mehr Anfragen an die SAN stellen, macht es aber nicht. Wie in der Antwort an Olaf beschrieben verhält sich das nur auf dem SAN so. Eine lokal angeschlossene 2,5" USB Platte hat bessere Performance Ergebnisse für MS SQL als die SAN mit 8 SAS Platten mit 10.000 U/min.

    Je nach dem, wie IOMeter konfiguriert wurde, kamen sogar IOPs im 5 stelligen Bereich heraus.

    SQLIO wurde auch einmal getestet, da kam ein Wert von 2.000 - 3.000 IOPS heraus.

    Viele Grüße

    Jan.

    Donnerstag, 12. März 2015 10:13
    |
  • Question
    Anmelden
    0
    Anmelden
    ...

    Das größte Problem sind hier "kleine / vertikale" Abfragen. Wenn "größere" Abfragen mit mehr Spalten (horizontale Größe wächst) werden in der gleichen Zeit erledigt. Die Höhe der IOPs bleiben gleich, aber die Größe der einzelnen IOs steigen. Dieser Effekt ist auf einer lokalen Platte nicht in dem Ausmaß zu beobachten.

    ...
    Damit wären wir also tatsächlich beim Transaktionsdesign, welches ich oben andeutete. Damit ist der Flaschenhals offenbar tatsächlich dort, und nicht auf der Festplatte.

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform, MCM, MVP
    www.SarpedonQualityLab.com | www.SQL-Server-Master-Class.com

    Donnerstag, 12. März 2015 11:09
    |
  • Question
    Anmelden
    0
    Anmelden

    ...

    Das größte Problem sind hier "kleine / vertikale" Abfragen. Wenn "größere" Abfragen mit mehr Spalten (horizontale Größe wächst) werden in der gleichen Zeit erledigt. Die Höhe der IOPs bleiben gleich, aber die Größe der einzelnen IOs steigen. Dieser Effekt ist auf einer lokalen Platte nicht in dem Ausmaß zu beobachten.

    ...

    Damit wären wir also tatsächlich beim Transaktionsdesign, welches ich oben andeutete. Damit ist der Flaschenhals offenbar tatsächlich dort, und nicht auf der Festplatte.

    Dann kann es aber nur an der Kombination liegen, da es auf den lokalen Platten dieses Problem nicht gibt.
    Dienstag, 17. März 2015 08:11
    |