Samba Performance Probleme

V

Vengance

Member
Hallo,

Ich betreibe auf einem Raspberry PI 4 einen Samba Server.
Der PI hat eine externe 8TB WD MyBook (kein SMR) via USB 3 angeschlossen.


In den meisten Fällen funktioniert der Transfer problemlos und ich reize das Gigabit Netzwerk mit 111mb/s komplett aus.
Nun musste ich jedoch festellen, dass teilweise die Schreibrate extrem schwankt, zwischen rund 70mb/s und 100mb/s oder auf knapp 100mb/s "feststeht".
Bei allen Tests wurden einzelne große Dateien genutzt, zwischen 10GB und 50GB.


Scheinbar hilft es dann jedoch den Client (eine Windows Workstation) neu zu starten und anschließend läuft der Transfer für eine gewisse Zeit wieder ohne Probleme.


Die Temperatur ist wärend des Transfers im grünen Rahmen, es findet also keine Drosselung statt.
Der IO delay ist ungefähr doppelt so hoch, wenn die Schreibgeschwindigkeit wie bereits erwähnt Probleme macht.

Hier die beschriebenen Probleme (oftmals noch deutlich stärkere Schwankungen als hier dargestellt):
oPKD1ZV.png



Hier nach einem Neustart des Clients:

sldUp0t.png



Hat jemand eine Idee was hier die Ursache sein könnte?
Ich bin mitlerweile absolut ratlos und kann auch kein Muster erkennen.
Ich kann mir auch nicht wirklich erklären, ob es Client Seitig oder Serverseitig ist, ich tippe eher auf ersteres, da ja meistens ein Neustart des Clients geholfen hat.


Grüße
Ian

Samba config:
Code: 
[global]
wins support = yes
workgroup = WORKGROUP
server string = nas
netbios name = nas
security = user
map to guest = Bad User
protocol = SMB3
load printers = no
disable spoolss = yes
max log size = 50
socket options = IPTOS_LOWDELAY TCP_NODELAY
deadtime = 30
use sendfile = yes
read raw = yes
write raw = yes


[ian]
comment = Privat
path = /mnt/hdd/ian
write list = ian
valid users = ian
force user = ian
 
Auch wenn ich dir keinen Lösungsweg vorschlagen kann, bei Samba hilft generell als erster Einstiegspunkt ein simpler Wireshark auf Clientseite um Paketanomalien, Protokoll-Timeouts oder sonstige Problemquellen fest zu stellen. Bruteforce... aber hilft meistens (mehr als Samba-Logs...)

Muss der Windows-Client wirklich neu gestartet werden oder reicht es dass *irgendwas* neu gestartet wird damit die Verbindung neu aufgebaut wird. Sprich wird die Leistung durch Ausstöpseln des Client-Netzwerkanschlusses oder Neustart des RPI auch wiederhergestellt?
 
Danke, Wireshark habe ich bereits versucht, muss ich mal versuchen, mich da etwas reinzufinden.

Wenn ich mich recht erinnere hat es teilweise ebenfalls geholfen den WIndows Explorer neu zu starten, dementsprechend die Verbindung neu aufzubauen.
 
Nachdem die Workstation nun im Energiesparmodus/ Ruhezustand war trat das Problem anschließend wieder auf, die Geschwindigkeit Schwanke ständig zwischen 90-100mb/s.

Hier hatte nur ein Neustart geholfen, anschließend wieder keine Probleme.

Sieht wohl wirklich nach einem Clientseitigen Problem aus?
Die Windows Installation ist jedoch keine zwei Tage alt, davor trat das selbe Problem auf, weshalb ich eine Neuinstallation versucht habe.
 
Vengance said:
die Geschwindigkeit Schwanke ständig zwischen 90-100mb/s.
Click to expand...
Boa, das ist ja voll die krasse Schwankung, wenn da mal nicht Die dahinterstecken...

Im Ernst: Das ist eine völlig normale Schwankung und wird durch diverse Hardware-/Software-Buffer und Protokolleigenschaften sowohl auf Clientseite als auch auf Serverseite verursacht.
Erst wenn diese Schwankungen ständig >20% liegen könnte man mal genauer nachschauen, ab >30% sollte man dann wirklich mal nachsehen.

Von <=10% träumen die meisten Netzwerkadmins nur, also mach Dir einen Schampus auf und hol den Kavier aus der Kühlung, Du darfst feiern...
 
Wie oben geschrieben war das auch einer der besseren Durchläufe.

Gerade wieder bewegte sich der Durchschnitt bei rund 70mb/s.
Wenn ich nun größere Datenmengen kopiere macht es definitiv einen Unterschied ob ich mit 70mb/s oder 110mb/s die Daten rüberschiebe.

Es geht nicht um die größe der Schwankung sondern die mir unerklärlichen Performanceeinbrüche welche jedoch immer entweder durch einen restart des Explorers oder des Client PCs behoben werden.

Das klingt ja an sich nach einem Client Problem, aber es wundert mich, dass in den Fällen der IO Wait auf dem Server auch deutlich höher ist.
Kann das dennoch durch den Client verursacht sein?
 
IO Wait bedeutet genau was der Name sagt "Input/Output Wait". Das muss nicht zwingend die Festplatte sein, sondern kann auch Netzwerk-Verarbeitung sein, zumal auf einem bereits (vergleichsweise) schwachen Gerät ohne hardware-offloading für Netzwerkverarbeitung. (IO Wait entsteht quasi jederzeit wenn die CPU auf eine Peripherie wartet)
Hier könnte zB die TCP-Window nach dem Sleep kleiner sein als Maximum oder ständig zurück-congested werden ,letzteres erkennt man an ständigem langsamen Wachsen der Geschwindigkeit mit recht abruptem Einbrechen.

Allein auf Basis der Paketgrösse und -pattern sowie der von Wireshark potentiell hervorgehobenen Besonderheiten (rote/schwarze Linien) kann man mögliche Anomalien dahingehend feststellen indem man Vorher-Nachher vergleicht. Ich würde empfehlen deine Feststellungen hier zu screenshoten, gerne kann man sich auch mal in die falsche Richtung festbeissen und totoptimieren ohne das Problem zu finden.
Ich mag auf Serverseite auch atop (apt install atop) im Kurzzeitmodus (bspw: atop -af 5) um zu erkennen was genau der Flaschenhals sein könnte.

Samba ist sehr empfindlich für *jegliche* Anomalie zwischen Client und Server und rächt sich schnell mit suboptimaler Performance. Die Analyse ist aber nicht unbedingt trivial wie man hier wieder sieht ;)
 
QnD-Versuch: Einfach mal einen anderen Client versuchen.

Zudem sind RaspPis - wenn's um max. Durchsatz bei minimaler Latenz geht - leider die falsche Wahl.
 
@d4f
Danke dir für deine ausführliche Antwort!

Habe ich auf das von dir beschriebene TCP-Window einen Einfluss?

Ich habe zusätzlich mal atop installiert und werde davon auch nochmal einen Screenshot schicken, wenn es wieder auftritt.

Wenn ich den Client frisch starte, dann ist der Transfer nahezu immer stabil, zu Problem kommt es dann oft entweder nach einem Sleep des Clients oder nach vielen Transfers (mit bspw. kleineren Dateien).

Dann hat meistens aber auch wieder ein Restart geholfen.

Ich werde auch Wireshark dann mal mitlaufen lassen.


@marce
Ich habe ansonsten leider nur macOS Clients hier, da hatte ich prinzipiell schlechte Erfahrungen was die Performance mit Samba angeht, da Apple hier eine eigene Implementation nutzt.
 
Habe ich auf das von dir beschriebene TCP-Window einen Einfluss?
Click to expand...
Auf die Maximalgrösse nur in Form von Treiber/Kernelparameter, aber das ist hier nicht das Problem. Die reale ("ausgehandelte") Fenstergrösse wird dynamisch durch den TCP-Congestion Algorithmus determiniert und kann ständig variieren, sollte aber generell nicht zusammenbrechen.
Um etwas Kontext zu geben: wenn ein System (Netzwerk / Router / Empfänger / ...) überlastet wird, wird das TCP-Paket einfach weggeworfen. Der Absender bemerkt diesen Packetloss und der TCP Congestion (deutsch: Stau) Algorithmus geht dann die Datengrösse reduzieren bevor er es erneut sendet, beim üblichen Algorithmus CUBIC generell etwa um 30%. Danach geht er wieder hoch.
==> Lektüre: https://blog.cloudflare.com/cubic-and-hystart-support-in-quiche/

macOS Clients hier, da hatte ich prinzipiell schlechte Erfahrungen was die Performance mit Samba angeht
Click to expand...
Etwas Kornpicken: Samba ist eine Implementierung des SMB-Protokolls. Unter MacOS heisst die mittlerweile Apple-eigene Implementierung SmbX.
(Nicht ganz so) langsam aber sicher wird halt aus OSx ein volles closed-source System. Die Zeiten von CUPS und Co sind halt vorbei.
 
Den Client anstelle von Sleep herunterzufahren hat bisher wohl weitergeholfen und das Problem ist weniger geworden.
Ich werde aber dennoch mal weiterhin ein Auge darauf haben und nochmal berichten.

Was mir jedoch aufgefallen ist, dass die Performance unter Windows mit Abstand am besten ist.

macOS = Ist in Benchmarks (Blackmagic Disk Speed test) quasi genauso gut, bei reellen Tests und dem kopieren großen einer Datei aber ständige Schwankungen zwischen 20mb/s und 112mb/s.

Ubuntu = Hängt stabil bei rund 40-50mb/s

Der PI hat wärenddessen weder einen hohen IO Wait, noch eine hohe CPU Auslasung.
Scheint also wieder irgendwas Clientseitiges zu sein


Edit:

Wenn man vom Teufel spricht, jetzt tritt es auch wieder im Betrieb häufiger auf...
Es hat weder der Restart von Samba noch von dem Explorer geholfen, lediglich der Neustart des PCs.

Und das stellt leider keine wirkliche Option dar, im laufenden den Client ständig zuzustarten
@d4f Wenn ich das richtig verstehe spricht das Wohl für die Ursache beim Receive Window Scaling?


Die Wireshark Resultate haben mir leider nicht wirklich weitergeholfen.

pfyV5c6.png
 
Last edited:
@Joe User

Das denke ich eben nicht, ich habe heute bestimmt 200GB testweise kopiert und bisher null Probleme gehabt, dazwischen lag auch kein Reboot oder ähnliches.

@GwenDragon
Das könnte sein, abgesehen von den standardmäßigem Windows Defender ist jedoch nichts installiert.
 
Schon nachgesehen, was der Defender-Prozess im Task-Manager denn zulässt an Datendurchsatz? Schnell ist der nicht beim Scannen und Transnfer. In jedem Fall solltest du das mal prüfen, um eben auszuschließen dass der Einfluss hat. Warum ich das schreibe? Aus leidvoller Erfahrung über die Jahre mit so manchem Defender.
 
Ich habe den Windows Defender nun mal deaktiviert, auhc wenn der Taskmanager keine auffälligen Prozesse gezeigt hat.

Hatte das Problem eben wieder, direkt nach dem Hochfahren des Clients, es hat wieder nur ein Neustart geholfen.
Danach war die Transferrate wieder ohne Probleme.

Ich habe wirklich absolut keine Ahnung wie ich mir das noch erklären kann oder wo hier die Ursahce liegen könnte.
Es scheint ja eher Clientseitig als Serverseitig aufzutreten.
 
Ich summiere mal; ausschliesslich client-seitig. Tritt nach Suspend/Sleep auf. Nur durch ein Neustart des OS lösbar.
Klingt nach aktuellem Stand potentiell nach "unlösbar". Versuch mal interessehalber den Netzwerktreiber im Device-Manager zu deaktiveren/reaktivieren und/oder Netzwerkkabel zu ziehen.

Aber ich fürchte hier sind wir wirklich ausserhalb des beinflussbaren Bereichs.
 
Schon mal die Treiber für die Netzwerkkarte aktualisiert. Windows bringt zwar viele Treiber mit, aber es sind nicht immer die aktuellsten.
 
Treiber sind die aktuellsten.

Ich habe gestern Abend im FreeNAS Forum entdeckt, dass die meisten der "Performance Optimierungen" mittlerweile nichtmehr empfohlen werden.

Habe die config daher mal aufs nötigste reduziert und werde es weiterhin mal beobachten.
 
d4f said:
Ich summiere mal; ausschliesslich client-seitig. Tritt nach Suspend/Sleep auf. Nur durch ein Neustart des OS lösbar.
Klingt nach aktuellem Stand potentiell nach "unlösbar". Versuch mal interessehalber den Netzwerktreiber im Device-Manager zu deaktiveren/reaktivieren und/oder Netzwerkkabel zu ziehen.

Aber ich fürchte hier sind wir wirklich ausserhalb des beinflussbaren Bereichs.
Click to expand...

Ja, mit vielen Transfers konnte ich das Problem aber auch provozieren.
Treiber ist aktuell, das Deaktivieren der NIC hat dann leider auch nicht geholfen.

Bin wirklich ratlos und es scheint wohl wirklich "unlösbar" zu sein.
 
You must log in or register to reply here.
Back
Top