Gelöst: Langsamer Datentransfer im lokalen Netz

[manes]

Hallo Forum,

im lokalen Netz sind mehrere Rechner, die ich per ssh erreichen kann. Einer davon, ein kleines NAS, transportiert die -durchaus großen- Datenmengen deutlich langsamer, als es mir recht ist. Darauf läuft ein

Code: Alles auswählen

uname -a
Linux n4 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

, die Festplatten haben ein ZFS, gespiegelt:

Code: Alles auswählen

mirror-0        ONLINE       0     0     0
dm-name-n4_2  ONLINE       0     0     0
dm-name-n4_3  ONLINE       0     0     0
mirror-1        ONLINE       0     0     0
dm-name-n4_0  ONLINE       0     0     0
dm-name-n4_1  ONLINE       0     0     0

Die Rechner sind alle per Gigabit-Ethernet verbunden, in der Fritzbox sind alle Ports auf Gigabit gestellt, die Netzwerkkarte des langsamen Rechners ist auf dem Mainboard integriert, es ist ein ASRock C70M1 mit einem Realtek-Chip.

Code: Alles auswählen

lspci -nn |grep Ether
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 06)

Die unfreie Firmware ist geladen:

Code: Alles auswählen

lsmod|grep r8169
r8169                  68262  0 
mii                    12675  1 r8169

Code: Alles auswählen

 ethtool eth0                       
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Half 1000baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Full 
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
                               drv probe ifdown ifup
        Link detected: yes

Während ein anderer Rechner klaglos 120MB/s liefert, dümpelt das NAS bei 18-19MB/s herum.
Hat jemand bitte einen Hinweis für mich, woher die schlechte Performance rührt und wie ich das verbessern kann?
Merci im Vorabbereich!

edit: Die Platten sind per SATA-III angebunden, das ist auch kein Flaschenhals…

[MSfree]

Wie hoch ist deine CPU-Last auf dem NAS beim Datentransfer?

Was sagt

Code: Alles auswählen

cat /proc/meminfo

[manes]

Wie hoch ist deine CPU-Last auf dem NAS beim Datentransfer?
Was sagt

Code: Alles auswählen

cat /proc/meminfo

Ich finde, das sieht soweit regelrecht und nicht ausgelastet aus:

Code: Alles auswählen

top:
Tasks: 520 total,   4 running, 516 sleeping,   0 stopped,   0 zombie
%Cpu(s): 28,1 us, 65,5 sy,  0,0 ni,  0,0 id,  1,1 wa,  0,0 hi,  5,2 si,  0,0 st
KiB Mem:   3782112 total,  2452632 used,  1329480 free,    50488 buffers
KiB Swap:   224252 total,        0 used,   224252 free.   184092 cached Mem

Code: Alles auswählen

 cat /proc/meminfo
MemTotal:        3782112 kB
MemFree:         1318040 kB
MemAvailable:    1397124 kB
Buffers:           50492 kB
Cached:           184092 kB
SwapCached:            0 kB
Active:           176804 kB
Inactive:          79960 kB
Active(anon):      22428 kB
Inactive(anon):     8524 kB
Active(file):     154376 kB
Inactive(file):    71436 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:        224252 kB
SwapFree:         224252 kB
Dirty:                 0 kB
Writeback:             0 kB
AnonPages:         22172 kB
Mapped:            16116 kB
Shmem:              8780 kB
Slab:             158340 kB
SReclaimable:      44416 kB
SUnreclaim:       113924 kB
KernelStack:        8368 kB
PageTables:         2444 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     2115308 kB
Committed_AS:      68684 kB
VmallocTotal:   34359738367 kB
VmallocUsed:     2300576 kB
VmallocChunk:   34357357484 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       59020 kB
DirectMap2M:     2805760 kB
DirectMap1G:     1048576 kB

[rendegast]

Die unfreie Firmware ist geladen:
lsmod|grep r8169
r8169 68262 0
mii 12675 1 r8169

Daran ist nur zu sehen, daß das Kernelmodul (Gerätetreiber) geladen ist.
Wegen der firmware braucht es Auszug dmesg.

Ich finde, das sieht soweit regelrecht und nicht ausgelastet aus:
top:
...
%Cpu(s): 28,1 us, 65,5 sy, 0,0 ni, 0,0 id, 1,1 wa, 0,0 hi, 5,2 si, 0,0 st

Addiert sich zu 100% CPU,
resp. "0,0 id" = nix am herumidlen.

[MSfree]

Addiert sich zu 100% CPU

Und damit sollte klar sein, das der 1GHz AMD Dualcore wohl ziemlich am Limit ist.

[manes]

Nur der Vollständigkeit halber:

Code: Alles auswählen

 dmesg|grep 8169
[    1.688169] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
[    2.043910] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[    2.043944] r8169 0000:04:00.0: can't disable ASPM; OS doesn't have ASPM control
[    2.044312] r8169 0000:04:00.0: irq 40 for MSI/MSI-X
[    2.045434] r8169 0000:04:00.0 eth0: RTL8168evl/8111evl at 0xffffc90000674000, d0:50:99:ad:32:f6, XID 0c900800 IRQ 40
[    2.045446] r8169 0000:04:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[   13.984192] r8169 0000:04:00.0: firmware: direct-loading firmware rtl_nic/rtl8168e-3.fw
[   14.102488] r8169 0000:04:00.0 eth0: link down
[   14.103824] r8169 0000:04:00.0 eth0: link down
[   16.252182] r8169 0000:04:00.0 eth0: link up

Und äh ja, die CPU-Last hätte ich doch allein addieren können sollen. Offenbar hab ich beim Mainboard am falschen Ende gespart.
solved. Und Danke den Beteiligten.

[MSfree]

Offenbar hab ich beim Mainboard am falschen Ende gespart.

Oder das falsche Dateisystem im Einsatz. ZFS ist jetzt nicht gerade dafür bekannt, besonders sparsam mit RAM und CPU-Last umzugehen.

[manes]

Offenbar hab ich beim Mainboard am falschen Ende gespart.

Oder das falsche Dateisystem im Einsatz. ZFS ist jetzt nicht gerade dafür bekannt, besonders sparsam mit RAM und CPU-Last umzugehen.

Das wußte ich aber schon beim Kauf des Mainboards, insofern kann ich das Problem nicht dem Dateisystem anlasten.
Beim nächsten Mal mache ich dann eben neue Fehler .

[MSfree]

Das wußte ich aber schon beim Kauf des Mainboards, insofern kann ich das Problem nicht dem Dateisystem anlasten.

Naja, mit ext4 wäre sehr viel mehr als nur 18MB/s auf der Hardware drin.

Für ZFS habe ich letztens eine Empfehlung gelesen, die sinngemäße 1-4 Workstation Multicore CPUs veranschlagen. Das liefe auf mindestens einen 4-Kern Core-i7 bis hin zu vier 18-Kern Xeons hinaus, plus 1GB pro Terabyte Plattenplatz. Mit einem Lowest-End-Prozessor würde ich mich gar nicht trauen, an ZFS zu denken.

[reox]

Für ZFS habe ich letztens eine Empfehlung gelesen, die sinngemäße 1-4 Workstation Multicore CPUs veranschlagen. Das liefe auf mindestens einen 4-Kern Core-i7 bis hin zu vier 18-Kern Xeons hinaus

Ist zwar OT aber: Pro Workstation die lesen/schreiben will braucht es 1-4 CPUs? oder wie ist das zu verstehen?
Die 1GB RAM pro TB hab ich schon öfters gehört wobei das auch ECC sein sollte...