10
1000 Schreib IOPs zu viel für SQLer ?
Hallo,
ich fahre hier einen virtuellen Standard 48GB RAM MS SQL Server auf nem Server 2012R2. Unser neues ERP jagd den regelmässig hoch auf bis zu 1000 IOPs schreibend. Lesend bedeutend weniger (max. 350). Das ganze bei maximal ca. 50MB/s. An den Applikationsservern hängen so ca. 150 Maschinen, die also auch indirekt auf dem SQLer rumfuhrwerken. Als Storage ist ein Dell SAS SC (irgendwas) verbaut. Die VM läuft auf "read intensive" original Dell SSDs.
Durchschnitts Schreib IOPs würde ich so bei 400 ansetzen. Aber eben mit diesen massiven Ausreissern nach oben.
Daher die Fragen:
a) Ist das zu viel für SSDs, die eigentlich eher auf Lesen ausgelegt sind?
b) Sind 1000 IOPs für diesen Bereich (ERP) zu viel oder durchaus "normal" ?
Vielen Dank!
ich fahre hier einen virtuellen Standard 48GB RAM MS SQL Server auf nem Server 2012R2. Unser neues ERP jagd den regelmässig hoch auf bis zu 1000 IOPs schreibend. Lesend bedeutend weniger (max. 350). Das ganze bei maximal ca. 50MB/s. An den Applikationsservern hängen so ca. 150 Maschinen, die also auch indirekt auf dem SQLer rumfuhrwerken. Als Storage ist ein Dell SAS SC (irgendwas) verbaut. Die VM läuft auf "read intensive" original Dell SSDs.
Durchschnitts Schreib IOPs würde ich so bei 400 ansetzen. Aber eben mit diesen massiven Ausreissern nach oben.
Daher die Fragen:
a) Ist das zu viel für SSDs, die eigentlich eher auf Lesen ausgelegt sind?
b) Sind 1000 IOPs für diesen Bereich (ERP) zu viel oder durchaus "normal" ?
Vielen Dank!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 373054
Url: https://administrator.de/forum/1000-schreib-iops-zu-viel-fuer-sqler-373054.html
Ausgedruckt am: 11.04.2025 um 03:04 Uhr
10 Kommentare
Neuester Kommentar
Moin,
a) kA... wie sind die Specs der SSD? In was für einem RAID laufen die? 1? 10? 5?
b) kann normal sein - was sagt der Hersteller?
Und: bemerkst du die Spitzen? Wird irgendwas langsamer?
lg,
Slainte
a) kA... wie sind die Specs der SSD? In was für einem RAID laufen die? 1? 10? 5?
b) kann normal sein - was sagt der Hersteller?
Und: bemerkst du die Spitzen? Wird irgendwas langsamer?
lg,
Slainte
Hallo,
durchaus normal kommt auf die Nutzung und die ERP an.
Wie viele IOPS die SSDs leisten kommt ebenfalls darauf an, wie alt die Dell Configuration und welche Platten in Nutzung sind.
Nach einer aktueller Planung kann ein Raid10 aus 4 SSDs Read Intensive locker 3.000 IOPS reissen. Aber, wie immer, je nach dem - was nicht zu vergessen ist: Was kommt "unten", sprich in der VM an.
Liegt die ERP auf demselben Host, wie der SQL?
Viele Grüße,
Christian
certifiedit.net
durchaus normal kommt auf die Nutzung und die ERP an.
Wie viele IOPS die SSDs leisten kommt ebenfalls darauf an, wie alt die Dell Configuration und welche Platten in Nutzung sind.
Nach einer aktueller Planung kann ein Raid10 aus 4 SSDs Read Intensive locker 3.000 IOPS reissen. Aber, wie immer, je nach dem - was nicht zu vergessen ist: Was kommt "unten", sprich in der VM an.
Liegt die ERP auf demselben Host, wie der SQL?
Viele Grüße,
Christian
certifiedit.net
aus technischer Sicht haben die anderen ja schon geantwortet. 1000 ist jetzt nicht unbedingt viel. Für 150 Clients die primär ein ERP Nutzen, kommt mir das allerdings doch etwas hoch vor. Kommt natürlich schwer darauf an, was da so schreibend geschieht. evtl. werden da ja extrem viele Daten geschrieben. Kann ja sein.
Aber Grundsätzlich würde ich mal analysieren, was da geschrieben wird.
Ich habe schon häufig gesehen, das z.B eine Log-Tabelle mit allem möglichen beschrieben wird und im Laufe der Zeit recht gross wurde. Das ist erst mal kein Problem. Was zum Problem werden kann: Der Clustered Index wurde falsch gesetzt, so das neue Daten nicht sequenziell ans Ende geschrieben wurden, sondern irgendwo mitten in der Liste. Dadurch muss der SQL ständig die Tabelle auseinandernehmen und wieder zusammenfügen.(Schau dir die Funktionsweise von Clustered Indexen an, um zu verstehen was ich hier meine)
Ebenso das exzessive verwenden von grossen, temporären Tabellen. Die werden ab einer gewissen Grösse auch auf die Festplatte gespeichert und danach wieder gelöscht. Bis zum nächsten Aufruf der Funktion.
Fraglich, ob du daran was ändern kannst
Aber Grundsätzlich würde ich mal analysieren, was da geschrieben wird.
Ich habe schon häufig gesehen, das z.B eine Log-Tabelle mit allem möglichen beschrieben wird und im Laufe der Zeit recht gross wurde. Das ist erst mal kein Problem. Was zum Problem werden kann: Der Clustered Index wurde falsch gesetzt, so das neue Daten nicht sequenziell ans Ende geschrieben wurden, sondern irgendwo mitten in der Liste. Dadurch muss der SQL ständig die Tabelle auseinandernehmen und wieder zusammenfügen.(Schau dir die Funktionsweise von Clustered Indexen an, um zu verstehen was ich hier meine)
Ebenso das exzessive verwenden von grossen, temporären Tabellen. Die werden ab einer gewissen Grösse auch auf die Festplatte gespeichert und danach wieder gelöscht. Bis zum nächsten Aufruf der Funktion.
Fraglich, ob du daran was ändern kannst
Wir sind gerade in der "heissen" Phase der Einführung. Daher sitzt da gerade auch ne "Taskforce" zusammen und kann derzeit noch keine Aussagen treffen ob das normal ist. Kopf => Tisch.
a)Raid 10. 7 Stück eine Spare.
b)siehe oben
SQLer und ERP Haupt-VM liegen auf getrennten Hosts, aber beide auf den SSDs. Musste ich so machen, da es schon IO Waits auf den anderen HDD Volumes mit der ERP Maschine gab.
Verbaut sind die SSDs: https://www.heise.de/preisvergleich/hgst-ultrastar-ssd1600mr-sed-500gb-0 ...
Nicht, dass ich da jetzt jeden Monat SSDs nachordern darf
a)Raid 10. 7 Stück eine Spare.
b)siehe oben
SQLer und ERP Haupt-VM liegen auf getrennten Hosts, aber beide auf den SSDs. Musste ich so machen, da es schon IO Waits auf den anderen HDD Volumes mit der ERP Maschine gab.
Verbaut sind die SSDs: https://www.heise.de/preisvergleich/hgst-ultrastar-ssd1600mr-sed-500gb-0 ...
Nicht, dass ich da jetzt jeden Monat SSDs nachordern darf
Wäre interessant, was das für eine ERP ist, dass die da keine Erfahrungswerte haben.
a) aber Platten von 2014? Aber laut "Blatt" 4k IOPS? - würde dennoch mal über Neuaufbau nachdenken - haben nun schon paar Tage auf dem Buckel. Kann natürlich auch an den Zwischenschichten liegen.
b) well.
a) aber Platten von 2014? Aber laut "Blatt" 4k IOPS? - würde dennoch mal über Neuaufbau nachdenken - haben nun schon paar Tage auf dem Buckel. Kann natürlich auch an den Zwischenschichten liegen.
b) well.
Hi
SQL Server als VM - bzw. allgemein kann das viele Ursachen haben:
Und 1k IOPs .... unsere ERP dreht mit max 45.000 schreibend wenn Optimierungsläufe am werkeln sind, schnitt liegt bei 7.500 mit 4ms Latenz.
Du scheinst irgendwo ein massives Nadelöhr zu haben und das musst du finden, entweder der Controller, das Netzwerk, CPU Einstellungen usw.
Und dann natürlich die Frage: welche ERP - SAP verhält sich anders wie NAV wie SAGE und was es sonst noch alles gibt.
Just my 2 Cent
@clSchak
SQL Server als VM - bzw. allgemein kann das viele Ursachen haben:
- was sagt die Latenz des Storages am VM Host an und die IO Last?
- was sagen die anderen Leistungsdaten?
- Nur weil man SSD's einsetzt heisst es nicht das auch die Leistung da ist
- was sagt der Controller und was mit den Cache Settings?
- Welche Latenzen haben die einzelnen Vorgänge lt. Aktivitätsmonitor?
- Liegt alles auf SSD's oder Teile auf anderen Platten?
Und 1k IOPs ....
unsere ERP dreht mit max 45.000 schreibend wenn Optimierungsläufe am werkeln sind, schnitt liegt bei 7.500 mit 4ms Latenz.Du scheinst irgendwo ein massives Nadelöhr zu haben und das musst du finden, entweder der Controller, das Netzwerk, CPU Einstellungen usw.
Und dann natürlich die Frage: welche ERP - SAP verhält sich anders wie NAV wie SAGE und was es sonst noch alles gibt.
Just my 2 Cent
@clSchak
Aber laut "Blatt" 4k IOPS? -
Ne, da steht "IOPS 4K lesen/schreiben: 130k/30k" - da sind sicher 4K Blöcke gemeint mit denen dann 130k r/30k w erreicht werden.Zitat von @SlainteMhath:
Aber laut "Blatt" 4k IOPS? -
Ne, da steht "IOPS 4K lesen/schreiben: 130k/30k" - da sind sicher 4K Blöcke gemeint mit denen dann 130k r/30k w erreicht werden.also 130.000IOPS Read?
Gehe allerdings auch eher Richtung @clSchak, dass nicht nur bei den Platten zu suchen ist.
Danke für euere Erfahrung bzw. Tipps. Das ERP Haus will ich hier absichtlich nicht nennen, da ich keinen in die Pfanne hauen möchte. Fehler passieren und meine Aufgabe ist es ja auch "nur" unterstützend zur Seite zu stehen.
Wenn ich mir eure Beiträge anschaue, kann ich beruhigt sagen, dass ich kein Bottlekneck habe.Die Werte passen einfach alle. Die SSDs sind übrigens nicht von 2014 sondern "erst" aus 2016.
Die Latenz geht auch eher nicht über 3ms. Ich sehe ja auch sonst keinerlei Probleme. Ich denke ich kann da nichts weiter tun. Ich bin übrigens kein DBA Admin bzw. lass da absichtlich die Finger von. Der SQLer ist auch komplett in ERP Hand und das ist auch gut so
Vielen Dank und ein schönes Wochenende!
Wenn ich mir eure Beiträge anschaue, kann ich beruhigt sagen, dass ich kein Bottlekneck habe.Die Werte passen einfach alle. Die SSDs sind übrigens nicht von 2014 sondern "erst" aus 2016.
Die Latenz geht auch eher nicht über 3ms. Ich sehe ja auch sonst keinerlei Probleme. Ich denke ich kann da nichts weiter tun. Ich bin übrigens kein DBA Admin bzw. lass da absichtlich die Finger von. Der SQLer ist auch komplett in ERP Hand und das ist auch gut so
Vielen Dank und ein schönes Wochenende!
Hallo !
Kurzes Update nochmal: Es gab wirklich fehlerhaft programmierte Abfragen auf den Applikations Servern. Das wurde nun gefixt und siehe da: unter 100 IO/s im IDLE
Kurzes Update nochmal: Es gab wirklich fehlerhaft programmierte Abfragen auf den Applikations Servern. Das wurde nun gefixt und siehe da: unter 100 IO/s im IDLE
