Geschwindigkeit, Rsync, FTP-Download und die Auswirkungen...

[rumknapser]

Hi,

ich habe eine (hoffentlich) allgemeingültige Frage zu einem Zustand:

Im Moment rsync'e ich von einem anderen NAS 8 TB Daten über das Netz (1GBit Switch, allerdings Low Budget DLink Green) auf die Synology. Dies über die Konsole per rsync command.
Es sind 4 Screens auf, auf denen 4 einzelne rsync Prozesse laufen, weil wenn ich nur einen laufen lassen würde, würde das ganze noch viel viel länger dauern. Es macht den Anschein, das ich die 4 Prozesse locker nebeneinander laufen lassen kann, ohne das ich z.B. durch Ruckeln bei Filmchen gucken oder Aussetzern beim Musik hören via SMB beeinträchtigt werde.

Nun gibt es aber noch einige User die Daten von der Synology per FTP holen müssen. Immer mal wieder große Projektdateien zw. 500MB-2GB.
Da mir der Sync wichtiger ist, habe ich den FTP-Download auf 50, bzw. 100KB/s eingeschränkt, was mir aber auch etwas wie Schikane vorkommt. als das es wirklich eine geschwindigkeitstechnische Auswirkung haben könnte.

Hier bin ich mir nicht sicher.

Der Ressourcenmonitor der DS zeigt leider keine einzelnen Prozesse, die gerade auf die Platte schreibend/lesend zugreifen, so das ich mir ein Bild machen könnte...

Meint Ihr, es hilft der rsync Geschwindigkeit, wenn ich FTP beschränke?

Ich habe schon alle (die meisten) Multimedia Dienste (Plex, iTunes, Audio, Video, etc.) ausgeschaltet, damit die nicht im Hintergrund indizieren oder ähnliches.

Der rsync läuft seit ca. 4 Tagen und es sind gerade mal 4 TB übertragen oder so...

 

[itari]

probiere doch einmal, eine Netzwerkleitung direkt zwischen DS und anderer NAS zu stecken (und ja, jetzt im laufenden Betrieb) und schau, ob die Performance besser wird ... wenn ja, liegt es am Switch

hast Jumbo-Frames definiert (oder geht das mit dem Switch und der anderen NAS nicht) ???

Itari

 

[rumknapser]

Danke itari, das Umstöpseln werde ich versuchen, wenn ich wieder am Standort bin.

Remote kann ich gerade nur gucken, ob JumboFrames auf der DS aktiviert sind, was sie NICHT sind:

LAN1:
Jumbo Frame deaktivieren, der MTU-Wert ist 1500
1000, Full Duplex, MTU 1500
LAN2: getrennt

Meine Kenntnisse bzgl. Netzwerkgeräte direkt verkuppeln basieren noch auf dem Hinterund, dass man früher eine CrossOverKabel (oder so) brauchte, wenn man keinen Switch/HUB dazwischen hat. Das ist heutzutage wohl nicht mehr nötig? Das andere NAS ist ein QNAP TS-459 Pro II, dessen Jumbo-Einstellungen folgendermaßen aussehen:




Es scheint, das die beiden also nicht gleichwertig eingestellt sind.
Ich muss mich aber erst nochmal einlesen, was diese Jumbo-Frames bewirken und was es evtl. für Nachteile gibt. Danke f.d. Hinweis!

 

[itari]

bei GBit-Netzen ist cross-Kabel nicht mehr notwendig, wird automatisch richtig gedreht im Adapter

beide können '9000' ... zur Zeit sind beide auf '1500' ... wichtig ist halt, dass beide Geräte ihre Netzwerkeinstellungen irgendwo her bekommen (entweder fest oder halt bevor man umstöpselt von dem DHCP-Server ... deswegen live stöpseln, dann haben sie ja die Konfiguration)

Nachteile haben die Jumboframes keine ... außer, dass es vielleicht nicht funktioniert ... aber das wäre halt zu testen

Itari

 

[rumknapser]

bei GBit-Netzen ist cross-Kabel nicht mehr notwendig, wird automatisch richtig gedreht im Adapter

Jut zu wissen, ddanke f.d. Info.

beide können '9000'

Hast Du auch schonmal Fälle gehabt, bei denen eine Identische maximale Einstellung für Probleme gesorgt hat? Und welche könnten das sein?
Sporadisch auftretende korrupte Datenpakete würde ich als äußerst unschön erachten!
Wenn Du schreibst "nicht funktioniert", was bedeutet das in der Auswirkung?
Wäre das komplette Netzwerk betroffen, oder nur die beiden Geräte? Findet dann überhaupt kein Datenverkehr mehr statt oder nur ein "seltsamer"?
...Stimmt schon, selber ausprobieren geht hier über studieren Aber lieber vorher aus dem Leid der Anderen versuchen zu lernen

live stöpseln, dann haben sie ja die Konfiguration

Ah, jetzt habe ich den Zusammenhang verstanden. Beide Geräte haben ihre IP-Adressen per DHCP über HW-MAC fixiert und booten hatte ich eh nicht vor, also wird es dann wohl funktionieren. Nochmal Danke.


EDIT:
Nachtrag, beim Durchlesen dieses Artikels:
Hinweis / Erklärung zu Jumbo Frames hab ich diesen hilfreichen Link enttarnt:

wie finde ich heraus, was mein Switch kann?

Dort steht bei meinem Tisch-Switch, dass er keine Jumobframes kann, somit hat sich das Thema JumboFrames hier also erstmal erledigt, ich teste also das direkte Zusammenspiel der beiden NAS später und berichte hoffentlich über Performancezuwachs.

 

[Matthieu]

Wie sieht es denn mit der Prozessorauslastung aus? rsync ist ja eigentlich eher dafür bekannt, dem Prozessor ordentlich Dampf zu machen. An Platten oder Netzwerk scheitert es selten. In dem Fall wäre Besserung nur möglich, indem gezielt einige der "Sicherheitsmechanismen" von rsync abgeschaltet würden.
Bei Jumboframes kenne ich es so, dass die Geräte sich entweder gar nicht mehr finden oder es einfach läuft. Jumboframes erhöhen die maximale Paketgröße für Netzwerkpakete, um den Overhead zu verringern. Alle Geräte die mit diesen Größen nicht klar kommen, können dann außen vor sein. Daher ist es empfehlenswert, Jumboframes auf eine Direktverbindung zu beschränken oder das gesamte Netzwerk auf einmal zu migrieren (wobei dann auch Switches, Router und co damit klar kommen müssen!).

MfG Matthieu

 

[rumknapser]

Danke Matthieu,
die Prozessorauslastung ist schon gewaltig, wie ich finde:


Ich werde es später, wie Du und itari vorschlagen, mit einer direkten Kabelverbindung der beiden NAS versuchen und die Jumboframes mal hochsetzen.
Lange kann ich das natürlich nicht laufen lassen, denn in der Zeit wird sich niemand mit dem NAS verbinden können, was ja -wie ich oben schrieb- via FTP nötig ist.

Es gibt zwar in beiden Geräten 2 Netzwerkkarten, aber soweit ich durch Versuche vor einiger Zeit getestet habe, kann man auf der Konsole nicht bestimmen, welches Programm über welches Netzwerkinterface senden/empfangen soll, so das ich theoretisch einfach den rsync auf NIC1 laufen lassen könnte und das interne Netzwerk über NIC2.

 

[Matthieu]

Da die 412+ einen Dual-Core hat, scheint rsync einen der Kerne auszulasten. Die Frage ist, wie bekommt man die verschiedenen rsync-Prozesse auf verschiedene Kerne verteilt. Hängt das am sshd? Ich hab dahingehend leider keinerlei Erfahrung ...

MfG Matthieu

 

[rumknapser]

wie bekommt man die verschiedenen rsync-Prozesse auf verschiedene Kerne verteilt. Hängt das am sshd? Ich hab dahingehend leider keinerlei Erfahrung ...

Ich auch nicht, und ich glaube auch nicht, das dies im Jahre 2013 mit 2 Befehlen getan werden kann. Hatte die Problematik schon mal vor ca. einigen Jahren, aber die Recherche und das Herumprobieren hat länger gedauert als es einfach so laufen zu lassen. Mit mehr als einer NIC im Rechner war es ein ähnliches rumgefrickel. Alles noch nicht -für den unbedarften Endwandender und faulen Admin- ausgereift ;->

Aber zurück zum Thema,
ich sizte nun vor der DS und stelle mir praktisch die Frage, wie ich diese überhaupt direkt verkabeln soll, so das ich auch noch auf die DS komme um z.B. im RessourcenMonitor zu prüfen, wie und ob sich die Geschwindigkeit verändert.

Ich habe also meinem PC, der DS und dem QNAP-NAS drei statische IP-Adressen im selben Netz vergeben. Die WindowsFireWall ist ausgeschaltet.

Sind allesamt über den Switch verbunden, können sie sich sehen (via Ping).

Nehme ich den Switch aus dem Verbund heraus, und stecke die DS direkt in meinem PC, kann sehen sie sich auch.

Stecke ich das QNAP an meinen PC, können sie sich sehen.

Soweit, so einfach.

Stecke ich die DS und das andere NAS zusammen, kann ich ja nicht auf die NAS zugreifen.

Stecke ich noch meinen Windows-PC dazu, also die drei in Reihe (QNAP -> DS -> PC) funktioniert kein Ping mehr, sobald das QNAP am 2. NIC der DS steckt. (IP ist auch fest vergeben im selben Netz) Kein Ping mehr möglich vom PC an die DS. Weder auf die IP des NIC1, noch die IP von NIC2.

In meinem Windows PC ist diese NIC eingebaut: Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller. Die sollte mit Jumboframes zurecht kommen, soweit das Netz hier Auskunft gibt. Doku hab ich nicht.

Begehe ich einen strategischen Fehler, oder sehe ich etwas offensichtliches nicht?

Jedenfalls halte ich jetzt schonmal aussschau nach einem geeignetem LowBudget TischSwitch, der JumboFrames beherrscht und wenig Strom frisst, damit ich mir nicht vorkomme, wie in den wilden 90ern, wo man ständig unter den Tisch gekrochen ist, um die Verkabelung zu prüfen oder umzustecken...

 

[itari]

Es gibt zwar in beiden Geräten 2 Netzwerkkarten, aber soweit ich durch Versuche vor einiger Zeit getestet habe, kann man auf der Konsole nicht bestimmen, welches Programm über welches Netzwerkinterface senden/empfangen soll, so das ich theoretisch einfach den rsync auf NIC1 laufen lassen könnte und das interne Netzwerk über NIC2.

jede Netzwerkschnittstelle hat ihre eigene IP-Adresse ... man kann also zwischen 2 Geräten ein eigenes (Sub-)Netz definieren ... und man kann beim rsync-Job satt des NAS-Namens auch die IP eingeben und somit entscheiden, welche Route genommen wird

Itari

 

[rumknapser]

Genau, und ebendies funktioniert(e) nicht einwandfrei oder Störungsanfällig. Doch ich will hier kein Userversagen ausschliessen, deswegen ist der neue Switch schon bestellt und dann kann der Test mit den Jumboframes weitergehen. (Falls bis dahin die Daten nicht eh schon alle kopiert sind...)

 

[rumknapser]

Nahm'

also jetzt ist der neue Switch da (Cisco Small Business SG 100D-08 8-Port Gigabit Switch)
Jumbo-Frames sind bei beiden NAS eingeschaltet, aber es sieht nicht wirklich schneller aus, oder?
Was könnte ich denn überhaupt erwarten?
Es sind die selben rsync-Läufe, wie vor dem neuen Switch.

 

[Theslowman]

Du hast wieder 4 parallel laufen ? Mal nur mit einem getestet ob der Netzwerkdurchsatz steigt ?

Gruß TSM

 

[rumknapser]

Du hast wieder 4 parallel laufen ? Mal nur mit einem getestet ob der Netzwerkdurchsatz steigt ?

Das waren 2.

Bei diesem Screenshot (bildet ca. 20 Minuten ab) ist nur einer am laufen. Im Durchschnitt sind 14 Dateien á ~ 1GB vom QNAP NAS zur DS gewandert und ein paar kleine <~2MB Dateien... sieht eher mickrig aus ;-/


Gucke ich mir mit ifconfig auf beiden NAS die NICs an, sehe ich MTU 9000, also sind die Jumboframes eingeschaltet/aktiv. Der Switch, an dem beide hängen, kann es lt. Beschreibung auch und selbst bei meinem Windows PC, hab ich Jumbo-Frames in den Netzwerkkarteneinstellungen aktiviert. (Hier sehen die Übertragungsraten an die DS aber genauso traurig aus, wie vor dem neuen Switch und mit ohne Jumbo-Frames...)

Hab ich evtl. noch etwas übersehen?

Jetzt, ca. 20 Minuten später, es laufen 2 rsync's...dieses Ergebnis. Auch nicht besser, oder?

 

[Matthieu]

70% CPU-Auslastung sehen für mich aber so aus als würde er jetzt auf beiden Kernen laufen. Es sei denn da läuft noch was im Hintergrund. Auch die iSCSI-Auslastung irritiert mich etwas.

MfG Matthieu

 

[rumknapser]

a)
Das mit den iSCSI Verstehe ich sowieso nicht. Wieso wird da überhaupt etwas angezeigt? M.W. habe ich nichts dergleichen eingerichtet oder verbunden.

b)
Wie kann ich überprüfen, auf wieviel Kernen irgendetwas läuft?

Es ist allerdings so, das je mehr rsyncs laufen, desto mehr CPU Auslastung. Macht schon Sinn, meine ich.

die "kleinen" Amplituren, also die, die sich im Skalabereich von 10 abspielen, kommen übrigens zustande, weil dort immer wieder eine Datei komplett übertragen wurde und rsync zur nächsten Datei springt. Es kommen ein paar kleine Dateien und dann wieder eine Datei á 1GB... Woher die Ausschläge kommen, die bei 40 landen, ist mir nicht klar.

Im Übrigen sieht es von der "Auslastung" (Netz und CPU) bei dem QNAP NAS genauso aus.



Ich möchte es mal so sagen: Mir ist die CPU egal, wie bekomme ich einen besseren Netzdurchsatz hin?

 

[Matthieu]

Ich möchte es mal so sagen: Mir ist die CPU egal, wie bekomme ich einen besseren Netzdurchsatz hin?

Dann bring ichs mal auf den Punkt:
Die CPU ist der Flaschenhals. Mehr Netzdurchsatz führt also über eine bessere Auslastung der CPU. rsync ist nicht darauf optimiert, die CPU zu schonen. Sondern genau gegenteilig: Das Netz schonen und dafür die CPU gnadenlos belasten. rsync ist für WAN-Verbindungen optimiert, und da limitiert sich der Durchsatz meist von selbst ...
Die simpelste Methode wäre auf rsync zu verzichten und es über SMB/CIFS o.ä. abzuwickeln ...

MfG Matthieu

 

[rumknapser]

Die CPU ist der Flaschenhals. Mehr Netzdurchsatz führt also über eine bessere Auslastung der CPU. rsync ist nicht darauf optimiert, die CPU zu schonen.

Bei rsync mag ich Dir hier zustimmen, denn damit kenne ich mich nicht detailliert aus.

Ich habe allerdings gerade einen Test mit SCP gemacht.

Vom QNAP NAS einen SCP auf die DS gemacht (genausorum, wie beim rsync) und das Ergebnis ist -augenscheinlich- fast identisch.

Diesmal wenig(er) CPU-Last, aber derselbe -geringe- Durchsatz (13.2MB/s).
(Die Pausen kommen zustande, da der SCP fertig war und ich ihn nicht direkt neu gestartet habe, aber die Ausschläge sind mit denen aus dem obigen Screenshots bei rsync ja doch fast identisch würde ich sagen...)

Ich möchte Dir also hier (für meinen konkreten Fall natürlich nur) widersprechen, denn ich meine nicht, dass der geringe Datendurchsatz über das Netz -ausschliesslich- an der hohen CPU-Auslastung liegt, die rsync verursacht.

Sicherlich gestehe ich rsync seine "Nachteile" ein, die Du beschreibst, doch ich möchte nocheinmal meine Frage an alle wiederholen, wie ich es wohl schaffen könnte, für mehr Datendurchsatz auf der DS zu sorgen? Bzw. was könnte ich wohl noch prüfen/umstellen, damit ich den wirklichen Flaschenhals oder die ungünstigen Einstellungen enttarne?

Evtl. noch ein Nachtrag zu SMB.

Ich habe nun von der DS via smbclient //server/share und mget Daten auf das QNAP NAS kopiert. (leider ist auf dem QNAP NAS kein smbclient, deswegen musste ich die Kopierrichtung ändern, ich weiss nicht, ob das Auswirkungen auf die Geschwindigkeit haben kann...)
Das Resultat sieht etwas besser auf dem Screenshot aus, aber auch nicht wirklich (24721.8 KiloBytes/sec) (average 24707.1 KiloBytes/sec).

(hinten im Screenshot die grüne Linie zeigt den SMBClient vorgang)

Ich weiss allerdings auch nicht wirklich, das für Übertragungsraten ich überhaupt erwarten darf. Aber wirklich schnell kommt mir das nicht vor...

Über einen Windows-Rechner (am selben Switch) bekomme ich auch im Durchschnitt 25MB/s.

 

[BavariaR]

70% CPU-Auslastung sehen für mich aber so aus als würde er jetzt auf beiden Kernen laufen. Es sei denn da läuft noch was im Hintergrund. Auch die iSCSI-Auslastung irritiert mich etwas.

MfG Matthieu

habe zwar nichts zum eigentlichen Thema beizutragen, möchte aber meine Erkenntnisse zur iSCSI Grafik beitragen, weil mich das auch bereits gewundert hatte und ich der Sache auf den Grund gegangen bin. Die Grafik iSCSI ist auch Volume anzeige. Es gibt einen Unterschied zwischen Datenträger Anzeige und Volume / iSCSI Anzeige. Die Datenträger anzeige zeigt die Aktivität die rein auf den Platten passiert, muss nicht durch Datentransfert (kann aber) von oder zu einem Volume stammen, kann zum Beispiel rein der Verkehr sein den RAID generiert um die Paritäten zu schreiben (unter "Alle Anzeigen kann man das sogar für jede Platte einzel sehen und so zum Beispiel erkennen warum einzelne Festplatten dauernd rum rödeln ohne dass es überhaupt Datenverkehr zur DS gibt). Der Volume Traffic ist wirklich der reine Traffic der auf ein Volume / Verzeichnis geht und Daten von einem Volume zum anderen oder von oder nach außerhalb der DS (dieser verursacht auf alle Fälle auch Datenträger Traffic aber nicht zwangsweise umgedreht... es kann durchaus Datenträger Traffic geben ohne Volume Traffic).

Den Unterschied kann man ganz toll beobachten wenn man zum Beispiel ein Volume / Diskgruppe erweiterte mit neuen Platten, dann gibt es 0 Volume/iSCSI Verkehr aber massig Datenträger Verkehr. Volume und iSCSI werden nur deshalb in einer Grafik angezeigt weil sie im Prinzip das selbe sind, entweder ein ext-Partition oder eben ein iSCSi Container.

 

[rumknapser]

meine Erkenntnisse zur iSCSI Grafik beitragen

Recht vielen Dank für das Licht in diesem Teil des Tunnels! Das war sehr hilfreich um weiteren Spekulationen meinerseits vorzubeugen und spart mir auch viel Zeit. Danke nochmal!