SMB war shon immer eine Krankheit

[/mecki78]

Windows kopiert immer langsam über Netzwerk, egal in welcher Version, auch dann wenn es da neues SMB verwendet, weil SMB an sich einfach langsam ist. Außerdem kommt SMB nicht mit Latenzen zurecht . Sobald man damit über einen Brigde oder ein VPN auf Daten zugreift, bricht die Performance komplett ein und dann ist so ziemlich alles andere schneller, das man sonst dafür nehmen könnte.

/Mecki

[JouMxyzptlk]

Komisch, meine Erfahrung ist, seit SMB2, eine andere. Damit seit etwa 2007. Wäre ja auch echt komisch wenn unsere Kunden alle nicht das Leitungslimit mit SMB+VPN erreichen könnten.
Bei SMB1 stimmt deine Aussage.
Hast du mehr Details? Denn bei SQLite oder Access über VPN sind so Beispiele wo ich mir vorstellen könnte dass es zickt.

[/mecki78]

JouMxyzptlk schrieb:
--------------------------------------------------------------------------------
> Beispiele wo ich mir vorstellen könnte dass es zickt.

Kopiere eine große Datei per SMB über ein VPN (so dass du eine RTT von mindestens 40-60 ms hast) und messe genau wie lange das dauert. Wiederhole das mit HTTP, FTP, AFP, NFS, SFTP (SCP), oder rsync und es wird jedes mal schneller sein, teilweise deutlich schneller.

Machst du den Test im LAN mit RTTs von gut unter 1 ms, dann merkt man kaum einen Unterschied.

Das blockbasierte Protokolle hier deutlich Nachteile haben, mag einleuchten. Deswegen sind hier HTTP und FTP klar im Vorteil, denn hier folgt auf eine Anfrage nur noch Daten, da keine Blöcke einzeln angefordert werden müssen. Und SFTP und rsync sind zwar blockbasiert, können aber die Blockgröße jederzeit beliebig variieren und sich daher auch fast wie streams verhalten. Allerdings sind AFP und NFS auch blockbasiert und haben dennoch weniger Probleme mit hohen Latenzen.

Man kann SMB für hohe Latenzen tweaken, indem man bestimmte Registry Keys von Hand setzt, das muss man dann aber auf Client und Server tun, das verschlechtert die Performance aber im LAN und erhöht den Ressourcenverbrauch und man muss halt auch grob wissen, was man da tut (man kann da nicht irgendwelche Werte eingeben). So etwas sollte das System IMHO selber tun, und zwar pro Verbindung, oder das Protokoll sollte so etwas selber aushandeln bzw. im laufenden Betrieb erkennen und sich anpassen. Aber dafür ist SMB viel zu primitiv, was lachhaft ist, weil es ansonsten das komplexeste aller oben genannten Protokolle ist, weswegen es nur wenige Implementierungen davon gib und jede ist auf die eine oder andere Art fehlerhaft.

/Mecki

[JouMxyzptlk]

Du hast alle Details, welche relevant sein könnten, ausgelassen.
Ein RTT von 40-60 ms, auch durch VPN, ist schlimmer als ISDN. Was für eine üble Anbindung ist das?
Was für ein VPN? Was für Router auf den beiden Seiten?
Welche OS Versionen für den SMB Test auf beiden Seiten? (Winver auf Client Seite bitte)
Welche SMB Version war es?
Hast du mit Namen oder mit direkt \\ipv4\share gearbeitet?
Ist DFS-N, oder gar DFS-R im Spiel?
War "Offlineordner" aktiv? Da gibt es übrigens einen Bug in Windows 10 20h* bis inlk. 22h1 dass dies bei bestimmten Konstellationen aktiv ist obwohl es auf dem Fileserver für dieses Share deaktiviert ist.
Sind von VPN vielleicht bestimmte Ports blockiert so das MS hier auf ein Fallback zurückgreifen muss, z.B.: NetBios Ports 137-139 statt Port 445? Oder bestimmte ports bewusst ausgebremst? Letzteres geht übrigens auch auf dem Client oder Server mit den Windows eingebauten Net-QoS Regeln: Bei bestimmten Ziel-IPs und Ports kannst du geziehlt und sehr genau abbremsen.
Ist ipv6 beim VPN mit im Spiel oder rein ipv4? <- Sollte keine Einfluss haben, hatte aber zwei Fälle wo ipv4 über den VPN ging, aber ipv6 direkt, echt skurril was dann rauskommt.

Was dein Autotuning für Durchsatz oder Latenz betrifft: Stimmt, normalerweise muss man da nicht eingreifen, da behindern starre Vorgaben in der Registry eher.

[GilBates]

eigentlich nicht. von Windows Share auf Windows Share im Netzwerk, das geht ruckzuck.
Linux kann das ja auch, aber dann wird langsam.
weil die Unterstützung für SMB nicht so gut ist.
obwohl... Samba.
aber es ist ein deutlicher Unterschied, ob man von Linux aus auf Windows Share kopiert als von Windows aus.

Bei Windows-Windows erscheint die Datei fast sofort, bei Linux-Windows tröpfelt es behäbig rein.
zumindest im Firmennetz.
da gibs allerdings kein Windows 11

[Neuro-Chef]

/mecki78 schrieb:
> Windows kopiert immer langsam über Netzwerk, egal in welcher Version, auch
> dann wenn es da neues SMB verwendet, weil SMB an sich einfach langsam ist.
> Außerdem kommt SMB nicht mit Latenzen zurecht . Sobald man damit über einen
> Brigde oder ein VPN auf Daten zugreift, bricht die Performance komplett ein
> und dann ist so ziemlich alles andere schneller, das man sonst dafür nehmen
> könnte.
Jupp. Im Home Office bekomme ich an guten Tagen bis zu sagenhafte ~10 Mbit/s, wenn ich mit Linux über VPN was vom Windows fileshare ziehe. Über HTTP oder SSH bekomme ich locker 130 Mbit/s da durch.

¯\_(ツ)_/¯

» Niemand ist vollkommen, aber irre sind ganz sicher viele. « – Vollkommen Irrer ಠ_ಠ

(war mal) Verifizierter Top 500 Poster!

[JouMxyzptlk]

Bei Samba muss man genau schauen dass wenigsten SMB2 genutzt wird, SMB3 ist zu empfehlen. Mit SMB1 ist es wirklich sehr träge, da sah ich oft bei 30 bis 40 MB/s das Limit. Bei den heutigen stärkeren CPUs wird es wohl besser sein, aber immer noch weit unter dem was die Leitung hergibt.
Diese SMB Performance-Geschichte hat mich auch dazu gebracht den Linux Fileserver zu knicken und durch Server 2008 R2 zu ersetzen. Auf gleicher Hardware über 100 MB/s statt bis zu 40 MB/s, ein ganz anderes Performancelevel. Software RAID, Verschlüsselung und gut funktionierende Snapshots obendrein. Mit 2012 R2 Umstellung auf Storage Spaces, und noch gut funktionierende Deduplizierung mit drauf.
Bis jetzt fehlt immer noch folgende Kombination in Linux als ein Paket welches seit Server 2012 einfach so tut: Software-RAID + Verschlüsselung + Snapshots (Shadowcopy) + Offline-Background-Deduplizierung + Storage Tiering. Da reichen schon 8 GB RAM, auch bei Server 2022 mit GUI-nicht-Core installation. Im Firmenumfeld kommen noch viel bessere ACL, also Datei und Verzeichniszugriffsrechte, oben drauf. Das alte Unix-Rechteschema funktioniert da nicht mehr, es muss immer ein extended Schema darübergepfropft werden.
Mit Server 2022 kam noch SMB-Kompression dazu, wobei das weniger wichtig ist da die Platten bei mir das Limit sind. Die anderen groß angepriesenen Features bei Server 2022 sind solala, wie zum Beispiel dieser StorageBusCache, welcher an den gleichen komischen Limitierungen leidet wie "Storage Spaces Direct". Nicht verwechseln mit den oben genannten "Storage Spaces". Microsoft hat da zwei irgendwie ähnliche parallele Entwicklungszweige welche nicht viel gemeinsam haben.



1 mal bearbeitet, zuletzt am 11.03.23 00:46 durch JouMxyzptlk.