Drosselung des Festplattendurchsatzes bei Root-Servern bis zur Unbrauchbarkeit

  • Wo widerspricht das jetzt meiner Aussage?

    Du hast ursprünglich geschrieben:

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

    Und der erste Satz stimmt eben nicht.


    rsync überprüft die Prüfsumme nur, wenn man --checksum angegeben hat. Und dann eigentlich nahezu immer, außer die Dateigröße hat sich geändert.


    Soll heißen: rsync --checksum überprüft die Prüfsumme auch, wenn size/mtime identisch sind. Hingegen rsync [--no-checksum] vergleicht die Prüfsummen nie, auch nicht, wenn sich size/mtime geändert hat. Ohne --checksum kommt es somit immer zu einer Übertragung, sobald size/mtime anders sind – auch bei identischem Inhalt!

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

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

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

    Wunderbar, danke vielmals.


    War hier im Thread bislang nur "stiller Mitleser".


    Habe bis 29.01.2019 eine tägliche Datensicherung meines RS 500 SAS G7SEa1 mittels Veeam Backup Agent for Linux durchgeführt, ab 30.01.2019 war mir dies nicht mehr möglich, da nach ca. 20min die Disk-IO (Lesen) auf 1-8MB/Sek eingebrochen ist. Habe Veeam dann nach einigem Tüfteln - da nicht mehr praktikabel verwendbar - deaktiviert und die letzten Monate ein file-basiertes Backup mit Duplicity verwendet.


    Motiviert durch diesen Thead habe ich heute mein damaliges Veeam-Backup erneut versucht (Config und Version unverändert wie im Jänner/Februar) => Klappt nun wieder problemlos. Disk-IO Lesen >30MB/Sec - der Backup Job ist in erwarteten 1,5 Stunden durchgelaufen.


    => Danke vielmals [netcup] Felix P. für die Änderung und auch an den Thread-Ersteller geomap und allen Mitwirkenden für das Aufzeigen und Dokumentieren dieser Problematik!

  • Habe dieses Problem besonders in den Backupzeiten, dort ist mein server meist offline