Was stimmt nicht mit den langsamen Netzwerkfreigaben meines schnellen Netzwerks?

Ich habe extrem viel getestet. cp, dd, rysnc, iperf, netcat, custom-dd und wahrscheinlich mehr.

Was ich sehe, ist ein starkes Netzwerk. Die iperf-Ergebnisse unten zeigen das, und ich habe andere Daten, um es auch zu validieren.

Was ich suche, ist ein Freigabeprotokoll, das diesen Geschwindigkeiten entspricht oder ihnen sogar nahe kommt.

Was ich derzeit mit den Sharing-Protokollen iSCSI (FreeNAS) und CIFS (WIN7) bekomme, sind ca. 1,5 GB / m bis 2,5 GB / m. Mein Ziel ist 3,0 GB / m

Was könnte ich an meiner Implementierung des Freigabeprotokolls vermasseln, das die Geschwindigkeit so drastisch reduziert?

root@fdas:~# ./iperf -c 192.168.2.138
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 43066 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.05 GBytes   900 Mbits/sec
root@fdas:~# ./iperf -c 192.168.2.138 -t 60
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 43067 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.22 GBytes   891 Mbits/sec
root@fdas:~# ./iperf -c 192.168.2.138 -t 600
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 35506 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-600.0 sec  62.0 GBytes   887 Mbits/sec

//bearbeiten Disk io Benchmarks hinzugefügt. ANMERKUNG: Dieser hdparm-Test wird in sequentieller Reihenfolge gelesen. Das ultimative Ziel hier ist das Lesen und Schreiben von unformatierten Bytes von einer Festplatte (gesamte Festplatte, keine Partition).

/dev/sdd1 on /a type ext4 (rw)

ANMERKUNG: sdd ist eine FreeNAS iSCSI-Festplatte

root@fdas:~# hdparm -t /dev/sdd

/dev/sdd:
 Timing buffered disk reads:  168 MB in  3.02 seconds =  55.71 MB/sec
root@fdas:~# hdparm -t -T /dev/sdd

/dev/sdd:
 Timing cached reads:   5240 MB in  2.00 seconds = 2620.70 MB/sec
 Timing buffered disk reads:  168 MB in  3.01 seconds =  55.84 MB/sec

Haben Sie Disk IO-Benchmarks sowohl auf dem Server als auch auf dem Client ausgeführt? Sofern die Festplattensubsysteme nicht in der Lage sind, den gewünschten Durchsatz zu erzielen, sind sie natürlich eher der Engpass als das Netzwerk.

Nach meiner Erfahrung ist iSCSI der niedrigste Overhead, und Jumbo-Frames werden am Ende gezählt. Ich habe gesehen, wie iSCSI eine GigE-Verbindung mit dem LIO-Target-iSCSI-Framework und einer Ramdisk als Ziel gesättigt hat. Das Ding ist geflogen. Die ältere Version des Linux-iSCSI-Stacks hatte einige Leistungsprobleme und konnte keine RAM-Disk für den Durchsatz mit vollem Durchsatz verwenden. Ich bin nicht sicher, was FreeNAS in diesen Tagen ausführt, das LIO-Target-Zeug ist ziemlich neu.

Einer der größten Beschränkungen für einen solchen Durchsatz ist das Speichersystem-Backend. Wie bereits erwähnt, wurde die oben genannte Geschwindigkeit durch die Verwendung einer RAM-Disk erreicht (der Server verfügte über 32 GB RAM, daher war es einen Versuch wert). Als ich denselben Test mit Speicherstreifen auf 48 Festplatten ausprobierte, war ich in der Lage, GigE während der sequenziellen Tests zu überlasten, aber die zufälligen E / A-Tests lagen weit darunter. im Bereich von 65-80MB / s, wie ich mich erinnere.