HBS3 Sync sehr langsam in GbE Lan mit Error Code: -62

    Mache mein erster Versuch um Daten vom alten NAS TS-259 Pro+ zum neuen TS-453D zu schaufeln und das läuft zu langsam. Mit HBS3 Ein-Weg-Sync über RTRR in GbE Lan ist es mit ~5 MB/s zu langsam, und später kammen Errors mit Code: -62.


    Zuerst 1 mal...

    Code
    Message: [Hybrid Backup Sync] Failed to complete Sync job: "xxx". Connection timed out. Check connection to device.. Check logs for more information.

    ...und spätter ...

    Code
    Message: [Hybrid Backup Sync] Failed to complete Sync job: "xxx". Connection timed out. Check connection to device. Error code: -62

    immer wieder. Sync wurde nicht abgebrochen. Bai ~990 GB Daten hat er ~36% in 24h geschaft.


    Wo kann der Hacken liegen?

    Bitte um Tipps!

    Klingt erstmal nach Netzwerkproblemen... befinden sich beide NAS im selben Netzwerk? War das Ziel auch ganz sicher die ganze Zeit eingeschaltet?

    Wenn es erstmal nur darum geht die Daten rüber zu bekommen würde ich das eher über einen PC machen, damit das betagte 259 Pro nicht so viel arbeiten muss. Wie sah denn die Systemauslastung bei den beiden NAS aus als der Job lief bzw. wenn er läuft?

    tiermutter

    Beide sind an ein GbE Netgear 5x Rj Switch. CPUs sind nicht sehr belastet, 259er bei ~25% (qsyncd ~20%) und 453er bei ~6% CPU last.


    Netz wird mit GbE/Full Dublex bei den RJ-Leds angezeit, und jetzt nach kurzes Samba Kopie Test zw. 259er<->PC<->453er von 5GB in beide Richtungen geht mit ~58 MB/s schnell!


    259er:

    test-259er.png


    453er:

    test-453er.png



    Der Sync Auftrag rennt noch, langsm, aber doch.

    Was für Dateien sind es denn und wie sieht der RAM beim 259 aus?

    tiermutter :

    Nun, es waren CD/DVD-Images. Mem am 259er war ok.

    mem-259er.png

    Übrigens, beide hängen immer nur mit 1 Eth am LAN!


    Nun gibts auch Updates! :cup:


    Hab den Auftrag gestoppt, und die Sync Regeln geändert:

    • Komprimierung bei Übertrageng aus, und
    • Netzwerk von Auto auf Standard-Route gestzt.

    Ich weiss nicht welches vom beiden hillft, aber habs gestartet, und jetzt schoss es bis ~107 MB/s hinauf!


    Habe später duzu synchron einen 2 Auftrag mit viele klene Dateien gemacht und gestartet. Der ging nur bis ~5 MG/s und der alte runter auf ~90 MB/s. Als der alte Auftrag fertig war, blieb der neue niedrig. Nach ein neustart vom neuen Auftrag ging es nur langsam, aber dann nach etwas Zeit ~5 Min. wurde es lansam schneller bis ~75 MB/s und blieb dabei.


    PS: Beide gehen auf versch. Thin-Volumes, versch. inode, und ohne Snapshots.

    Komprimierung im LAN ist nicht notwendig, damit experimentiert man bei der Übertragung übers WAN und selbst da bringt es oft so gut wie nix an zusätzlicher Datenrate.


    Thin Volumes sind das langsamste was man nutzen kann, da hier erst noch mal der Speicherplatz zugeteilt werden muss und erst dann Daten geschrieben werden können.


    Konvertiere das man in ein Thick, das ist schneller und du kannst nicht mehr einfach Überbuchen.

    Das kann böse enden wenn du den Pool bis zum Anschlag voll schreibst.

    Auf die Komprimierung hätte ich schon vorher kommen können X/

    Durch Thin Volumes habe ich bei mir keine Einschränkungen was die Übertragungsrate angeht.

    Ich hatte wärend meinem Backups auch eine Fehlermeldung bekommen ( I/O Error ) jedoch dazu keine weiteren Infos bekommen.....

    Im Helpdesk habe ich dann eine protokolldatei erstellt, und mir diese dann angeschaut, und bin dort dann fündig geworden ;)

    Evtl. hilft dir das auch weiter.

    Crazyhorse & tiermutter


    Zur Komprimierung dachte ich zuerst auch, dass es im LAN nicht notwendig ist. Aber bei knapp 1 TB herum schaufeln, dachte ich dann: Hey was solls, wird noch schneller.


    Anscheinend hat der alte 259er Schwierigkeiten damit, weil die CPU bei der Arbeit durch Thread Wechsel dauernd so gestört war:

    cpu-259er.png

    Ohne Komprimierung ging es flüßiger!


    Zu Thin Volumes habe ich nicht so das Gefühl, dass sie das langsamste sind. Vorher waren es zum testen auch Thick & Einzel Volume ohne RAID, und so echte Unterschied bzw. Nutzen Verlußt konnte ich bei 2 TB Restore (über SAMBA Umwege) am Speed hier nicht sehen.


    Gut, womöglich wenn wenig Platz frei ist und Snapshots weg müssen, erst dann könnte es bei der Speicherplatz Zuteilung stressig werden.


    Ich halte mich jetzt an den Blog Tipps hier:

    Mein Wechsel von einem statischen Volume zu einem Speicherpool ;)


    Andreas1202 :

    Zitat von Andreas1202

    eine protokolldatei erstellt, und mir diese dann angeschaut, und bin dort dann fündig geworden

    Wo genau? Da steht nicht mehr als im QTS Logs. :)

    Andreas1202 :

    Ja eh, die Helpdesk Prokolldateien habe/kenne ich, aber so ist es, ohne ein genaueren Hinweis wo dort genau Etwas zu HBS oder qsync zu finden ist, kaum hilfreich! :/

    Ich muss zugeben, dass ich in dem log auch nicht wüsste, wo es (explizite) Anhaltspunkte zu HBS geben sollte. Man könnte das Log aber zu den Zeiten anschauen, wenn ein Job fehl schlägt... Wenn das. Problem systemseitig ist, taucht da evtl ein Grund auf... Sonst wüsste ich nichts.