[SOLVED ]Halbe CIFS read performance zu write performance, Raidz2

[peacepipe]

Hallo Community,

ich bin gerade an der Feinarbeit meiner FreeNAS-Konfiguration.

Hier die interessanten Specs:

CPU:

Code:

Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz
RAM: 18393MB
HDD: 8x8TB WD80EFZX
SSD: 80GB (L2ARC)

ZFS-Konfig:

Code:

raidz6
recordsize 1M
compression lz4
atime off
dedup off

Samba write:

Code:

115 MegaByte/sec

Samba read:

Code:

65 MegaByte/sec

Samba habe ich schon mit folgenden Parametern tunen wollen:

Code:

socket options = TCP_NODELAY
SO_KEEPALIVE
SO_SNDBU
SO_RCVBUF
IPTOS_LOWDELAY

Hat auch nichts gebracht.


Erklären kann ich mir die halbe Leseleistung im Vergleich zur Schreibleistung nicht, weshalb ich auch hier nachfrage, woran es liegt.

 

[MrToddsFriends]

Die angegebenen Transferraten wurden mit Gigabit Netzwerk ermittelt, korrekt? L2ARC dürfte eine Bremse darstellen, laut ZFS Primer bringt das unter 32 GByte RAM Nachteile. Hier im Forum wird zumeist empfohlen, einen L2ARC erst mit mindestens 64 GByte RAM zu verwenden.

 

[peacepipe]

Danke für die schnelle Antwort. Ja die Transferraten wurden ein Gigabit-Netz gemessen. Wieso stellt denn ausgerechnet der L2ARC bei der Readperformance eine Bremse dar? Generell hätte ich genau das Gegenteil erwartet (SSD-Perf > HDD-Perf).

 

[MrToddsFriends]

Zitat aus dem oben verlinkten ZFS Primer: "If there is not enough RAM for a adequately-sized ARC, adding an L2ARC will not increase performance. Performance actually decreases in most cases, potentially causing system instability."

Probier's einfach mal ohne. Andere direkte Hinweise auf Perfomancehindernisse habe ich Deinen Angaben zur Hardware nicht entnehmen können.

 

[peacepipe]

Achso, ich habe es außerdem verschlüsselt, AES-NI ist aber vorhanden. Könnte es daran noch liegen? Ich bin soeben dabei es ohne L2ARC zu testen. Edit folgt...

EDIT: Hat kein MB/s mehr gebracht.

 

[MrToddsFriends]

Hmm, ein Xeon E3 sollte mit jeder auch nur halbwegs vernünftigen ZFS Plattenkonfiguration (damit RaidZ2 natürlich eingeschlossen) eine Gigabit-Netzwerkverbindung sättigen können.

Mit der ZFS recordsize habe ich bis jetzt allerdings noch nie gespielt. Es gab für mich auch keinen Grund dazu, den Default-Wert von 128k zu ändern. Die Verschlüsselung an Gigabit sollte ein Xeon E3 handeln können (verwende ich selbst nicht) und die lz4 Kompression sowieso.

Ist eine für FreeNAS/FreeBSD ungewöhnliche (nicht-Intel) Netzwerkhardware im Spiel?
Wie genau testest Du?

 

[peacepipe]

Ich vermute aktuell, dass es an der "tollen" Realtec NIC vom Client liegt.

Code:

07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)

Ich teste es soeben von einem Server mit einer Intel NIC ob es besser aussieht (CIFS via Debian <-> FreeNAS)

Mein Desktop-PC mit Realtek hatte ich auf Windows 10 pro x64 nach FreeNAS getestet.

 

[Ericloewe]

Ich vermute aktuell, dass es an der "tollen" Realtec NIC vom Client liegt.

Unter Windows funktionieren Realtek NICs schon hablwegs problemlos. Meistens.

Wieso stellt denn ausgerechnet der L2ARC bei der Readperformance eine Bremse dar?

Die L2ARC braucht Metadata in RAM, damit ZFS sich die Daten holen kann. Also gibt es weniger L1ARC. Deswegen ist L2ARC nicht immer besser.

 

[peacepipe]

Hallo,

es hat wohl den Anschein, dass es sich eher um tiefere OSI-Schichten handelt und nicht auf der Applikationsebene:

FreeNAS, lagg0, LACP

Code:

iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 64.0 KByte (default)
------------------------------------------------------------
[  4] local 192.168.77.123 port 5001 connected with 192.168.77.78 port 44943
[ ID] Interval	   Transfer	 Bandwidth
[  4]  0.0-10.0 sec  1.09 GBytes   938 Mbits/sec

iperf -c 192.168.77.78 -B 192.168.77.123
------------------------------------------------------------
Client connecting to 192.168.77.78, TCP port 5001
Binding to local address 192.168.77.123
TCP window size: 32.8 KByte (default)
------------------------------------------------------------
[  3] local 192.168.77.123 port 56282 connected with 192.168.77.78 port 5001
[ ID] Interval	   Transfer	 Bandwidth
[  3]  0.0-10.0 sec   577 MBytes   484 Mbits/sec

Linux-System mit bond0, LACP:

Code:

sudo iperf -c 192.168.77.123
------------------------------------------------------------
Client connecting to 192.168.77.123, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.77.78 port 44943 connected with 192.168.77.123 port 5001
[ ID] Interval	   Transfer	 Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec

sudo iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.77.78 port 5001 connected with 192.168.77.123 port 56282
[ ID] Interval	   Transfer	 Bandwidth
[  4]  0.0-10.0 sec   577 MBytes   483 Mbits/sec

 

[MrToddsFriends]

FreeNAS, lagg0, LACP

In's Blaue hinein: Probier' mal ohne Link Aggregation.

 

[peacepipe]

Dachte ich auch und das hat mich viel Zeit gekostet, festzustellen, dass es daran nicht lag.

Das Problem war, dass ich mein Management-Interface und Daten-Interface (LACP) im gleichen Subnetz hatte. Das wurde von mir über die CLI erzwungen, weil es über die GUI nicht ging. Ganz begreifen kann ich den Geschwindigkeitsverlust trotz allem nicht.