Drosselung des Festplattendurchsatzes bei Root-Servern bis zur Unbrauchbarkeit

  • Es ist halt schwierig hier pauschale Auskünfte zu tätigen. Bei VPS die auf viel Speicherplatz und niedrigem Preis optimiert sind, geben wir keine Garantie für IO-Durchsatz. Das tut ja niemand in dem Preissegment. Wer möchte kann bei uns schnelle SSDs als Storage einkaufen. Das kostet halt etwas mehr.


    Bei unseren Root-Servern mit SSD-Storage garantieren wir besseren Durchsatz als eine normale Desktop-SSD ihn bietet. Das ist unser Anspruch. Wir schalten hier viele Enterprise-SSDs parallel und bekommen so extrem gute Werte. Wir schlagen damit jeden dedizierten Server aus dem Niedrigpreissegment.


    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.


    Wir können nie einzelne Fehler ausschließen. Bitte kontaktieren Sie uns dann via E-Mail mit einem entsprechenden Nachweis.


    Vielen herzlichen Dank!



    Mit freundlichen Grüßen


    Felix Preuß

  • Sollte ich die Intention des TEs richtig verstanden haben, geht es hier jedoch rein um die Erwähnung der Limitierung auf der Produktseite. Ich denke, dass generell keine Unzufriedenheit mit der P/L vorhanden ist sondern lediglich mit der Informationspolitik dem Kunden gegenüber bezogen auf genau dieses Thema.


    Eventuell passendes Beispiel: Unlimitiert Speicher aber Inodes limitieren

    Umgemünzt: SAS bewerben, jedoch Geschwindigkeiten bieten, welche von Laptop-HDDs übertroffen werden können


    lg.

  • Das IO-Leistung irgendwie limitiert ist, ist doch logisch, oder? Es gibt bei uns keine zusätzliche absichtliche Limitierung.


    Wir betreiben ein faires Scheduling auf geteilten Systemen. Andernfalls kann ein einzelner Kunde ja die gesamte IO-Performance nutzen.


    Wenn hier noch Klärungsbedarf besteht, probiere ich diesen sehr gerne zu lösen. Eventuell verstehe ich noch nicht worum es genau geht.

  • 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.

    Das ist soweit ich dies herauslesen konnte der Punkt um den es geht.

    Die starke Beschränkung beim Lesen über einen mittellangen Zeitraum bei gleich oder mehr als 200 IOPs. Somit ist bei Storage Servern die Transferrate bei 128k Blockgröße auf 25MB/s beschränkt und dies sollte imho irgendwo erwähnt werden.


    Ich versuche nur nochmals aufzuzeigen wo meiner Meinung nach das Problem des TEs und einigen Kunden hier im Thread ist und dies nochmals klar zu vermitteln. Don't blame me. :)

  • Hallo :)

    Wenn hier noch Klärungsbedarf besteht, probiere ich diesen sehr gerne zu lösen. Eventuell verstehe ich noch nicht worum es genau geht.


    Ich denke es geht vielen um das hier was Michael gesagt hatte


    * 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.

    Ich erwarte auch keine "wirklich gute Schreibraten" für SAS-Systeme. Aber 25 MB/s fällt nicht einmal unter "brauchbare Leseraten".

    Eine verborgene Drossel welche erst bei produktiver Load zum Vorschein kommt, ist eine Art von Überraschung, auf die ich gern verzichten kann.


    Sowie diese Punkte

    Offenlegung von für Kunden bedeutsamen Produkteigenschaften essentiell für eine friktionsfreie Geschäftsbeziehung respektive eine gute Kundenbindung ist.

    Aber Details, wie sie geomap nennt, wären sehr wohl schon vor der Bestellung interessant.


    Aber etwas mehr Transparenz hinsichtlich dessen von Netcup würde ich mir doch schon Wünschen.


    Viele wünschen sich Transparenz (vor der Bestellung) und eine offene ehrliche Kommunikation.

  • Es ist halt schwierig hier pauschale Auskünfte zu tätigen. Bei VPS die auf viel Speicherplatz und niedrigem Preis optimiert sind, geben wir keine Garantie für IO-Durchsatz. Das tut ja niemand in dem Preissegment. Wer möchte kann bei uns schnelle SSDs als Storage einkaufen. Das kostet halt etwas mehr.

    Das „Problem“: es gibt keine Angebote mit 1,5 TB SSD Speicher.


    Ich für meinen Teil habe heute mal einen Test mit einem 300GB Borg Repository gemacht. Die Aufgabe war es einmal auf den VPS Ibizza per rsync abzugleichen und einmal auf eine ZFS Raid1/Mirror Disk. Natürlich ist die Netzwerkverbindung anders. Zu meiner Überraschung dauerte es auf das Netcupsystem 70 Minuten. Auf das externe System 50 Minuten. Das ist nicht soo weit weg. Ich wurde nun aber etwas stutzig, da ich weiß, dass der VPS schon mehrere Stunden für den Abgleich benötigt hat. Also habe ich im SCP mal die IOPS Werte angeschaut. Siehe da: seit nichtmal einer Woche gibt es eine deutliche Leistungssteigerung bei den IOPS. Wobei die Grafiken für 31 Tage leider gar nicht die ganz hohen Spitzenwerte ausweist, sondern nur die für die letzten Stunden.


    Generell ist es krass wie viel IO Leistung rsync verbrät. Müsste ich glatt mal nach Alternativen suchen...

  • Also habe ich im SCP mal die IOPS Werte angeschaut. Siehe da: seit nichtmal einer Woche gibt es eine deutliche Leistungssteigerung bei den IOPS.

    Ich weiß gerade nicht, wie ich das deuten kann.

    Wie stellst du über das SCP fest, dass du mehr Leistung zur Verfügung hast?

  • 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.

  • Vielen Dank für Ihre Rückmeldung und Ihre Konkretisierung der relevanten Punkte.


    Ich kann nur nochmals betonen, dass wir keine genauen Werte zu IOPS bei unseren kostengünstigen VPS veröffentlichen oder gar garantieren. Das geht in so einem Markt nicht. Es kann im laufe einer Produkt Generation hier durchaus zu Änderungen kommen, da das Nutzungsverhalten sich ändert, z.B. wenn wir einen weiteren Intel-Patch einspielen müssen. Mehr Transparenz geben wir in dem Preissegment nicht. Das tut auch keiner unserer Mitbewerber der eine vergleichbare Preis- Leistung anbietet.


    Wir sehen ein Scheduling nicht als Drosselung an. Daher resultiert vermutlich die Aussage aus unserem Support. Ich möchte mich dafür Entschuldigen, wenn dieses anders verstanden wird. Es ist nicht unsere Absicht Kunden zu täuschen. Daher gehen wir hier auch ganz offen damit um, dass wir bzgl. IOs nichts garantieren. Dennoch werde ich mich heute mit dem Teamleiter des Supports unterhalten um zu erfragen, wie unsere Support-Mitarbeiter diesbezüglich geschult sind. Alternativ können Sie auch eine Beschwerde bei der Beschwerdestelle zu dem Ticket einreichen, damit wir in der Zukunft sicher stellen das hier klar und deutlich kommuniziert wird, dass wir keine IO-Garantien bei VPS und Storage-Servern geben können.


    Noch ein vielleicht wichtiger Hinweis in der Sache:


    Bzgl. rsync darf nicht vergessen werden, dass dieses je nach Anwendung einiges an CPU-Last erfordert. Dieses kann auch ein limitierender Faktor sein.


    Zitat

    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.


    Ich habe dazu eben eine Anfrage bei unserer Technik aufgemacht um zu 100% sicher stellen zu können, dass meine vorherige Aussage dazu stimmt. Ich kann leider auch Fehler auf meiner Seite nicht zu 100% ausschließen.


    Zitat

    Das „Problem“: es gibt keine Angebote mit 1,5 TB SSD Speicher.


    Auf Anfrage können wir hier sicherlich etwas manuell erstellen. Natürlich wird dieses dann einen marktüblichen Preis haben.


    Alternativ können Sie auch unseren RS 8000 mit SAS-Festplatten verwenden. Die SAS-Festplatten bieten hier eine bessere Performance, als sie manch ein Marktbegleiter mit SSDs anbietet. Der Vorteil liegt darin, dass wir einen recht großen Cache verwenden und zudem viele parallele Spindeln einsetzen.


    Ein Update folgt, sobald ich mehr weiß. Vielen Dank für Ihre Geduld!



    Mit freundlichen Grüßen


    Felix Preuß

  • Guten Tag,


    ich habe ein Update für Sie:


    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.


    Vielen Dank und morgen einen angenehmen Feiertag!



    Mit freundlichen Grüßen


    Felix Preuß

  • Noch ein vielleicht wichtiger Hinweis in der Sache:


    Bzgl. rsync darf nicht vergessen werden, dass dieses je nach Anwendung einiges an CPU-Last erfordert. Dieses kann auch ein limitierender Faktor sein.

    Es ist mir auch schon aufgefallen, dass rsync einen Kern voll auslastet, aber nicht mehr. Ich werde jetzt mal auf dem VPS Ibizza die Checksummen basierte Prüfung deaktivieren und schauen wie sich das auswirkt.


    Zitat

    Auf Anfrage können wir hier sicherlich etwas manuell erstellen. Natürlich wird dieses dann einen marktüblichen Preis haben.


    Alternativ können Sie auch unseren RS 8000 mit SAS-Festplatten verwenden. Die SAS-Festplatten bieten hier eine bessere Performance, als sie manch ein Marktbegleiter mit SSDs anbietet. Der Vorteil liegt darin, dass wir einen recht großen Cache verwenden und zudem viele parallele Spindeln einsetzen.

    Dann wäre aber der RS 8000 zunächst mal der Versuch wert, wenn die geänderten rsync Optionen auch keinen Erfolg bringen.

  • […] Checksummen basierte Prüfung […]

    Wenn man dieses Feature verwendet, ist eine hohe Auslastung nicht verwunderlich. rsync muss dann alle (!) Dateien mindestens einmal vollständig von der HDD lesen.


    Wenn man sich hingegen nur auf Dateigröße und Modification-Time verlässt, geht der Abgleich wesentlich schneller und braucht kaum Ressourcen. Außer bei Beibehaltung der Hardlinks und vielen Dateien, das kostet natürlich massiv RAM. Ob man einen Prüfsummenabgleich wirklich braucht, hängt vom zu synchronisierenden Inhalt ab, und wer darauf Zugriff hat.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Wenn man dieses Feature verwendet, ist eine hohe Auslastung nicht verwunderlich. rsync muss dann alle (!) Dateien mindestens einmal vollständig von der HDD lesen.


    Wenn man sich hingegen nur auf Dateigröße und Modification-Time verlässt, geht der Abgleich wesentlich schneller und braucht kaum Ressourcen. Außer bei Beibehaltung der Hardlinks und vielen Dateien, das kostet natürlich massiv RAM. Ob man einen Prüfsummenabgleich wirklich braucht, hängt vom zu synchronisierenden Inhalt ab, und wer darauf Zugriff hat.

    RSync benutzt den Checksummenvergleich nur, falls sich Größe oder Mtime der Datei geändert haben. Oder falls man `-c` angegeben hat.

  • RSync benutzt den Checksummenvergleich nur, falls sich Größe oder Mtime der Datei geändert haben. Oder falls man `-c` angegeben hat.

    Nicht ganz richtig: Wenn sich die Größe geändert hat, wurde die Datei offensichtlich verändert. Dann erfolgt immer eine Übertragung. Ob die ganze Datei neu übertragen wird, hängt davon ab, ob der Delta-Algorithmus aktiv ist.


    Ohne --checksum findet niemals ein Prüfsummenvergleich statt! In diesem Fall wird standardmäßig nur die Dateigröße und Modification-Time vergleichen. Es könnte somit jemand den Inhalt der Datei verändern, ohne dass es rsync bemerkt:

    Die Dateien haben nun einen unterschiedlichen MD5-Hash, trotzdem findet ohne --checksum keine Übertragung statt.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bei mir ist es ein Borg Backup, das gesynced wird. Ab morgens wird es nicht mehr geändert. Keine Ahnung woher ich die rsync Optionen genommen habe.


    Ich schätze, dass sich in meinem Fall die checksum Option negativ auswirkt, da es um sehr viele Daten geht und die dann erstmal alle gelesen werden.


    Ich werde das die nächsten Tage beobachten.