Ubuntu Server Rsync / SFTP langsam Samba schnell

[SeeD]

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

 

[HominiLupus]

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.

 

[SeeD]

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

 

[Troublegum]

Ich würde auch die CPU vermuten. SSH ist nunmal verschlüsselt. Vielleicht wird ja auch nur ein Kern ausgelastet. Aber nur ~20MB/s finde ich auch wenig. Da schafft ja meine imx6-ARM CPU fast mehr.

Kannst ja auch mal herumtesten:
http://www.cyberciti.biz/faq/how-to-find-out-aes-ni-advanced-encryption-enabled-on-linux-system/
https://bbs.archlinux.org/viewtopic.php?id=9107
http://stateless.geek.nz/2004/10/13/scp-performance/

 

[chithanh]

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.

 

[mensch183]

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.