Netzwerkgeschwindigkeit unter Linux NAS unterdurchschnittlich, Debugging (es sind nicht die Kabel)
554
greenone83
Bevor ich dies poste, habe ich viele Threads / Seiten / Blogs über Netzwerkgeschwindigkeiten gelesen, die unter den Spezifikationen liegen. Also kaufte ich neue CAT6 UTP-Kabel und testete zwischen jedem Gerät in meinem Netzwerk.
Ich bekomme jetzt einheitliche Geschwindigkeiten von etwa 110 MBit / s zwischen allen Geräten außer meinem selbst gebauten Linux-NAS. Dateien werden nur bei 40 MB / s konsistent kopiert. Ich habe dies mit kurzen Kabeln, langen Kabeln, einem dedizierten 1-Gbit-Switch (anstelle des Routing durch meinen Gigabit-Router) getestet, immer dasselbe Ergebnis. Ich habe das Kopieren über das Netzwerk von SSD zu SSD getestet, SSD zu HDD, kein Unterschied (NAS hat sowohl SSD als auch HDD). Ich habe versucht SFTP, SMB, FTP, machte auch keinen Unterschied. Bei allen Tests blieb die Belastung des NAS sehr gering.
Mittlerweile ist mein Verdacht die NAS-Hardware- und / oder Linux-Treiber, Konfiguration. Wie kann ich das debuggen?
[aktualisieren]
1 Kern ist während des Dateikopierens über das Netzwerk maximal. Die Ladung schien mit 0,6 in Munin klein zu sein, aber das ist nur der Durchschnitt über 5 Minuten. CPU ist also der Engpass?
[Update 2]
In meinem Fall hat der Treiber ein bisschen geholfen, aber am Ende ist mein Engpass die Kombination aus Protokoll + CPU. Nur HTTP schafft es, die Verbindung zu maximieren, wohingegen SFTP und SMB durch die CPU begrenzt sind. Möglicherweise kann durch ein paar Änderungen die CPU-Nutzung für beide reduziert werden.
Die Specs:
OS: Debian 8 Board: ASRock N3150B-ITX Intel N3150 mITX CPU: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz RAM: 8 GB HDD: 2 x WD Red WD40EFRX 4TB SSD: 1 x Kingston SSDNow V300 120GB MLC
Detaillierte Spezifikationen
lscpu
Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 76 Model name: Intel(R) Celeron(R) CPU N3150 @ 1.60GHz Stepping: 3 CPU MHz: 481.933 CPU max MHz: 2080,0000 CPU min MHz: 480,0000 BogoMIPS: 3202.01 Virtualization: VT-x L1d cache: 24K L1i cache: 32K L2 cache: 1024K NUMA node0 CPU(s): 0-3
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether d0:50:99:78:03:d2 brd ff:ff:ff:ff:ff:ff inet 192.168.0.100/24 brd 192.168.0.255 scope global eth0 valid_lft forever preferred_lft forever 5: lxc: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 52:54:00:c6:f0:23 brd ff:ff:ff:ff:ff:ff inet 10.11.0.1/24 brd 10.11.0.255 scope global lxc valid_lft forever preferred_lft forever 6: lxc-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master lxc state DOWN group default qlen 1000 link/ether 52:54:00:c6:f0:23 brd ff:ff:ff:ff:ff:ff 12: veth6FWFI5@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxc state UP group default qlen 1000 link/ether fe:26:a4:3e:ec:22 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc26:a4ff:fe3e:ec22/64 scope link valid_lft forever preferred_lft forever 16: veth4IKF6U@if15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxc state UP group default qlen 1000 link/ether fe:a4:7f:d9:88:e8 brd ff:ff:ff:ff:ff:ff inet6 fe80::fca4:7fff:fed9:88e8/64 scope link valid_lft forever preferred_lft forever 38: vethBC83V0@if37: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master lxc state UP group default qlen 1000 link/ether fe:72:5a:77:15:f2 brd ff:ff:ff:ff:ff:ff inet6 fe80::fc72:5aff:fe77:15f2/64 scope link valid_lft forever preferred_lft forever
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/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 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
iptables
iptables -L -n -v --line-numbers Chain INPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 1280K 89M fail2ban-ssh tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 22 2 0 0 ACCEPT udp -- lxc * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 3 0 0 ACCEPT tcp -- lxc * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 4 0 0 ACCEPT udp -- lxc * 0.0.0.0/0 0.0.0.0/0 udp dpt:67 5 0 0 ACCEPT tcp -- lxc * 0.0.0.0/0 0.0.0.0/0 tcp dpt:67 6 615K 107M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 7 0 0 REJECT all -- !lo * 0.0.0.0/0 127.0.0.0/8 reject-with icmp-port-unreachable 8 7065K 1431M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 9 40 2560 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.100 state NEW tcp dpt:22 10 27 1724 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.100 state NEW tcp dpt:80 11 15377 923K ACCEPT tcp -- * * 10.11.0.10 10.11.0.1 state NEW tcp dpt:4949 12 340K 65M ACCEPT udp -- * * 192.168.0.0/24 0.0.0.0/0 state NEW udp dpt:5353 13 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.100 state NEW tcp dpt:3689 14 0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.0.100 state NEW tcp dpt:6600 15 5 412 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 16 309K 77M LOG all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 5/min burst 5 LOG flags 0 level 7 prefix "iptables denied: " 17 441K 97M DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 429 38624 ACCEPT tcp -- * * 0.0.0.0/0 10.11.0.20 state NEW tcp dpt:445 2 7 444 ACCEPT tcp -- * * 0.0.0.0/0 10.11.0.20 state NEW tcp dpt:139 3 0 0 ACCEPT udp -- * * 0.0.0.0/0 10.11.0.20 state NEW udp dpt:138 4 2 156 ACCEPT udp -- * * 0.0.0.0/0 10.11.0.20 state NEW udp dpt:137 5 243M 228G ACCEPT all -- * lxc 0.0.0.0/0 10.11.0.0/24 ctstate RELATED,ESTABLISHED 6 84M 341G ACCEPT all -- lxc * 10.11.0.0/24 0.0.0.0/0 7 0 0 ACCEPT all -- lxc lxc 0.0.0.0/0 0.0.0.0/0 8 0 0 REJECT all -- * lxc 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 9 0 0 REJECT all -- lxc * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 10 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 ACCEPT udp -- * lxc 0.0.0.0/0 0.0.0.0/0 udp dpt:68 2 12M 9842M ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 Chain fail2ban-ssh (1 references) num pkts bytes target prot opt in out source destination 1 1280K 89M RETURN all -- * * 0.0.0.0/0 0.0.0.0/0
und "ethtool eth0"?
13dimitar vor 7 Jahren
0
fügte nur hinzu
greenone83 vor 7 Jahren
0
Welches Protokoll verwenden Sie? FTP? HTTP? SMB? NFS? Wie sieht die CPU-Auslastung während einer Kopie aus?
David Schwartz vor 7 Jahren
0
Wie ich schrieb, habe ich mit SFTP, SMB und FTP getestet
greenone83 vor 7 Jahren
0
So stellt sich heraus, dass einer der vier Kerne beim Kopieren von Dateien maximal ausfällt (105%). Ich denke, die CPU ist der Engpass? Gibt es etwas, was man dagegen tun kann? Wofür wird die CPU überhaupt verwendet? Umgang mit der NIC? Schreiben / Lesen von der Festplatte?
greenone83 vor 7 Jahren
0
Das ist die nächste Frage. Es kann sich um die Dateiserversoftware, den NIC-Treiber, den Festplattentreiber, das Dateisystem usw. handeln. Möglicherweise überhitzt die CPU.
David Schwartz vor 7 Jahren
0
Eigentlich denke ich, dass deine CPU einfach nur scheiße ist. PassMark gibt es eine Single-Thread-Bewertung von 471. Im Gegensatz dazu hat ein i3-4150 (der $ 100 kostet) eine Single-Thread-Bewertung von 2.022. Sie haben also weniger als 1/4 der Single-Thread-Leistung einer CPU der untersten Zeile. SFTP benötigt CPU-Leistung zum Ver- / Entschlüsseln. (Stellen Sie sicher, dass es nicht überhitzt. Das macht es noch schlimmer.)
David Schwartz vor 7 Jahren
0
Ja, ich entschied mich für etwas mit superlow TDP, das passiv gekühlt werden konnte und nicht viel Energie benötigte. Ich denke, ich bin zu weit gegangen
greenone83 vor 7 Jahren
0
1 Antwort auf die Frage
3
LSerni
aktualisieren
Es scheint, dass meine Hypothese unten einen Vorzug hatte: Hier finden Sie eine aktuelle Anleitung, wie Sie das Verhalten der 8168 korrigieren können, indem Sie die entsprechenden Treiber installieren und wie sie nach einem Kernel-Upgrade / -Startakt hängen bleiben.
Protokolle
Die Verwendung eines Protokolls wie SFTP beinhaltet das Hinzufügen von Verschlüsselung und Komprimierung. Das Komprimieren einer Datei bedeutet, dass Sie die CPU erreicht haben, aber die Netzwerkbandbreite erhöhen. Was bei einer langsamen CPU selbst von der CPU-Last beeinflusst wird. Sie müssen also ein Gleichgewicht zwischen den beiden finden.
Außerdem unterscheidet sich die Netzwerkkonfiguration für Verbindungen mit kurzer Latenz und großer Bandbreite von der umgekehrten. Linux hat Auto-Tuning, aber Ihre Situation kann immer noch außerhalb ihrer Grenzen liegen. Hier finden Sie weitere Informationen (und wo Sie optimieren). Ich erinnere mich, dass ich ein Skript gesehen habe, das behauptete, eine automatische Anpassung durch Übertragen einer großen Datei zwischen zwei Hosts (einen im Servermodus, einer im Clientmodus) durchzuführen, aber dafür benötigen Sie zwei Linux-Hosts. Außerdem sind die besten Einstellungen für das Gespräch mit einem Linux-SFTP-Host möglicherweise sehr schlecht für eine Samba-Verbindung mit Windows 7 und so weiter.
Aller Wahrscheinlichkeit nach müssen Sie einen Kompromiss zwischen den verschiedenen Bedürfnissen finden.
Sie verwenden wahrscheinlich einen unterdurchschnittlichen Treiber, der die Realtek-Funktionen (z. B. das Entladen von Prüfsummen) nicht nutzt, was zu übermäßiger CPU-Belastung führt.
Hier finden Sie Anweisungen, wie Sie den r8168-Treiber in:
Sie können ein dkms-Paket mit dem r8168-Treiber aus offiziellen Ubuntu-Repositorys installieren.
Sie müssen den manuell installierten Treiber deinstallieren und anschließend im Terminal ausführen:
sudo apt-get install r8168-dkms
Das dkms-Paket erstellt das Kernel-Modul (Treiber) bei jedem Upgrade eines Kernels neu.
Das Repository für Ubuntu 14.04 enthält eine Version 8.037.00-1 von dkms r8168.
Es kann gut funktionieren. Wenn Sie wirklich den neuesten Treiber benötigen, können Sie ihn folgendermaßen installieren:
Dadurch wird dieselbe Version installiert, die Sie jetzt verwenden, jedoch mit Unterstützung von dkms.
Möglicherweise aktivieren Sie auch die Unterstützung für Large Frame (Sie haben jetzt die Standard-MTU von 1500). Bei großen Dateiübertragungen kann eine MTU von bis zu 9000 zu besseren Ergebnissen führen, vorausgesetzt, der Fahrer und alle Beteiligten unterstützen dies ebenfalls .
Ich habe non-free und contrib hinzugefügt und ein dist-upgrade durchgeführt und das Paket "firmware-realtek" wurde aktualisiert.
greenone83 vor 7 Jahren
0
ethtool -i eth0 zeigt jetzt: Treiber: r8169 Version: 2.3LK-NAPI Firmware-Version: rtl8168g-2_0.0.1 02/06/13 bus-info: 0000: 02: 00.0 Unterstützungsstatistik: ja Unterstützungs-Test: Keine Unterstützung -eeprom-access: nein unterstützt-register-dump: ja unterstützt-priv-flags: nein, nicht sicher, ob dies der neue Treiber ist, über HTTP bekomme ich jetzt 105 MB / s, aber SMB und SFTP bleiben bei ~ 40 MB / s so jetzt bin ich mit protokollspezifischen Problemen?
greenone83 vor 7 Jahren
0
hm laut diesem Thread: http://forums.debian.net/viewtopic.php?f=5&t=85431 dass nicht das Kernel-Modul eins ist, ich versuche es weiter
greenone83 vor 7 Jahren
0
Nein, Sie benötigen anscheinend den Treiber r8168. Überprüfen Sie auch die CPU-Last, wenn Sie große Dateien beispielsweise mit FTP übertragen. SFTP ist eine weitere Dose von Würmern, da es * Verschlüsselung * hinzufügt, was für CPUs schwierig ist.
LSerni vor 7 Jahren
0
so dass ich den r8168 installiert habe, aber die geschwindigkeiten nur geringfügig verbessert wurden, von sftp bekomme ich jetzt ~ 60mb / s (vor rund 40) die cpu noch maxes auf ssh und smb, ich denke, ich kann versuchen, die leistung für beide durch Tweaking zu verbessern die configs dort, also hat der Treiber ein wenig geholfen, aber mein Flaschenhals ist CPU und / oder Protoctol
greenone83 vor 7 Jahren
0