Patient0
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
Ich habe folgendes Problem mit Samba:
Seit einiger Zeit (~3-5 Monate) habe ich eine stark reduzierte Zugriffsgeschwindigkeit auf Samba-Shares.
Technisch sind über die Netzwerkverbindung 30-45 MiB/s möglich, diese werden nach einigen Änderungen der fstab-Parameter im Download auch teilweise (wieder) erreicht, im Upload komme ich jedoch (unter Kubuntu) nicht über 15 MiB/s hinaus, meistens pendelt sich die Geschwindigkeit zwischen 7 und 13 MiB/s ein. Ein (per Gbit-LAN angebundener) testweise aufgesetzter Windows 10-Client erreicht lesend wie schreibend >110 MiB/s beim Zugriff, das NAS ist dementsprechend aller Wahrscheinlichkeit nach kein Flaschenhals.
Ein Netzwerk-Durchsatz-Test mittels iperf3 ergab in beide Richtungen jeweils zwischen 325 Mbit/s und 380 Mbit/s, was min. etwa 40 MiB/s entspricht, dort ist also m.E. ebenfalls kein Flaschenhals zu finden.
In der Vermutung, evtl. in der /etc/samba/smb.conf etwas verkonfiguriert zu haben, habe ich diese testweise zeitweise "gelöscht" (wegverschoben) und dadurch ebenfalls keine Besserung erzielt. Die technischen Daten: Client: Laptop mit Kubuntu 20.10 (ebenfalls per live gebootetem 21.04 getestet), Samba-Version 4.12.5-Ubuntu Fstab-Eintrag:
| //$IP-Adresse/Daten /mnt/Daten cifs users,sfu,exec,_netdev,iocharset=utf8,file_mode=0777,dir_mode=0777,rw,nofail,uid=1000,gid=1000,credentials=/Pfad/zur/.smbcredentials,sec=ntlmssp,vers=3.1.1 0 0
|
Server: Tower-PC mit Openmediavault 5.6.4-1 (Debian Buster), Samba-Version 4.9.5-Debian
Ich habe an den Konfigurationsdateien (smb.conf etc.) nichts geändert und die Einstellungen für die Samba-Shares im Web-GUI auf den Default-Einstellungen belassen. Ich habe alle Tests per GUI-Kopierfunktion (Dolphin) mit großen Dateien (>1GiB) durchgeführt.
Getestet habe ich vier verschiedene Konstellationen: 1. Kubuntu 20.10, Mount des Shares via fstab mit oben genanntem fstab-Eintrag:
Download: 32-35 MiB/s
Upload: ~12 MiB/s 2. Kubuntu 20.10, Mount des Shares via Dolphins "Netzwerk"-Funktion (also smb://IP-Adresse/Share in die Adresszeile eingetragen)
Download: ~14 MiB/s
Upload: ~12 MiB/s 3. Kubuntu 21.04 (boot per Live-USB 3.0-Stick), Mount des Shares via fstab mit oben genanntem fstab-Eintrag:
Download: 35-40 MiB/s
Upload: einmal ~14 MiB/s, beim nächsten Versuch 35 MiB/s (was dann bei mir völlige Verwirrung ausgelöst hat) 4. Kubuntu 21.04 (boot per Live-USB 3.0-Stick), Mount des Shares via Dolphins "Netzwerk"-Funktion (also smb://IP-Adresse/Share in die Adresszeile eingetragen)
Download: 35-45 MiB/s
Upload: 35-40 MiB/s Abseits davon habe ich noch einmal testweise mit einem live vom ISO gebooteten Linux Mint 20 getestet, mir die genauen Werte davon jedoch leider nicht aufgeschrieben. Was ich aber definitiv noch weiß: Beim fstab-Mount hatte ich unter Mint in beide Richtungen "volle Geschwindigkeit" (also >35 MiB/s) Ich habe zu diesem Phänomen bisher im Internet nichts zielführendes gefunden und hatte etwas auf die vorgestern veröffentlichte *ubuntu-Version 21.04- gehofft, um diesem Zustand durch ein Update beizukommen, das jedoch auch eher semi-erfolgreich, wie oben beschrieben. Da ich an dieser Stelle mit meinem Latein am Ende bin, hoffe ich auf hilfreiche Hinweise von anderen Samba-Nutzern.
|
micneu
Anmeldungsdatum: 19. Januar 2021
Beiträge: 217
|
Patient0 schrieb: Ich habe folgendes Problem mit Samba: 4. Kubuntu 21.04 (boot per Live-USB 3.0-Stick), Mount des Shares via Dolphins "Netzwerk"-Funktion (also smb://IP-Adresse/Share in die Adresszeile eingetragen)
Download: 35-45 MiB/s
Upload: 35-40 MiB/s Abseits davon habe ich noch einmal testweise mit einem live vom ISO gebooteten Linux Mint 20 getestet, mir die genauen Werte davon jedoch leider nicht aufgeschrieben. Was ich aber definitiv noch weiß: Beim fstab-Mount hatte ich unter Mint in beide Richtungen "volle Geschwindigkeit" (also >35 MiB/s)
ich bin ein wenig verwirrt, wenn du per ethernet testet und nur 350mbit hast, das ist für mich nicht volle geschwindigkeit (ethernet: 1GBit/s)
oder testest du aqlles mit wlan (steht nirgends im text), bitte mal einen grafischen netzwerkplan. welche netzwerk komponenten werden genutzt (hersteller/model) router (hersteller/model) wlan (2,4ghz/5ghz)? entfernung zum router vom client (solltest du wlan nutzen, bitte auch mal testen wenn du direkt vor dem router sitzt) bitte solltest du es nicht mit ethernet getestet haben, diese mal machen ich bevorzuge bei großen dateien (das ist bei mir täglich, immer ethernet, wlan ist für surfen gut aber große dateien übertragen macht kein spaß) ethernet was zeigt bei deinem notebook das ergbins bitte mal posten
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
micneu schrieb: ich bin ein wenig verwirrt, wenn du per ethernet testet und nur 350mbit hast, das ist für mich nicht volle geschwindigkeit (ethernet: 1GBit/s)
oder testest du aqlles mit wlan (steht nirgends im text), bitte mal einen grafischen netzwerkplan.
Stimmt, das hatte ich vergessen, zu erwähnen - mein Fehler. Der Laptop hängt per WLAN (AC, also 5 Ghz) im Netz. Per Gbit-LAN habe ich mit einem davon unabhängigen Tower (mit testweise installiertem Win10) getestet, um auszuschließen, dass das NAS nicht mehr schafft. (Dass Gbit-LAN auf deutlich mehr als 350 Mbit/s kommen muss, ist mir durchaus klar. ☺ )
Eine grafische Netzwerkskizze dauert bei meinen digitalen Animationskünsten länger, die reiche ich nach, falls noch benötigt. In Kürze: OpenMediaVault Tower-PC ← Gbit-LAN → FritzBox 4040 ← WLAN AC (5 Ghz, ~4m Distanz)→ Laptop (WLAN-Karte: Intel AX200)
Mehr Netzwerkhardware ist an der Verbindung nicht beteiligt. ca. 4 Meter, siehe oben. Wenn ich näher herangehe, sind definitiv auch mehr als 45 MiB/s möglich, aber es würde mir ja bereits genügen, wenn ich diese - auch für Samba-Zugriffe - zuverlässig erreichen würde. 😀 Per Ethernet hatte ich in der Vergangenheit bereits getestet (auf dem Problem kaue ich schon länger herum), werde das aber gleich zur Sicherheit nochmal wiederholen und die Ergebnisse hier nachtragen. Meiner Erinnerung nach war es gleich-langsam (und damit deutlichst unter 1 Gbit/s), was mich erst auf irgendeinen Samba-Protokoll-Fehler gebracht hat. EDIT:
Anbindung per Gbit-LAN (das installierte Kubuntu 20.10): Iperf3-Test kommt in beide Richtungen auf ~935 Mbit/s, das sieht schon eher nach Gbit-Tempo aus. Test per fstab-Mount: Upload: schwankt zwischen 20 und 40 MiB/s (was per LAN definitiv zu wenig ist) Download: schwankt zwischen 65 und 70 MiB/s Test per smb://IP/Share in Dolphin: Upload: konstant ~36 MiB/s Download: konstant ~38 MiB/s Wenn ich ein 400 GiB-Backup aufs NAS-schiebe, ist LAN definitv angenehmer. Ich störe mich aber auch bei kleineren Dateien daran, nicht die volle WLAN-Bandbreite für die Samba-Übertragung nutzen zu können. (und vermutlich auch nicht das volle Gbit von LAN, das teste ich gleich nochmal)
Und mal ehrlich: Ich habe per WLAN AX, direkt vor einem AX-fähigen Router sitzend, schon Netto-Datenraten von 80 MiB/s erreicht. Da ist der Weg bis zum perfekten Gbit-Tempo (~110 MiB/s) nicht mehr all zu weit. 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
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: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether $MAC-Adresse brd ff:ff:ff:ff:ff:ff
altname enp2s0
3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether $MAC-Adresse brd ff:ff:ff:ff:ff:ff
inet $IPv4-Adresse/24 brd 192.168.69.255 scope global noprefixroute wlp1s0
valid_lft forever preferred_lft forever
inet6 $IPv6-Adresse/64 scope link
valid_lft forever preferred_lft forever
|
|
chr123
Anmeldungsdatum: 19. Juli 2018
Beiträge: 1632
|
Die unterschiedlichen Geschwindigkeiten per fstab (genauer: per CIFS-vfs via mount.cifs) und per GUI (genauer: per libsmbclient via kio-slave) sind leider erwartbar. Was du noch testen könntest: sind die cifs Protokollversion alle gleich langsam? Dazu die verfügbaren Versionen ermitteln
sudo apt install nmap
sudo nmap --script smb-protocols 192.168.178.1
Logischerweise noch die richtige IP ergänzen.
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
chr123 schrieb: Die unterschiedlichen Geschwindigkeiten per fstab (genauer: per CIFS-vfs via mount.cifs) und per GUI (genauer: per libsmbclient via kio-slave) sind leider erwartbar.
Aber auch in diesem Ausmaß ? Die Geschwindigkeit im Upload (bei der von mir favorisierten Methode, also CIFS-vfs via mount.cifs) scheint geradezu auf 12 MiB/s festgenagelt zu sein. Ich bin mir sehr sicher, dass das in der Vergangenheit anders (schneller) war. Was du noch testen könntest: sind die cifs Protokollversion alle gleich langsam? Dazu die verfügbaren Versionen ermitteln
sudo apt install nmap
sudo nmap --script smb-protocols 192.168.178.1
1
2
3
4
5
6
7
8
9
10
11
12 | sudo nmap --script smb-protocols $IP-Adresse
(...)
Host script results:
| smb-protocols:
| dialects:
| NT LM 0.12 (SMBv1) [dangerous, but default]
| 2.02
| 2.10
| 3.00
| 3.02
|_ 3.11
(...)
|
Ich nehme mal an, ich probiere die dann einfach per fstab-Option "vers=1.0" etc. durch ?
|
chr123
Anmeldungsdatum: 19. Juli 2018
Beiträge: 1632
|
Ja, genau. Es werden ja diverse Versionen vom Server angeboten.
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
vers=1.0: Upload: lässt erst für ca. 30 sek die I/O einfrieren, dann ~13,5 MiB/s | Download: ~45 MiB/s (ist so ein krasser Unterschied auch normal ?) vers=2.0: Upload: lässt für >1min die I/O einfrieren, sinkt dann von ~1,8 GiB/s (angezeigt) auf zwischen 30 und 40 MiB/s (real). Dateisystem bleibt danach noch ca. 2-3min im Freeze und ist danach sehr langsam in der Reaktion auf Eingaben (Markieren, kopieren, Umbenennen etc. von Dateien dauert min. 30 sek). | Download: Freeze für ~45 sek, dann ~26 MiB/s vers=2.1: Upload: 12-13 MiB/s | Download: 42-45 MiB/s | keinerlei Freezes. vers=3.0: Upload: erst die üblichen 13 MiB/s, dann (nach ca. 2 min in dem Tempo) Sprung auf 60 MiB/s (angezeigt), dann langsames Absinken Richtung 35 MiB/s. Parallel und anschließend erneut I/O-Freeze(s), die ein Bedienen von Dolphin unmöglich machen. | Download: 42-45 MiB/s vers=3.02: Upload: konstant 13,1 MiB/s (anschließend ca. 1 min Freeze) | Download: zwischen 35 und 40 MiB/s Die Version 3.11 / 3.1.1 habe ich ja bereits weiter oben beschrieben. Die einzige Version, die grundsätzlich brauchbare (Upload-)Geschwindigkeit erzielt hat - vers=2.0 - lässt dafür Dolphin einfrieren und macht ein weiteres Arbeiten mit irgendwelchen (auch lokalen) Dateien während des Kopiervorgangs unmöglich. Das kann doch nicht ernsthaft der Normalzustand von Samba unter Linux sein ?! Zumal es bei Mint ja besser funktioniert.
|
chr123
Anmeldungsdatum: 19. Juli 2018
Beiträge: 1632
|
Das Einfrieren entsteht wohl beim Cachen. Schalt doch mal den Cache per Option cache=none in deiner fstab. Warum hast du eigentlich die Option sfu aktiviert?
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
chr123 schrieb: Das Einfrieren entsteht wohl beim Cachen. Schalt doch mal den Cache per Option cache=none in deiner fstab.
Habe eben folgende Szenarien getestet: cache=none,vers=3.1.1 und cache=none,vers=2.0 Beide Versionen verursachen keine verbesserte Upload-Geschwindigkeit, dafür ist die Downloadgeschwindigkeit ohne Cache genauso langsam wie der Upload. 🙄 Warum hast du eigentlich die Option sfu aktiviert?
Ich hatte in der Vergangenheit (vor ca. einem halben Jahr) Freeze-Probleme beim Markieren (oder sogar schon durchgucken) von vielen Dateien auf dem NAS.
Das hat zu dem Zeitpunkt auf Clientseite einen Fehler im Kernel-Log (dmesg) und im Syslog verursacht, der mich - über eine Microsoft-SAMBA-Fehlercode-Seite und die mount.cifs-Manpage - auf diese Option gebracht hat (ohne, dass ich die genauen Zusammenhänge verstanden hätte). Ab Nutzung dieser Option waren diese Freezes bei vielen Dateien in einem Ordner (oder der schnell aufeinanderfolgenden Markierung mehrerer Dateien) behoben.
|
chr123
Anmeldungsdatum: 19. Juli 2018
Beiträge: 1632
|
Es gibt noch ein paar andere Optionen, die man durchtesten könnte:
noserverino
nobrl Aber wenn es unter Mint geht, dann muss es ja einen Unterschied zwischen Ubuntu und Mint geben. Unter welcher Mint Version klappt es denn und vor allem, klappt es per libsmbclient oder per Kernelmodul (via CIFS-vfs).
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
Test mit aktiviertem noserverino: Upload: erst 1,5 GiB/s (angezeigt), dann rapide Absinken auf 30 MiB/s (vermutlich real), diese für ca. eine Minute. Dann hängt der Kopiervorgang (mit "0 MiB/s". Das serverseitige Dateisystem ist währenddessen nicht mehr zugreifbar - Neustart nötig. Download: Sofort und konstantes Tempo (45-49 MiB/s). Kein Freeze. Test mit aktiviertem nobrl: Upload: erst 1,5 GiB/s (angezeigt), dann rapide Absinken auf ~50 MiB/s, ab dem Zeitpunkt schwankend zwischen 25 und 65 MiB/s - dabei ist der Dateisystemzugriff aufs NAS mittelmäßzig zeitverzögert (ca. 5 sek Lag beim Auswählen einer Datei), aber kein kompletter Freeze - nach "Abschluss" des Kopiervorgangs hängt er noch ca. 2 min bei 100% und 0 MiB/s (vermutlich aufgrund der Tatsache, dass er am Anfang mit 1,5 GiB/s in den Cache geschrieben hat). Download: konstant 45-49 MiB/s. Diese beiden Tests waren wieder per WLAN (wie alle davor auch). Dank der recht vielversprechenden Geschwindigkeit jetzt einmal nobrl per LAN-Verbindung: Upload: Sehr ähnliches verhalten wie per WLAN, nur dass die Geschwindigkeit (vermutlich nach dem Cache) zwischen 60 und 90 MiB/s schwankt. Auch hier am Ende das Absinken auf 0 MiB/s bei "100%". Download: konstant 66-70 MiB/s. chr123 schrieb: Aber wenn es unter Mint geht, dann muss es ja einen Unterschied zwischen Ubuntu und Mint geben. Unter welcher Mint Version klappt es denn und vor allem, klappt es per libsmbclient oder per Kernelmodul (via CIFS-vfs).
In Linux Mint (20.1, also dem derzeit aktuellen) hatte ich das ganze ebenfalls per fstab (also per CIFS-vfs) getestet.
Mint 20.1 basiert meines Wissens auf Ubuntu 20.04, was ich kurioserweise im Gegensatz zu Mint aufgrund der AMD Ryzen-CPU in meinem Laptop jedoch nichtmal booten kann, um damit gegenzutesten. Dem fehlen vermutlich irgendwelche notwendigen Treiber. Vor allen Dingen habe ich für Mint aber die gleichen fstab-Einträge genutzt (die Optionen eins zu eins kopiert):
| //$IP-Adresse/Daten /mnt/Daten cifs users,sfu,exec,_netdev,iocharset=utf8,file_mode=0777,dir_mode=0777,rw,nofail,uid=1000,gid=1000,credentials=/Pfad/zur/.smbcredentials,sec=ntlmssp,vers=3.1.1 0 0
|
Bisher war die nobrl-Option am Wirksamsten. Wobei Mint meiner Erinnerung nach auch diese unrealistischen Cache-Schreibgeschwindigkeiten (samt dem anschließenden Stillstand bei 100%) beim Upload nicht hatte. Ich muss das nochmal gegentesten und trage es anschließend hier nach. EDIT: Korrektur: Die anfangs unrealistischen Übertragungsraten (>= 1,5 GiB/s) - die vermutlich aufgrund des Caches entstehen - sind bei Mint genauso zu beobachten. Bei Mint friert allerdings das Dateisystem nicht ein (auch ohne nobrl).
|
chr123
Anmeldungsdatum: 19. Juli 2018
Beiträge: 1632
|
Das Einfrieren liegt vielleicht an der Desktopumgebung. Evtl. bietet der Server auch NFS als Alternative zu SMB an.
|
Patient0
(Themenstarter)
Anmeldungsdatum: 20. März 2021
Beiträge: 31
|
Ja, OMV unterstützt auch NFS. Habe ich bei den früheren Freeze-Problemen mal eine Weile als Workaround genutzt.
Das möchte ich allerdings auf Dauer vermeiden, da keine Zugriffsbeschränkung abseits von einer(!) IP-Adresse möglich sind.
|