Frage rsync parallelisieren, , wie oft möglich?

Hinweis: In dem Thema Frage rsync parallelisieren, , wie oft möglich? gibt es 25 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Ich kopiere/verschiebe regelmäßig große Dateien (zwischen 200 und 300GB) zwischen Partitionen. Dafür schmeiße ich abends den rsync an. Das würde ich gerne in einem script weitestgehend parallelisieren.


    Eckdaten:

    4-Kern 3500er AMD64,

    32 GB RAM

    2 SSD 500GB

    2 externe HDD 1TB


    Plan bash-script


    Code
    rsync quelle1 ziel1 &
rsync quelle2 ziel2 & 
rsync ...

wait


    Ich finde nichts zu Zuverlässiges dazu, wie viele ich parallel starten kann.


    Ich meine ursprünglich war das mal für das synchronisieren von Serverdaten geschrieben, trotzdem ...

    Bremsen verwandelt hochwertigen Vortrieb in minderwertige Wärme und macht die Felgen dreckig.

    Für den Inhalt des Beitrages 329045 haftet ausdrücklich der jeweilige Autor: V-Treiber

    Bei solchen Kopieraktionen ist meist I/O der Flaschenhals, insbesondere bei Festplatten.


    Wenn also zwei rsync-Jobs auf unterschiedlichen Platten arbeiten, kannst Du sie ruhig parallel anwerfen - genügend CPU-Kerne und RAM vorausgesetzt.


    Muss eine Platte hingegen zwei parallele Jobs bedienen, wird sie womöglich zum ständigen Hin- und Herbewegen der Köpfe zwischen verschiedenen Bereichen gezwungen - und dadurch sehr langsam. Dann kann die Parallelverarbeitung sogar länger dauern als die einzelnen Jobs nacheinander.

    Für den Inhalt des Beitrages 329046 haftet ausdrücklich der jeweilige Autor: rkbwde

    Gefällt mir 1

    :) Ich sehe, wir verstehen uns! Wahrscheinlich erinnerst Du Dich auch noch an debug g-c800:5. :smilie_pc_012:


    Nein, es soll nicht zwischen Partitionen auf ein und der selben Platte kopiert werden, jedenfalls nicht parallel. Bei HDDs, ganz besonders externen, ist die mechanische Kopfbewegung der begrenzende Faktor, wobei das bei großen Dateien ob der Pufferung auch nicht so ins Gewicht fällt.


    Mir geht es mehr um die Puffer, die rsync anlegt und ob die Jobs auf die Kerne verteilt werden. :/

    Bremsen verwandelt hochwertigen Vortrieb in minderwertige Wärme und macht die Felgen dreckig.

    Für den Inhalt des Beitrages 329048 haftet ausdrücklich der jeweilige Autor: V-Treiber

    Gefällt mir 1

    Bei mir nutzen rsync-Jobs nur 1 CPU-Kern, RAM ist vernachlässigbar.

    Ich starte allerdings nur selten mehrere Jobs parallel.


    Pro Festplatte würde ich wie gesagt nur 1 Job starten, bei SSDs geht vielleicht mehr. Auch hier gilt: Versuch macht kluch :)

    Für den Inhalt des Beitrages 329049 haftet ausdrücklich der jeweilige Autor: rkbwde

    Fun Fact: Auf Arbeit spiegele ich (zumeist nachts) Daten per rsync zwischen den Servern.


    Dabei achte ich traditionsgemäß darauf, das die Jobs zeitversetzt laufen, um Platten und Netzwerk nicht unnötig zu stressen - auch wenn es heute dank schneller SSDs und 10Gbit/s-Netz wohl nicht mehr groß stören würde.

    Für den Inhalt des Beitrages 329052 haftet ausdrücklich der jeweilige Autor: rkbwde

    So ein Aufwand lohnt bei mir nicht. 1 Server, 3 Linux-Büchsen, 3 Windows-Büchsen, ein paar Androids(4?), GB-Netz, da ist nichts mit zwischen den Rechnern kopieren. War mal anders gedacht aber dann bin ich in die Beratung und sie in ein festen Job. Dafür lang es alle Mal. Damit ist der Automatisierungsbedarf auch relativ gering und ich bin in dem Thema inzwischen ziemlich blank.

    Bremsen verwandelt hochwertigen Vortrieb in minderwertige Wärme und macht die Felgen dreckig.

    Für den Inhalt des Beitrages 329054 haftet ausdrücklich der jeweilige Autor: V-Treiber

    Früher hatte ich auch nur 1-Gbit-Netz - da habe ich Differenz-Sicherung mit rsync (mit der Option --link-dest) als ziemlich effektiv erlebt, da nur Prüfsummen und die Änderungen übers Netz müssen.


    Auch in Deinem Setting könnte es sinnvoll sein, wichtige Daten vom Server regelmäßig per rsync auf einen der PCs zu spiegeln :/

    Für den Inhalt des Beitrages 329055 haftet ausdrücklich der jeweilige Autor: rkbwde

    Gefällt mir 1
    Zitat von rkbwde

    Auch in Deinem Setting könnte es sinnvoll sein, wichtige Daten vom Server regelmäßig per rsync auf einen der PCs zu spiegeln :/

    Dann taucht nachher meine Datensicherung in der Wiedergabeliste des Mediacenters auf. 8) Ich bin der Meinung, das ist der einzige der noch genug Platz hat.

    Bremsen verwandelt hochwertigen Vortrieb in minderwertige Wärme und macht die Felgen dreckig.

    Für den Inhalt des Beitrages 329060 haftet ausdrücklich der jeweilige Autor: V-Treiber

    Haha 1

    Nachdem ich hier mit hdparm, dd und lsusb rumgebastelt habe. -->


    Der HDD-I/O ich komme mit nichts über einen Schnitt von 36MB, was natürlich die Anzahl der parallel laufenden Zugriffe auf die HDDs deutlich beschränkt. Ich werde also max 2 rsync parallel laufen lassen und das dann über mehrere Nächte verteilen. (Ärgerlich)

    Mittelfristig wird es dann wohl ein paar externe SSD geben oder ein NAS.


    rkbwde

    Danke für Deine Beiträge.

    Bremsen verwandelt hochwertigen Vortrieb in minderwertige Wärme und macht die Felgen dreckig.

    Für den Inhalt des Beitrages 329075 haftet ausdrücklich der jeweilige Autor: V-Treiber

    36 MB/s wäre erstaunlich wenig - aktuelle SATA-Platten sollten ca. 100 MB/s schaffen :/


    2 Dinge fallen mir noch ein:

    • HDDs mit Shingled Magnetic recording (SMR) erreichen höhere Speicherdichten, sind aber langsam.
    • Einige Platten haben phys. Sektorgrößen von 4k - da sollte auch das Filesystem mit 4k-Blöcken arbeiten.

    Für den Inhalt des Beitrages 329112 haftet ausdrücklich der jeweilige Autor: rkbwde

    Gefällt mir 1