2
Windows Server 2008R2 mit SSDs in externem Storage über iSCSI
Hallo zusammen,
mich beschäftigt ein Problem mit der Schreibperformance auf einem externen Storage Infortrend EonStor DS-SDS16E-R2152. Das System ist mit 400GB SSD bestückt (vom Hersteller lizensiert), die in einem RAID10-Verbund betrieben werden. Hierauf sind 3 Volumes angelegt, die alle mit NTFS formatiert sind und von MSSQL2008R2 genutzt werden (DB, tempdb, log). Alle Volumes haben ein unterschiedliches Schreib-/Lese-Verhältnis von 30/70 bis hin zu 80/20. Blocksize ist i.d.R. 64k. Das Komplettsystem wurde vom Lieferanten vorkonfiguriert gemäß unseren Anforderungen. Die Anbindung ist iSCSI. Der Server läuft unter VMware vSphere 5.1, die LUNs sind durchgereicht. Es sind niemals mehr als 70% der LUN belegt.
Das Problem besteht nun darin, dass die Schreibperformance extrem einbricht, je mehr sich das Schreib-/Lese-Verhältnis in Richtung Schreiben verschiebt.
Folgende Performance-Werte konnte ich messen (bs=64k):
0% Lesen/100% Schreiben: ~850 IOPS
100% Lesen/0% Schreiben: ~7000 IOPS
50% Lesen/50% Schreiben: ~650IOPS
Insbesondere bei der letzten Messung hätte ich ein Ergebnis zwischen der ersten und zweiten Messung erwartet...
Meine Vermutung besteht darin, dass das verwendete NTFS (blocksize tempdb 4k, sonst 64k) die Schwachstelle bildet, und zwar dass der TRIM-Befehl nicht an das Storage/die SSDs durchgereicht wird. Soweit mit bekannt ist, steigert die erfolgreiche Benutzung des TRIM-Befehls die Performance erheblich.
- Wie kann ich verifizieren, ob TRIM eingeschaltet ist und funktioniert?
- Welche Faktoren könnten noch ursächlich sein für die mangelhafte Performance?
- Welche Treiber muss ich ggf. benutzen?
Info nebenbei: Die Netzwerk-Anbindung ist aktuell zu gering (4x 1GBit/s). Trotzdem dürfte die nur eine Einschränkung beim Lesen, nicht jedoch beim Schreiben bedeuten, oder?
Kennt jemand dieses Phänomen und kann helfen?
Gruß
Olaf
mich beschäftigt ein Problem mit der Schreibperformance auf einem externen Storage Infortrend EonStor DS-SDS16E-R2152. Das System ist mit 400GB SSD bestückt (vom Hersteller lizensiert), die in einem RAID10-Verbund betrieben werden. Hierauf sind 3 Volumes angelegt, die alle mit NTFS formatiert sind und von MSSQL2008R2 genutzt werden (DB, tempdb, log). Alle Volumes haben ein unterschiedliches Schreib-/Lese-Verhältnis von 30/70 bis hin zu 80/20. Blocksize ist i.d.R. 64k. Das Komplettsystem wurde vom Lieferanten vorkonfiguriert gemäß unseren Anforderungen. Die Anbindung ist iSCSI. Der Server läuft unter VMware vSphere 5.1, die LUNs sind durchgereicht. Es sind niemals mehr als 70% der LUN belegt.
Das Problem besteht nun darin, dass die Schreibperformance extrem einbricht, je mehr sich das Schreib-/Lese-Verhältnis in Richtung Schreiben verschiebt.
Folgende Performance-Werte konnte ich messen (bs=64k):
0% Lesen/100% Schreiben: ~850 IOPS
100% Lesen/0% Schreiben: ~7000 IOPS
50% Lesen/50% Schreiben: ~650IOPS
Insbesondere bei der letzten Messung hätte ich ein Ergebnis zwischen der ersten und zweiten Messung erwartet...
Meine Vermutung besteht darin, dass das verwendete NTFS (blocksize tempdb 4k, sonst 64k) die Schwachstelle bildet, und zwar dass der TRIM-Befehl nicht an das Storage/die SSDs durchgereicht wird. Soweit mit bekannt ist, steigert die erfolgreiche Benutzung des TRIM-Befehls die Performance erheblich.
- Wie kann ich verifizieren, ob TRIM eingeschaltet ist und funktioniert?
- Welche Faktoren könnten noch ursächlich sein für die mangelhafte Performance?
- Welche Treiber muss ich ggf. benutzen?
Info nebenbei: Die Netzwerk-Anbindung ist aktuell zu gering (4x 1GBit/s). Trotzdem dürfte die nur eine Einschränkung beim Lesen, nicht jedoch beim Schreiben bedeuten, oder?
Kennt jemand dieses Phänomen und kann helfen?
Gruß
Olaf
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 216211
Url: https://administrator.de/forum/windows-server-2008r2-mit-ssds-in-externem-storage-ueber-iscsi-216211.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
2 Kommentare
Neuester Kommentar
Moin,
wir haben ein ähnliches Problem bloß andere Eckdaten. Wir haben in einer VM Volumens eingebunden für Microsoft SQL Server Datenbanken. Verbindung zwischen VMWare ESX und Netapp Storage ist einmal 10GBit bzw. FC. Auf der Storageseite steht sogar nur SSD-Platten im RAID DP. SOftware installiert, Einstellungen konfiguriert, etc... SQL-Skript entworfen, dass 1 Mio Inserts in eine Tabelle schreibt.
Der Test dauert ca. 6 Minuten. Machen wir das selbe mit einem phy. Server braucht der Test nur noch 1:10 Minute. WIr haben für uns festgestellt, sobald ein Byte den Server Richtung Storage verlässt, tritt das "Problem" auf. STorage und SSD langweilen sich zu Tode. Wir vermuten es liegt am Server - bloß wo... weiter sind wir noch nicht gekommen.
Grüße,
Dani
wir haben ein ähnliches Problem bloß andere Eckdaten. Wir haben in einer VM Volumens eingebunden für Microsoft SQL Server Datenbanken. Verbindung zwischen VMWare ESX und Netapp Storage ist einmal 10GBit bzw. FC. Auf der Storageseite steht sogar nur SSD-Platten im RAID DP. SOftware installiert, Einstellungen konfiguriert, etc... SQL-Skript entworfen, dass 1 Mio Inserts in eine Tabelle schreibt.
Der Test dauert ca. 6 Minuten. Machen wir das selbe mit einem phy. Server braucht der Test nur noch 1:10 Minute. WIr haben für uns festgestellt, sobald ein Byte den Server Richtung Storage verlässt, tritt das "Problem" auf. STorage und SSD langweilen sich zu Tode. Wir vermuten es liegt am Server - bloß wo... weiter sind wir noch nicht gekommen.
Grüße,
Dani
Hallo!
Ich habe letzte Woche einen neuen iSCSI-HA-Cluster in Betrieb genommen mit 2x 10 GBit Anbindung, vielen SSDs, etc.
Danach kann ich nur sagen: iSCSI Performance-Tuning bzw. die Suche nach Flaschenhälsen ist ganz großer Mist.
Ich würde Dir gerne helfen, aber das war so eine Suche nach der Nadel im Heuhaufen, weil manche Parameter erst gut, in Verbindung mit anderen dann aber ganz mies waren. Am Schluss haben sogar noch die Switche einen Einfluss gehabt, wodurch dann ab einer gewissen Anzahl Switche zwischen Target und Initiator plötzlich NUR die Schreibgeschwindigkeit einbrach. Ich habe ähnliche Effekte beobachtet, wie Du.
Die 850 IOPS beim Schreiben sind ja auch nicht gerade das Erhoffte, schätze ich.
Zum eigentlichen Topic:
TRIM funktioniert IMHO noch mit keinem Raid-Controller
Ich würde mit der Strip-Size experimentieren.
Ist TCP-Offload beidseitig aktiviert?
Ist Flowcontrol deaktiviert?
Grüße
Phil
Ich habe letzte Woche einen neuen iSCSI-HA-Cluster in Betrieb genommen mit 2x 10 GBit Anbindung, vielen SSDs, etc.
Danach kann ich nur sagen: iSCSI Performance-Tuning bzw. die Suche nach Flaschenhälsen ist ganz großer Mist.
Ich würde Dir gerne helfen, aber das war so eine Suche nach der Nadel im Heuhaufen, weil manche Parameter erst gut, in Verbindung mit anderen dann aber ganz mies waren. Am Schluss haben sogar noch die Switche einen Einfluss gehabt, wodurch dann ab einer gewissen Anzahl Switche zwischen Target und Initiator plötzlich NUR die Schreibgeschwindigkeit einbrach. Ich habe ähnliche Effekte beobachtet, wie Du.
Die 850 IOPS beim Schreiben sind ja auch nicht gerade das Erhoffte, schätze ich.
Zum eigentlichen Topic:
TRIM funktioniert IMHO noch mit keinem Raid-Controller
Ich würde mit der Strip-Size experimentieren.
Ist TCP-Offload beidseitig aktiviert?
Ist Flowcontrol deaktiviert?
Grüße
Phil
1
