Gigabit wird nicht erreicht

[Alternativende]

Hallo zusammen,
ich setze derzeit ein neues NAS auf und habe etwas Probleme mit der Netzwerkperformance. Als System kommt OpenMediaVault zum Einsatz und getestet habe ich folgendes.

An einem 5 Port Gigabitswitch von Netgear hängt eben besagtes NAS und mein Debiandesktop. Beim schreiben übers Netzwerk komme ich nun maximal auf 300Mbit und bin noch weit entfernt von den avisierten 1Gbit. Beide Netzwerkkarten werden als Gigabit erkannt, die Verkabelung ist ok, andere Clients greifen nicht auf das NAS zu. Geschrieben wurde über SSHFS.

hdparm Desktop

Code: Alles auswählen

# hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   20366 MB in  2.00 seconds = 10191.48 MB/sec
 Timing buffered disk reads: 348 MB in  3.01 seconds = 115.79 MB/sec

hdparm NAS, Softwareraid 1

Code: Alles auswählen

# hdparm -tT /dev/md0

/dev/md0:
 Timing cached reads:   6926 MB in  2.00 seconds = 3467.02 MB/sec
 Timing buffered disk reads: 522 MB in  3.01 seconds = 173.48 MB/sec

Da muss doch mehr drin sein oder?

[feltel]

SSHFS verschlüsselt aber den Datentransfer und ich denke nicht, das das NAS so wahnsinnig viel CPU-Reserven hat, als das es entsprechende Datenraten über SSH schaffen kann. Das RAID muss die Daten ja auch noch wegschreiben/lesen können, so das Du denke ich hier ne Gigabit-Netzwerkkarte nicht auslasten kannst.

[Cae]

iperf und/oder Billigloesungen wie

Code: Alles auswählen

hostb$ nc -l -p {port} | pv >/dev/null
hosta$ timeout 10 pv </dev/zero | nc {hostb} {port}

zeigen auf, dass es tatsaechlich am Netzwerk liegt?

FUSE (und damit sshfs) hat prinzipbedingt mehr Overhead durch Kontext-Switches. Und die Krypto ist bei niedlicher Hardware evtl. zu teuer.

Gruss Cae

[catdog2]

FUSE (und damit sshfs) hat prinzipbedingt mehr Overhead durch Kontext-Switches.

FUSE ist nicht das Problem.

Und die Krypto ist bei niedlicher Hardware evtl. zu teuer.

Die ist viel viel teurer als die paar context switches.

[wanne]

Die ist viel viel teurer als die paar context switches.

Das würde ich so nicht sagen. 100MiB Datei

Code: Alles auswählen

sshfs wanne@127.0.0.1:/tmp /tmp/testdir/
time cp testdir/testdat test2

real    0m3.926s
user    0m0.016s
sys     0m0.152s

Code: Alles auswählen

time cat /tmp/testdat | openssl enc -aes-128-cbc -k passwd | openssl enc -d -aes-128-cbc -k passwd> ./test2  
real    0m1.774s
user    0m1.352s
sys     0m0.376s

244MiB:

Code: Alles auswählen

$ dd if=/dev/urandom of=/tmp/testdat count=500000
$ time cat /tmp/testdat | openssl enc -aes-128-cbc -k passwd | openssl enc -d -aes-128-cbc -k passwd> ./test2
real    0m4.060s
user    0m2.996s
sys     0m1.112s

$ time cp testdir/testdat test2 

real    0m8.892s
user    0m0.012s
sys     0m0.376s

ssh scheint mehr als doppelt so lange für den übertragungsvorgang zu brauchen als openssl zum ver- und entschlüsseln. Kann daran liegen, dass die crypto in ssh sowieso nicht so genial umgesetzt ist. Aber auf jeden Fall ist das schon bemerkenswert.

[catdog2]

Seltsamer Benchmark. Wenn dann müsstest du ein fuse Dateisystem welches nur durchreicht gegen sshfs antreten lassen und dann schauen um wie viel sshfs langsamer ist. Außerdem musst du die CPU beachten, ich gehe hier da von NAS die Rede ist von einem eher schwachen Modell aus.

[Alternativende]

Die Auslastung der CPU liegt bei ca. 50% was darauf hindeuten könnte das ein Kern voll ausgelastet ist.

[wanne]

Seltsamer Benchmark. Wenn dann müsstest du ein fuse Dateisystem welches nur durchreicht gegen sshfs antreten lassen und dann schauen um wie viel sshfs langsamer ist.

Wenn ich wissen will ob jetzt fuse oder die ssh crypto langsam ist ja.
Wenn ich wissen will ob crypto schneller sein kann als ssh ist mein Benchmark absolut aussagekräftig.

[reox]

Probiers mal mit

Code: Alles auswählen

rsync -aHAXxv --numeric-ids --delete --progress -e "ssh -T -c arcfour -o Compression=no -x" user@<source>:<source_dir> <dest_dir>

(siehe https://gist.github.com/KartikTalwar/4393116)

bzw auch ganz unverschlüsselt

Code: Alles auswählen

client$ tar -c /path/to/data | nc -q 10 12345
server$ nc -w 10 -l -p 12345 | tar -x 

Ich komm mit ersten schon auf >100MB/s solange die platten mithalten. SSD -> SSD waren 110MB/s drin.

übrigens: hdparm sagt nicht viel darüber aus ob du tatsächlich mit der geschwindigkeit lesen/schreiben kannst. Es kommt mal sehr darauf an wie die daten da auf der platte liegen, ob du große oder kleine files bearbeitest und ob die files außen oder innen auf der platte liegen. das macht zT einen unterschied von 30MB/s aus...

[catdog2]

Code: Alles auswählen

ssh -T -c arcfour -o Compression=no -x

Den MAC nicht vergessen, der Algorithmus spielt da auch noch mal groß mit rein. umac-64@openssh.com sollte z.B. nochmal deutlich schneller sein.

Code: Alles auswählen

ssh -T -c arcfour -o Compression=no -x -o MACs=umac-64@openssh.com

Bei neueren sshs (jessie) wird arcfour nicht mehr unterstützt. Stattdessen könnte man chacha20-poly1305@openssh.com versuchen.

bzw auch ganz unverschlüsselt

Das ist für so einen generellen durchsatztest natürlich optimal.

[Alternativende]

Hat schon jemand Erfahrung mit dem neuen Kernel gemacht? 3.18 soll in dieser Richtung ja etwas bringen, oder wie schätzt ihr das ein?

[peschmae]

Würde ich nicht unbedigt davon ausgehen; wie siehts denn aus mit unverschlüsseltem Netzwerktraffic à la netcat? Was ist das überhaupt für ein NAS?

MfG Peschmä

[reox]

Hat schon jemand Erfahrung mit dem neuen Kernel gemacht? 3.18 soll in dieser Richtung ja etwas bringen, oder wie schätzt ihr das ein?

afaik trifft das nur für 10 und 40Gbit Karten von Intel zu...