Performance rsync DS118 mit SSD unterirdisch

louis84

Cadet 3rd Year
Registriert
Feb. 2020
Beiträge
35
Hallo zusammen,

ich nutze eine DS118 - ich brauche nur eine Festplatte - als NAS für diverse Rechner. Auf dem NAS liegen derzeit 2,2 TB, darunter viele Fotos und weitere kleine Dateien. Auf meinem PC mit Linux Mint ist eine verschlüsselte SSD, in der die Daten des NAS ebenfalls liegen. Auf dem NAS liegen die Daten ebenfalls in einem verschlüsseltem Bereich. Um die Performance zu erhöhen habe ich meine 6 TB Festplatte gegen eine SSD ausgetauscht. Ich dachte gerade die Verarbeitung der vielen kleinen Dateien würde sich dadurch verbessern. Das System ist auch in Summe performanter geworden, aber eine Übertragung alle Daten von einem sehr performanten PC auf das Synology NAS dauert ca. 4 Tage, trotz Gigabit Netzwerk. Das ist für mich nicht akzeptabel und ich suche nun nach einer Lösung.

1. Software: Liegt es vielleicht daran, das rsync via SMB bei vielen kleinen Dateien einfach nicht die beste Lösung ist? Dazeit mounte ich die Freigabe via SMB in das Linux Filesystem und führe dann rsync durch. Zukünftig sollen PC und NAS regelmäßig den Datenbestand abgleichen und syncen.

2. Hardware: Wenn sich das mit Software nicht lösen lässt, denke ich über einen selbst konfigurieren Home Server nach. Auf welche Komponenten kommt es hier eurer Meinung nach an, um den Sync-Vorgang deutlich zu beschleunigen?

Schon einmal vielen Dank und viele Grüße in die Runde!
 
eine Samsung 870 QVO 4TB SATA 2,5 Zoll Internes Solid State Drive (SSD)
 
Mordenkainen schrieb:
Nun, du hast eine QLC-SSD. Die haben das Problem dass sie ziemlich schnell bei größeren Schreiboperationen langsam werden, deswegen sind sie auch so günstig.
2,2TB in 4 tagen sind 6,7MB/s - das schafft jede qlc-ssd. @louis84 kannst du auf auf dem nas rsync direkt bzw. über ssh ausführen? dann kann man das mal ohne smb probieren.
Ergänzung ()

louis84 schrieb:
Auf welche Komponenten kommt es hier eurer Meinung nach an, um den Sync-Vorgang deutlich zu beschleunigen?
ich habe letztens mit mehreren TB rsync über ssh von einem system mit 2400g auf eins mit einem athlon 200ge gemacht. bei ssh die kompression deaktivieren und die gigabit-verbindung war ausgelastet. man braucht also nicht viel dafür.
 
Zuletzt bearbeitet:
Hallo zusammen, danke für die Rückmeldung! Ich habe zwischenzeitlich gelesen, dass
a) rsync generell langsamer ist als z.B. klassisches kopieren (teilweise nur 25% zu schnell)
b) Synology rsync wohl ziemlich schlecht implementiert hat

Danke für Eure Rückmeldung. Ich hab auch das Gefühl, das da was generell nicht stimmt. Das ist zu langsam. Die Idee das direkt über ssh zu machen versuche ich mal. Das könnte eine weitere Ursache sein.

Wenn schon ein 2400g die Leitung komplett auslastet, klingt die Idee eines Home Servers immer verlockender ...
 
Nutzt du WLAN oder Kabel?
Wie schnell geht der Transfer via scp?

Wie schaut der transfer aus, wenn du rsync parallelisierst?
ls /srv/mail | xargs -n1 -P4 -I% rsync -Pa % myserver.com:/srv/mail/
 
louis84 schrieb:
Ich hab auch das Gefühl, das da was generell nicht stimmt. Das ist zu langsam.
Was bedeutet langsam konkret? Du hast bisher keine Zahlen genannt und auch keinen Vergleich beim Kopieren einer einzigen großen Daten (ein paar GB). Dabei müsstet Du auf 110-115 MByte/s kommen. die 4TB Variante sollte gemäß Tests im Internet auch ohne SLC-Cache noch max. 160 MByte/s schreiben können.

Außer, das NAS ist zu langsam um die Daten in der Zeit zu verschlüsseln
"Auf dem NAS liegen die Daten ebenfalls in einem verschlüsseltem Bereich"
Dann ist es vorher mit der HDD mit großen Dateien auch nicht auf die 110-115 MByte/s gekommen und die SSD kann natürlich nichts bringen.

Die DS218 bricht dabei laut CB-Test nicht ein, das sollte also mit der DS118 nicht das Problem sein.

Also gehe ich eher in eine andrere Richtung:
  • Wie groß sind die Bilder/Datein (eher 1-3MB oder 50MB)
  • wie viele Dateien sind es
  • wie wird kopiert (immer eine Datei nach der anderen oder viele parallel, rsync kopiert bei mir immer nur eine Datei, aber u.U. kann man das, wie bei robocopy, parametrieren)

Nur so als ein Beispiel, dass das Problem u.U. (je nach Dateianzahl und Größe) nichts mit der Hardware zu tun hat:

Quelle: PC mit SSD
Ziel: NAS, bzw. mein alter PC mit HDD (WD Red 8TB) als Ziel
Netzwerk: 10 GBase-T

Kopiere ich 541 Bilder (15,2 GB, ca. 28 MB/s pro Bild) vom PC aufs NAS, komme ich auf 125-150 MB/s (je nachdem, auf welchen Bereich der HDD Linux gerade schreiben muss). Bei großen Dateien sind es 140-180 MB/s.

Mache ich das ganze mit nur 13 MB großen Bildern, bleiben nur noch 110-120 MB/s übrig. Und nehme ich 7500 Datein mit jeweils 20-30 KB, dann bleiben trotz 10 GBit Anbindung nur noch knapp 3 MB/s Übertragungsrate übrig.

Kopiere ich die selben Daten mittels robocopy /MT:8 (also mit 8 Copy-Threads parallel), komme ich bei den 28 MB Bildern auf 182 MB/s (mehr kann die WD Red nicht) und bei den 20-30 KB Dateien trotzdem nur auf 8,6 MB/s. Für bedeutend mehr müsste man das Ram im NAS noch viel intensiver als Cache nutzen wie Linux (oder auch Windows) das standardmäßig macht und die damit verbundenen Risiken in Kauf nehmen.

Die erwähnten 7500 kleinen Dateien (bzw. insg. wären es gut 400k so kleine Dateien gewesen) habe ich aus Frust auf dem Quell-PC gepackt, das ZIP-Archiv kopiert und auf dem "NAS" lokal wieder entpackt. Das ging insg. erheblich schneller, ist auf einem Fertig-NAS aber meist keine Lösung.
 
Zuletzt bearbeitet:
Vielen Dank madmax2010 und gymfan. Noch ein paar Infos zum generellen Setup: Die PCs sind per Gigabit LAN verbunden, über einen Unify Switch, via CAT 7 Kabel, insg. 3 Meter Strecke. Daran sollte es nicht liegen.

Ich habe jetzt einmal einen Test mit der HighCharts Bibliothek durchgeführt, da viele kleine Dateien:
37.978 Objekte, mit insgesamt 609,8 MB

scp: 36 Sekunden - ca. 17 MB pro Sekunde
rsync parallel (mit dem Code von madmax2010): 160 Sekunden - ca. 3,8 MB pro Sekunde
rsync nicht parallel via samba: ca. 6 Dateien pro Sekunde, ich habe nach 15 Minuten abgebrochen, nachdem ca. 4000 Dateien und 218 MB kopiert wurden.

Es liegt also wie von Euch beiden vermutet daran, dass rsync die vielen kleinen Dateien sequenziell langsam abarbeitet. RSync parallelisiert und ohne Samba zu nutzen ist glaube ich ein sehr guter und ausreichend performanter Mittelweg. Auch robocopy könnte noch mal interessant sein.

Vielen Dank schon einmal!
 
madmax2010 schrieb:
Nutzt du WLAN oder Kabel?
Wie schnell geht der Transfer via scp?

Wie schaut der transfer aus, wenn du rsync parallelisierst?
ls /srv/mail | xargs -n1 -P4 -I% rsync -Pa % myserver.com:/srv/mail/

Mhm, bei kleineren Ordnern klappt es super. Möchte ich die 2,2 TB syncen, fragt er immer nach dem Passwort und akzeptiert das dann nicht. Ich habe gerade gelesen, dass man das umgehen kann, indem man auf SSH setzt. Dafür muss ich aber auf dem Synology NAS einen Admin User nutzen und der Traffic wird verschlüsselt, was für die Performance nicht zuträglich sein sollte.

Gibt es eine Möglichkeit das Passwort mit zu übergeben? RSYNC_PASSWORD="abcdef" klappt nicht. Es gibt noch das Paket sshpass, aber das bekomme ich gerade nicht mit xargs kombiniert. Und zuletzt gibt es glaub ich noch die Möglichkeit einen rsync Deamon zu nutzen und das Passwort in einer Datei abzulegen. Auch das klappt derzeit bei mir nicht. Wie hast Du das gelöst?
 
was klappt super?
scp? rsync parallelisiert?

was passwoerter angeht: Public keys nutzen ;)
 
Also scp und rsync ohne Samba funktioniert super. Das Script scheint nur einen Prozess genutzt zu haben, wenn wenig Dateien kopiert werden. Daher ist das Kopieren der 40.000 Dateien in 160 Sekunden als Benchmark für rsync direkt (also ohne samba) aber nicht parallel zu werten.

Parallel habe ich wegen der Login Problematik dann noch gar nicht hinbekommen. Alles klar, public key, also doch ssh. Da scp ja deutlich performanter war, sollte die Transprort-Verschlüsselung vermutlich die Performance nicht stark reduzieren.

Der Sync mit rsync in einem Prozess läuft übrigens gerade durch. Auch bei großen Dateien ist bei 50 MB / Sekunde das Limit erreicht. Und das obwohl CPU und Ram auf beiden Geräten nicht ausgelastet sind. Ich wundere mich, das da nicht mehr möglich ist. Aber immerhin nicht mehr dieses Faktor 1000 langsamere rsync via samba. Das hat mir schon sehr geholfen!
 
Zurück
Oben