none
SQL-Server 2012 auf SSD-PCIe Adapter RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    ich bin gerade an einem seltsamen Problem dran und muss auch gleich vorweg sagen, dass ich kein SQL-Admin bin, sondern von der Hardwarefraktion.
    Wir haben einen neuen DB-Server mit relativ guter Ausstattung:

    2x CPU
    256 GB RAM
    RAID10 für Betriebssystem (Windows Server 2012 R2)
    LSI Nytro WarpDrive Card bzw. die IBM Verison (IBM 600 GB High IOPS MLC Modular Adapter) für Datenbank und Log
    SQL 2012 mit SP1

    Zum Vergleich des RAID-Controller und der SSD-Karte wurde von der SQL-Fraktion einfach ein insert (2 Mio. mal) in eine Datenbank auf dem RAID10 und der gleiche Prozess auf der SSD-Karte gestartet.

    Der Vergleich ist erschütternd.
    Das RAID10 ist nach 2 Min 40 Sec. fertig.
    Die SSD-Variante habe ich nach 4 Min. abgebrochen und er hatte auch schon 23493 Inserts durchgeführt.

    Damit habe ich das Thema wieder bei mir auf dem Tisch.
    Mit Benchmarktools für Storage sehe ich die zu erwartende Performance der SSD.
    Treiber und Hardware sind in Ordnung.
    Es gibt keine Fehler in irgendwelchen Logs.
    Die Partitionen sind korrekt aligned und die Block-, cluster- und stripesize abgestimmt.

    Irgend wer steht aber auf der Bremse.
    Gibt es im SQL Parameter die ein solches Verhalten erklären könnten? Kann ich am caching oder Schreibverhalten des SQL etwas ändern?

    Ich bin gerade recht ratlos und für jeden Tipp dankbar.

    (Einen Supportcall beim Hardwarehersteller habe ich auch schon offen. Da die Storagebenchmarks jedoch gut sind, erhoffe ich mir da nicht sehr viel.)

    Vielen Dank im Voraus.

    Viele Grüße,

    Torsten


    Donnerstag, 21. November 2013 13:26
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Also zunächst einmal fragt man sich hier: warum um alles in der Welt wirfst man mit einem RAID10 nach dem OS?

    Das wäre bei den Logs in der Tat besser aufgehoben.

    Sodann sollte eigentlich klar sein, das RAID10 nicht gleich RAID10 ist: was hier also komplett fehlt, sind genauere Angaben, woraus dieses besteht.

    Selbes gilt für die SSDs

    Zuguterletzt: Wie ist dieser Test denn durchgeführt? Man kann keinen Test beurteilen, dessen Ablauf & Konfiguration man nicht kennt.

    Alles, was ich hier lese, dass irgendwelche INSERTS irgendwie gegen eine DB durchgeführt wurden. Es gibt sicher rund ein Dutzend Möglichkeiten, das anzugehen, und zusammen mit diversen Einstellungen kommen dann 100 verschiedene Varianten heraus. Ein valider Test muss nachvollziehbar und wiederholbar sein - auch für uns hier ;-)

     

    Ich hoffe, das ist nachvollziehbar. Aber um hier sinnvolle Vorschläge zu bringen, müssen wir doch etwas mehr wissen. Sonst wird es eine Rate-Stunde.

    Ansonsten wäre vor einem Test mit tatsächlichen Daten wohl mal ein Test der Platten alleine sinnvoll - mit SQLIO z.B. - ohne laufenden SQL Server etc, um die tatsächlichen Performance-Werte der Hardware zu erhalten. So kann man zB auch feststellen, ob es wirklich das Storage selber ist, oder etwas im SQL Server, was durch diesen etwas komplexeren "Insert"-Test verschleiert wird.

    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Donnerstag, 21. November 2013 13:49
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten,

    Nur ein kurzer Erfahrungsbericht: Wir hatten mal eine FusionIO Karte gegen unser akuelles SAN im Performanztest antreten lassen, natürlich mit dem SQL Server (war noch Version 2005). Bei solchen Operationen wie Full Table Scans auf große Tabellen war es mit Datenbanken auf der SSD Karte um den ganzzahligen Faktor 3 schneller; was weit hinter dem Marketing-Versprechen von 60 lag. Den Wert kann man durchaus erreichen, aber nur bei 4K Randrom Read-Write Access. Der SQL Server hat schon einen sehr gut optimierten Dateizugriff mit Read-Ahead usw, so das man keine zu großen Faktoren erwarten darf; aber mit der richtigen Karte erzielt man schon gute Werte.

    Im TechNet Script Center findest Du ein Script von mir: Storage I/O Performance Tester
    Mit dem kannst Du die verschiedenen Zugriffsarten / Blockgrößen austesten.

    P.S.: Mit SQL Server 2014 kommt nochmal eine bessere SSD Unterstützung hinzu, z.B. um den Buffer Pool dort hin zu erweitern.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]



    Donnerstag, 21. November 2013 15:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    vielen Dank für die Info.
    Damit bin ich beruhigt und sicher, dass es nicht an Einstellungen im SQL-Server liegt :)

    In der Zwischenzeit habe ich mit SQLIOSIM und unterschiedlichen Konfigurationen rumgespielt. Das Verhalten ist recht eindeutig. Die Karte liegt weit hinter dem RAID10.

    Die Hardware (IO-Karte) wird im nächsten Schritt getauscht. Danach werde ich mich nochmal melden.

    Vielen Dank für die Tipps (an alle).

    Viele Grüße,

    Torsten

    Freitag, 22. November 2013 12:45
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Also zunächst einmal fragt man sich hier: warum um alles in der Welt wirfst man mit einem RAID10 nach dem OS?

    Das wäre bei den Logs in der Tat besser aufgehoben.

    Sodann sollte eigentlich klar sein, das RAID10 nicht gleich RAID10 ist: was hier also komplett fehlt, sind genauere Angaben, woraus dieses besteht.

    Selbes gilt für die SSDs

    Zuguterletzt: Wie ist dieser Test denn durchgeführt? Man kann keinen Test beurteilen, dessen Ablauf & Konfiguration man nicht kennt.

    Alles, was ich hier lese, dass irgendwelche INSERTS irgendwie gegen eine DB durchgeführt wurden. Es gibt sicher rund ein Dutzend Möglichkeiten, das anzugehen, und zusammen mit diversen Einstellungen kommen dann 100 verschiedene Varianten heraus. Ein valider Test muss nachvollziehbar und wiederholbar sein - auch für uns hier ;-)

     

    Ich hoffe, das ist nachvollziehbar. Aber um hier sinnvolle Vorschläge zu bringen, müssen wir doch etwas mehr wissen. Sonst wird es eine Rate-Stunde.

    Ansonsten wäre vor einem Test mit tatsächlichen Daten wohl mal ein Test der Platten alleine sinnvoll - mit SQLIO z.B. - ohne laufenden SQL Server etc, um die tatsächlichen Performance-Werte der Hardware zu erhalten. So kann man zB auch feststellen, ob es wirklich das Storage selber ist, oder etwas im SQL Server, was durch diesen etwas komplexeren "Insert"-Test verschleiert wird.

    Andreas Wolter | Microsoft Certified Master SQL Server

    Blog: www.insidesql.org/blogs/andreaswolter
    Web: www.andreas-wolter.com | www.SarpedonQualityLab.com

    Donnerstag, 21. November 2013 13:49
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andreas,

    vielen Dank für die Antwort.

    Es geht hier eigentlich nicht wirklich um das RAID10, aber zur Beruhigung:
    Dort liegen im Endausbau ebenfalls ein paar nicht so wichtige Datenbanken.

    Bei dem SSD-Adapter geht es um eine PCIe-Karte, auf welcher direkt die Flashmodule sitzen:
    http://www.redbooks.ibm.com/abstracts/tips0937.html
    bzw. direkt von LSI:
    http://www.lsi.com/products/flash-accelerators/pages/nytro-warpdrive-blp4-800.aspx

    Den SQLIMSIM habe ich vor ein paar Minuten hier im Forum gefunden und der Standard-Test läuft gerade.
    Im Resourcenmonitor sieht es aber wieder recht schlecht für SSD aus :(
    Sobald der Vorgang beendet ist poste ich nochmal.

    Nochmal zur Klarstellung:
    Es geht nicht um irgendwelche absoluten Werte. Mir ist durchaus klar, dass ich die angegebenen 500MB/s nicht bei jeder Aktion auf dem Server sehen werde und das Performance von vielen Faktoren abhängt.

    Es wird die gleiche Aktion auf gleich erstellten Datenbanken durchgeführt. Nur der Speicherort der DBs unterscheidet sich eben.

    Hier ist mal die SQL Abfrage, die in beiden Fällen mit einer neuen Datenbank ausgeführt wird:
    #############################################
    use Test
    declare @i int
    Set @i=1
    while @i<2000000
    Begin
        insert into ZUT    
            (ZUT_ID,ZUT_KURZTXT,ZUT_LANGTXT)
        Values
            (    @i,
                '123456789123456789123456789123456789',
                '123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789123456789')
        set @i=@i+1
        if @i/10000*10000 = @i
            Begin
                print @i
            End
    End
    #############################################

    Donnerstag, 21. November 2013 14:22
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten,

    Nur ein kurzer Erfahrungsbericht: Wir hatten mal eine FusionIO Karte gegen unser akuelles SAN im Performanztest antreten lassen, natürlich mit dem SQL Server (war noch Version 2005). Bei solchen Operationen wie Full Table Scans auf große Tabellen war es mit Datenbanken auf der SSD Karte um den ganzzahligen Faktor 3 schneller; was weit hinter dem Marketing-Versprechen von 60 lag. Den Wert kann man durchaus erreichen, aber nur bei 4K Randrom Read-Write Access. Der SQL Server hat schon einen sehr gut optimierten Dateizugriff mit Read-Ahead usw, so das man keine zu großen Faktoren erwarten darf; aber mit der richtigen Karte erzielt man schon gute Werte.

    Im TechNet Script Center findest Du ein Script von mir: Storage I/O Performance Tester
    Mit dem kannst Du die verschiedenen Zugriffsarten / Blockgrößen austesten.

    P.S.: Mit SQL Server 2014 kommt nochmal eine bessere SSD Unterstützung hinzu, z.B. um den Buffer Pool dort hin zu erweitern.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]



    Donnerstag, 21. November 2013 15:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    vielen Dank für Deine Antwort.

    Musste am SQL-Server noch etwas für die FusionIO Karte angepasst werden?

    Was mich in meiner Umgebung massiv stört, ist die Tatsache, dass ich mit den künstlichen Benchmarks einen riesigen Unterschied zwischen der Karte und dem RAID zugunsten der Karte sehe.

    Mit SQL 2012 ist der Fall jedoch genau umgedreht.

    Danke im Voraus.

    Das Script schaue ich mir noch an und werde auch damit testen.

    Donnerstag, 21. November 2013 16:06
    |
  • Question
    Anmelden
    0
    Anmelden

    Musste am SQL-Server noch etwas für die FusionIO Karte angepasst werden?

    Hallo Torsten,

    Am SQL Server haben wir nicht eingestellt, war eine ganze normale Installation. Übrigens, wir haben den gleichen Test auch mit Oracle gemacht, gleiche Ergebnis.

    Dein Test war jetzt immer mit einzelnen kleinen INSERTS, das sollte eigentlich schon vom Hauptspeicher angefangen und dann vom LazyWriter weg geschrieben werden, von daher wundert mich Dein Ergebnsi. Hast Du schon mal BULK Operationen ausprobiert oder eben das Lesen von großen Datenmengen?

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Freitag, 22. November 2013 08:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten,
    trenne doch mal Daten (RAID) und Log (SSD) und wiederhole den Test als dritte Variante. Das umgekehrte dann als vierte Variante.

    Einen schönen Tag noch,
    Christoph
    --
    Microsoft SQL Server MVP - http://www.insidesql.org/blogs/cmu


    Freitag, 22. November 2013 10:03
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    Hallo Olaf,

    vielen Dank für die Info.
    Damit bin ich beruhigt und sicher, dass es nicht an Einstellungen im SQL-Server liegt :)

    In der Zwischenzeit habe ich mit SQLIOSIM und unterschiedlichen Konfigurationen rumgespielt. Das Verhalten ist recht eindeutig. Die Karte liegt weit hinter dem RAID10.

    Die Hardware (IO-Karte) wird im nächsten Schritt getauscht. Danach werde ich mich nochmal melden.

    Vielen Dank für die Tipps (an alle).

    Viele Grüße,

    Torsten

    Freitag, 22. November 2013 12:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    hier nochmal ein Statusupdate:
    Der Hardwaretausch hat leider nichts gebracht. Die Probleme werden durch ein seltsames Treiberverhalten verursacht.
    Wird "normal" auf das Dateisystem geschrieben, ist die Performance super.
    Wird im "write-through" Modus geschrieben ist die Performance fast auf dem Niveau einer Diskette.
    Da der SQL-Server standardmäßig die DB im sicheren, also write-through Modus öffnet ist die Performance mit der verwendeten Karte im Keller.
    Auch der aktuellste Treiber vom 04.12.2013 bringt hier leider keine Besserung.

    Das Verhalten wird weiter untersucht.
    Ich melde mich dann mit der finalen Lösung.

    Viele Grüße,

    Torsten

    Freitag, 6. Dezember 2013 10:25
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Torsten,

    solche Treiberprobleme hatten wir nicht, dafür aber andere. Geordert hatten wir eine 24 TB SAN Lösung, Brutto hatten wir dann aber nur ~20 TB; der Hersteller hatte kein Zutrauen zu seiner eigenen Lösung und per Treiber zur Ausfallsicherheit einfach 4 TB "versteckt", die dann verwendet werden, wenn ein paar Chips abbrennen. Da musste auch erst der Treiber angepasst werden, damit wir die voll Kapazität nutzen konnten.

    Olaf Helper

    [ Blog] [ Xing] [ MVP]

    Donnerstag, 12. Dezember 2013 08:32
    |