Beiträge von geomap

Zitat von [netcup] Felix

Den Parameter "iops_size" nutzen wir nicht in unserer Konfiguration. Wir haben das Scheduling für IO-Operationen so erweitert, dass länger andauernde IO-Last nicht dazu führt, dass eine Herabstufung der Priorität derart große Auswirkungen hat, wie hier zum Teil geschildert. Ich würde Sie bitten dieses einmal zu testen.

Es schaut so aus als ob die Drosselung für den Server gänzlich aufgehoben wurde. Es gibt keine Kappung mehr bei 1600 IOPs und auch keine auf 200 nach 15 Minuten I/O-Last.

Ist das jetzt generell und dauerhaft für alle Server so oder zeitlich beschränkt für diesen einen?

Was auffällt ist, dass im System immernoch 128k Blöcke als ein I/O gezählt werden. Ich weiß nicht, ob das nur noch ein Anzeigeproblem ist oder ob hier aufgrund einer Konfiguration unnötig viele IOPs "verbraucht" werden.

Vielen Dank und ebenso einen schönen Feiertag,

Michael.

Zitat von [netcup] Felix

Wenn Sie der Meinung sind das der Durchsatz nicht passt, prüfen Sie diesen bitte einmal im Rettungssystem. Verwenden Sie für den Test große Blöcke von 8 MByte. Sollten Sie dann nach wie vor unzufrieden sein, wenden Sie sich bitte an unseren Support

Genau das habe ich gemacht, bevor ich diesen Post eröffnet habe. Ich habe auf 2 unterschiedlichen Systemen im Rettungssystem Messungen mit dd und einer Blockgröße von 1 MB durchgeführt. Offenbar ist aber die Virtualisierung so konfiguriert, dass je 128kB als eine IO-Operation gezählt wird, so dass die Erhöhung der Blockgröße nicht zu mehr Durchsatz führt. Sobald die Drossel in Kraft tritt, beschränkt das den maximalen Durchsatz auf 25 MB/s - unabhängig davon ob ich größere Blöcke lese oder nicht.

Die Reaktion des Supports war: Behauptung, dass gar nicht gedrosselt wird. Danach unkonkrete Aussagen über eine ggf. mögliche Drosselung. Konkrete Angaben wurden trotz Rückfrage nicht gemacht. Am Ende wurden die IOPs des konkreten Servers "einmalig angehoben" - das eigentliche Problem (welches nicht die IOPs selbst sind sondern die Kombination von Einstellungen der Virtualisierung, die zur eingeschränkten Transferrate führt) wurde nicht behoben.

Zitat

Wenn hier noch Klärungsbedarf besteht, probiere ich diesen sehr gerne zu lösen

Ich sehe diesen für zwei Punkte:

1. Die Kommunikation ist alles andere als optimal. Es gibt offenbar eine konkrete, reproduzierbare Drosselung bei einer bestimmten Auslastung (in meiner Messung beim Storage-Server z.B. 1600 IOPs für 15 Minuten), welches zu einer konkreten Drosselung führt (200 IOPs). Das sind harte technische Obergrenzen, diese gehören in die Produktbeschreibung. Eine Drosselung ist prinzipiell ja OK, gehört aber meiner Meinung nach offen kommuniziert.

Der größte Cloud-Sever-Anbieter mit den drei Buchstaben drosselt auch IOPs - hier wird dies aber präzise als Obergrenze dokumentiert.

2. Das konkrete technische Problem, das 128kB als IO-Operation zählt, auch wenn diese linear gelesen werden, sollte gelöst werden, das die Drosselung sich sonst nicht nur auf IOPs sondern auch auf die IO Bandbreite bezieht. Wenn KVM/QEMU zum Einsatz kommt, wäre das vermutlich der Parameter "iops_size", welcher größer gewählt werden müsste (https://qemu.weilnetz.de/doc/qemu-doc.html).

Mit freundlichen Grüßen,

Michael.

Zitat von mfnalex

Ich kann das nicht nachvollziehen (RS 2000 Plus SAS G8). dd läuft seit über 15 Minuten:

Die Messungen habe ich auf 2 neu bestellten Servern durchgeführt. Es kann durchaus sein, dass ältere Systeme ungedrosselt sind.

Solange Netcup keine offiziellen Aussagen macht, welche Systeme unter welchen Bedingungen wie gedrosselt werden, lässt sich da leider nur spekulieren.

Hallo Herr Preuß,

vielen Dank für das Feedback. Meine Kritik gilt jedoch nicht den 200 IOPs (die isoliert betrachtet sehr gut sind), sondern:

* der Tatsache, dass aufgrund der I/O Blockgröße von 128k damit maximal 25MB/s Leserate möglich sind (ein Parameter, welcher sich unter KVM auch anpassen lässt)

* der Tatsache, dass diese Drosselung nicht nur nicht kommuniziert sondern vom Support teils geleugnet wird

* das keine konkreten Zahlen vorliegen, bei welcher Nutzung wie gedrosselt wird.

Meine Messungen legen nahe, dass anhand von IOPs bei überschreiten von 200 IOPs gedrosselt wird. Damit sind ab Drosselung auch bei vielen kleinen Dateien und einem hostseitigen Cache nicht mehr IOPs möglich.

Zitat

zunächst möchte ich klarstellen, dass Storage-Server bei in den SLA wie VPS, nicht wie Root-Server behandelt werden

Bei dem von mir geprüften Root-Server liegt die Rate auf die gedrosselt wird bei 250 IOPs und 30 MB/s.

Zitat

Für wirklich sehr gute Schreibraten, empfehlen wir unsere Root-Server mit SSD-Festplatten

Diese setzen wir dafür auch ein, die hohen Lese-/Schreibraten der SSD-Systeme kann ich bestätigen. Ich erwarte auch keine "wirklich gute Schreibraten" für SAS-Systeme. Aber 25 MB/s fällt nicht einmal unter "brauchbare Leseraten".

Zitat

200 IOPS ist bei der gebotenen Preis-Leistung unserer Meinung nach ein guter Wert, wenn Sie 8 TB am Stück schreiben möchten

Ich lese die 8 TB nur (externes Backup des Servers). 200 random-IOPs wären ein sehr guter Wert für festplattenbasierte Systeme. 200 IOPs bei linearen Lesen sind, wenn als "Abrechnungseinheit" 128k Blöcke gelten geradezu lächerlich (25 MB/s). Bei meinem Desktopsystem mit 2,5" Datenplatte kann ich mit "dd if=/dev/sdb of=/dev/null bs=128k" etwa 115 MB/s bei 900 IOPs lesen. Mit einer Blockgröße von 1 MB reichen für diesen Durchsatz 160 IOPs, was den tatsächlichen physikalischen Eigenschaften der HDD entspricht.

Wir planen unsere IT-Infrastruktur sehr sorgfältig und haben die Produkteigenschaften sowie auch eigene I/O-Benchmarks von älteren und neuen Systemen in die Planung mit einbezogen (allerdings offenbar ohne dabei die Drosselung zu triggern). Eine verborgene Drossel welche erst bei produktiver Load zum Vorschein kommt, ist eine Art von Überraschung, auf die ich gern verzichten kann.

Mit freundlichen Grüßen,

Michael Wyraz.

Hallo zusammen,

mir ist bei einem unserer Root-Server (S 8000 G7) aufgefallen, dass während des Backups die IOPs stark eingebrochen sind. Eine genaue Analyse hat gezeigt, dass die IOPs offenbar gedrosselt werden. Ich habe Verständnis dafür, dass die Server vor Überlast geschützt werden müssen. Keinerlei Verständnis habe ich jedoch dafür, auf welche Art und Weise dies geschieht und wie es kommuniziert wird.

Der Support hat, von mir darauf angesprochen, zunächst abgestritten, dass überhaupt gedrosselt wird. Von der Technik kam dann die Aussage, dass es keine festen Limits gibt und es sein kann, dass bei längerer Auslastung ggf. limitiert wird.

Dies habe ich zum Anlass genommen, ein paar Messungen durchzuführen.

Messung auf S 8000 G7, wenige Tage alt.

Beim linearen lesen mit 1 MB Blöcken (also keine Random-IO-Operationen) mit "dd if=/dev/sda of=/dev/null bs=1M" wird mit 200 MB/s gelesen. Dies erzeugt auf dem System 1600 IOPs. Das bedeutet eine I/O-Blockgröße von 128kb. Die IOPs scheinen auf allen S 8000 G7 auf 1600 limitiert zu sein.

Nach ca. 10 Minuten werden die IOPs auf 200 gedrosselt. Durch die Blockgröße von 128k bedeutet das eine Transferrate von 25MB/s.

Gedrosselt wird nicht nur, wenn die 1600 IOPs ausgelastet werden sondern sobald längere Zeit mit mehr als 200 IOPs bzw. mehr als 25MB/s gelesen werden. Das bedeutet, dass eine maximale Dauertransferrate von 25MB/s auf den Systemen nicht überschritten werden kann.

Damit dauert es über 116 Stunden, ein Vollbackup eines S 8000 G7 durchzuführen.

Für einen neu bestellten RS 4000 SAS G8SE a1 beträgt das initiale Limit 2000 IOPs / 250 MB/s, gedrosselt wird nach 10 Minuten I/O-Last auf 250 IOPs und 30 MB/s.

Auf mehreren älteren S 8000 G7 unterliegt die I/O Rate erheblichen Schwankungen zwischen 40 und 1600 IOPs, war jedoch im Mittel dauerhaft geringer als die 200 IOPs, so das ich nicht verifizieren konnte, ob auf den alten Systemen auch schon gedrosselt wird. Ich vermute, das die entsprechenden Hostsysteme recht stark ausgelastet sind.

Die reinen IOPs sind nicht das Problem (200 IOPs sind für SAS-Systeme sehr gut), jedoch ist die Transferrate, welche durch die 128k Blockgröße erzielt wird ein absolutes No-Go. Zum Vergleich: eine 2,5" Notebook-Platte (ST1000LM024) ließt sequentiell um die 115 MB/s bei 160 IOPs.

Ich bin der Meinung, dass eine solche Drosselung eine erhebliche Beeinträchtigung des Produktes darstellt und mindestens als Bestandteil der Produktbeschreibung offen kommuniziert werden muss. So kann jeder selbst entscheiden, ob ein Storage-Server, der dauerhaft nur 25 MB/s lesen kann für seinen Anwendungszweck tauglich ist.

Ich würde mich über ein klares Statement seitens Netcup bezüglich IOPs, Transferraten und Drosselung freuen.

Viele Grüße,

Michael.

PS: auf einem einzelnen S 8000 G7 habe ich in der Spitze eine sequenzielle Transferrate von 340 MB/s bei ca. 680 IOPs gemessen, was eine I/O-Blockgröße von 512k hinweist. Das zeigt, dass eine sinnvolle Balance zwischen IOPs und Transferrate technisch zumindest möglich ist.

PPS: Die Messungen auf den beiden neuen Systemen erfolgten aus dem Rescue-System heraus indem mit "dd if=/dev/sda of=/dev/null bs=1M" sequenzielle reads erzeugt und mit "iostat -x 1" die I/O-Statistiken ausgegeben wurden.