Ubuntu Server Rsync / SFTP langsam Samba schnell

SeeD

Lt. Junior Grade
Registriert
Aug. 2009
Beiträge
451
Hallo zusammen,

ich baue mir aktuell ein eigenes NAS auf Ubuntu-Server basis auf. Leider hakelt es aktuell sehr an der Performance beim schreiben und ich bin ein wenig Planlos.

Aktuell habe ich folgende Datenraten beim schreiben einer Beispieldatei (Video 1GB größe) auf eine HDD:

Samba Freigabe ~ 80-100MB/s
SSH / SFTP ~ 18-20 MB/s
Freigabe und dann Rsync ~30MB/s

Das ganze über Gigabit Lan auf einen Server mit Intel Celeron N3150 mit 4 GB Ram


Was mich irritiert ist, dass der Server durchgängig bei 30% (rsync) bzw. 40% (sftp) Cpu Last rumlungert, also an der Cpu kann es nicht liegen. Der Ram ist auch nicht wirklich gefordert. Um Netzwerkprobleme auszuschließen habe ich die Rechner auch schon nebeneinander gestellt und mit einem Cat6 Kabel direkt verbunden und kontrolliert, dass beide auch defintiv auf 1Gb stehen.


Habt ihr da irgendwelche Ideen? Klar ist Samba schneller, aber um den Faktor 5 dürfte es doch nicht sein oder?




Durchgängig nur Samba nutzen möchte ich eigentlich nicht, da der Connect zu dem Server immer nur dann hergestellt sein soll, wenn das Backup durchgeführt wird. Ansonsten wäre mir hier im privaten Rahmen eine verschlüsselung der Daten tatsächlich nicht so wichtig.

Ich wäre also auch für alternative Wege offen ;)

Mein Ziel ist also: Datensync der lokalen (Windows) Platte auf den Linuxserver automatisiert, incl. Herstellung der Verbindung zum Server im Zuge der Synchronisierung bei ordentlichen Datenraten

Danke euch

Beste Grüße
SeeD
 
Zuletzt bearbeitet:
Der Celeron ist zu langsam die Verschlüsselung mit 100MByte/s zu bedienen. Kompilier die SFTP libs mit AES-NI Support, nutze AES, das sollte helfen. Oder nutze rsync ohne Verschlüsselung.
 
Hallo,

aber warum liegt die Cpu Last dann unterhalb von 50%? Das ist mir unerklärlich.

Ergänzend noch:

- Lokaler Mount über Samba und dann RSync über Qtdsync oder Deltacopy = 30Mb/s

Beste Grüße
SeeD
 
Zuletzt bearbeitet:
Zuletzt bearbeitet:
Kannst ja probieren, ob ein zweiter rsync auch 30 MB/s bekommt, oder ob sich beide die 30 MB/s teilen. In ersterem Fall ist wahrscheinlich die Single-Thread-Leistung CPU der Flaschenhals.

Für AES-NI sollte es genügen, die Cipher auf aes256-gcm@openssh.com zu wechseln, ohne irgendwas neu zu kompilieren.
 
rsync: keine Ahnung
ssh: Da im vorliegenden Fall weder CPU noch I/O die Begrenzung darstellen, liegts sehr wahrscheinlich nicht am Kryptokram. Dann hilft auch kein Wechsel auf einen anderen Algorithmus. Wenn Fileübertragungen mit ssh über schnelle Verbindungen und/oder Verbindungen mit langer Paketlaufzeit weit lahmer sind als die Verbindung theoretisch erlaubt, liegt es i.d.R daran. Patches sind dort verlinkt.
 
Zurück
Oben