ich benutze hier einige Sambafreigaben auf einer “Managed Node”. Clients sind Kubuntu/Ubuntu 24.04 LTS. Alles 10Gbit. Freigaben (NFS und Samba) werden automatisch über Pammount eingebunden. Das funktioniert grundsätzlich auch. Aber ich habe folgendes Netzwerk Performancethema beobachtet beim Kopieren/Verschieben von Dateien:
Samba → Samba ~ 300MB/s
Samba → NFS ~600MB/s
NFS → Samba ~ 600MB/s
NFS → NFS ~ 600MB/s
Es handelt sich immer um die gleiche VM wo die Daten liegen und die gleiche physische Storage.
Wie man sieht, schaffe ich von einer Sambafreigabe auf die andere immer nur ca. die Hälfte, wobei das nach einer gewissen Zeit auch noch etwas absinkt. Sobald ein anderes Protokoll wie NFS darin beteiligt ist, funktioniert das um Längen besser. NFS verwende ich nur für die Freigaben die keine Authentifizierung benötigen.
Ich würde ja NFS für alle Freigaben verwenden, aber die Authentifizierung via Kerberos scheint von UCS nicht offiziell supportet zu sein. Zumindest konnte ich im Handbuch darüber nichts finden. Daher ergibt sich meine Frage zu Samba:
Muss da unter Samba noch etwas optimiert werden, damit man die volle Geschwindigkeit bekommt?
Moin @boospy, imho werden beim Test ein wenig Äpfel mit Birnen verglichen:
Linux NFS-Server (nfsd) und Linux-NFS-Client laufen im Kernel: geringere CPU-Overhead bei großen sequentiellen Transfers, besseres Readahead/Write-Back-Verhalten, effizientere Nutzung von sendfile/splice.
SMB-Server (smbd) läuft klassisch als Userland-Daemon; das bedeutet mehr Kontextwechsel zwischen Kernel ↔ Userspace beim Datenpfad als bei einem Kernel-basierten nfsd.
Kurz: Bei NFS ist das Protokoll einfacher, weniger „chatty“, und die Implementierung im Kernel deutlich effizienter. Also für Deine Tests:
Test NFS → Samba oder Samba → NFS: Hier wird eine Seite vom Kernel (NFS) und die andere über Samba bedient; besser parallelisierbar, weniger SMB-Overhead.
Test NFS → NFS: Komplett im Kernel (600 MB/s ist für 10G realistisch).
Erwartungshaltung: Aus meiner Erfahrung ist ~50% der NFS-Geschwindigkeit typisch, und 300–350 MB/s ist für “Samba → Samba” über 10G auch sehr normal. Mit Tuning kannst du sicher verbessern, aber nicht das NFS-Niveau erreichen.
Was Du mal checken kannst ist SMB-Signing, das halbiert oft den Durchsatz, speziell unter Linux-Clients. (Sicherheitsrelevante Änderung, also bitte nur im vertrauenswürdigen LAN!) In der Freigabe oder global:
server signing = disabled
client signing = disabled
Ansonsten: Jeder SMB-Stream erzeugt eigene Worker, das geht mächtig gewaltig auf die CPU. Daher schau beim Test auch mal auf die CPU Auslastung: Geht diese sehr spürbar beim Test hoch, wird VM-CPU schnell zum Bottleneck. Mehr vCPUs zuweisen hilft oft spürbar.
Serverseitiges Copy-Offload ist auch noch eine Sache, aber das fange ich jezt nicht an: Für alles weitere an Tuning ist es besser Dein Setup und config besser zu kennen, ansonsten sind alle weiteren Hinweise mehr so von der Qualität “Glaskugel”.
Folgend aus meinem cheat-cheat kopiert, als Hilfe zur Ermittlung ob CPU, Netzwerk oder Storage limitieren:
Reale sequenzielle Storage-Performance (Server-VM) als baseline. Ohne das zu kennen sind alle weiteren tests wertlos. Zielwert: mindestens 600 MB/s, besser 700–900 MB/s, je nach Storage. Kannst Du easy mit dd machen. (dd if=/dev/zero of=ddtest bs=4M count=1500 oflag=direct und dd if=ddtest of=/dev/null bs=4M iflag=direct)
Netzwerk als baseline: *Zielwert: 8–9,5 Gbit/s, also 900–1100 MB/s. Wenn iperf kleiner 6 Gbit/s liefert dann bist Du am Netzwerk limit (NIC/VM-virtio/vSwitch/vCPU/whatever). (server: iperf3 -s, client: iperf3 -c <server-IP> -P 8 -t 20)
CPU-Analyse auf dem Samba-Server während Kopie: pidstat -u -p $(pidof smbd) 1oder auch top -H -p $(pidof smbd). Siehst Du 1 SMB-Thread mit 100 % Last → CPU-Bottleneck. (SMB ist pro File-Stream oft single-threaded) Mehrere Threads je smbd-Prozess mit hoher Last → mehrere Streams laufen parallel. Wenn ein Thread auf 100 % hängt: Limit gefunden!.
I/O-Analyse auf dem Samba-Server während Kopie: macht Samba unnötige Syncs/Locks? (server: iotop -oPa) Wenn smbd ständig D (uninterruptible I/O) zeigt oder die I/O-wait hoch ist dann limitiert Storage/FS-Locking oder ein Samba-VFS-Modul.
Samba-Server config: VFS-Module geladen? (server: testparm -s | grep "vfs objects") Module wie vfs_fruit, streams_xattr, recycle oder acl_xattr können massiv bremsen. Schalte ab was Du nicht benötigst.
Samba-Client: Ist Signierung an? (grep Signing /proc/fs/cifs/DebugData) Wenn ja → Doppelte CPU → 300 MB/s typisch.
Server-Side Copy (SMB3 Offload - Optional - aber aufschlussreich) Wiederhole den Test mit einem Windows-Client, kopiere dieselbe Datei Samba → Samba. Wenn du plötzlich >600 MB/s bekommst: server-side copy funktioniert, Linux-Clients fordern sie jedoch nicht an. Linux-Tools wie cp, rsync, mv nutzen SMB-Offload nicht. Damit erklärt sich auch das NFS gewinnt; nicht weil weniger Netzwerk, sondern wegen Kernel-IO-Pfad.
Hallo @lutz.willek und vielen Dank für deine detaillierte Zusammenfassung. Ich habe einige Tests gemacht und mich damit beschäftigt. Und ja du hast leider Recht. der Overhead bei Samba ist wirklich sehr hoch im Gegensatz zu NFS. Bei SMB braucht die eine VM eigentlich die ganze CPU der Node. Wobei ich sagen muss, dass es hier nicht nur an Samba liegt. Die Storage darunter ist ZFS, das brauch auch sehr viel Ressourcen.
Ich hab einige FIOtests durch geführt. Hier ist einer davon:
Da komme ich auf ~640MB/s. Ist ganz gut. Wobei ich ja nie viel kleine, sondern eher große Files kopiere.
Iperf ist bei fast 9Gbit/s.
Default ist das wohl nicht. Ist hier nicht aktiv.
Toll… Habs mit Windows Server 2022 getestet. Dort geht es wesentlich besser.
Ja, die ACLs sind aktiviert. Aber glaub das machts nicht fett. Das meiste Thema ist wohl full_audit, das brauche ich zum Scan auf z.B. Cryptotrojaner. Funktioniert recht zuverlässig, aber braucht I/O.
Ich werde mal ein wenig umbauen und ein zusätzliches NFS-Laufwerk für spezielle Fälle erstellen. Ist, glaube ich ein guter Kompromiss.
Server-Side Copy via SMB3 (“SMB3 Copy Offload”, FSCTL_SRV_COPYCHUNK) funktioniert nur wenn Server und Client es unterstützt. Samba unterstützt Copy-Chunk seit Samba 4.3 (also seit Jahren). Linux SMB-Client (mount.cifs / SMB3 Kernel Client) muss Server-Side Copy anfordern.
Bevor Du das Samba Setup weg wirfst schaue Dir bitte mal die Client-Seite genauer an. Damit es genutzt wird, musst du SMB3 verwenden:
mount -t cifs //server/share /mnt/smb -o vers=3.1.1,username=...
Es wird verwendet, wenn:
Quelle und Ziel auf demselben Share liegen
Der Client per SMB3 verbunden ist
Die Datei nicht gesperrt ist
Der Copy-Befehl “copychunkfähig” ist
Wie testen ob SMB3 Offload aktiv ist
Kopiere innerhalb des Share:
cp /mnt/smb/largefile.iso /mnt/smb/copy.iso
Falls Server-Side Copy funktioniert:
CPU-Last auf dem Client: fast 0 %
Netzwerktraffic: quasi 0 (überwachbar mit iftop, nload)
Geschwindigkeit: So schnell wie das Backend-FS des Servers es erlaubt, bei Dir also so um die 600 MB/s.
Grenzen:
Der Linux SMB3-Client führt cp nicht als Copy-Chunk aus, wenn Quelle und Ziel in verschiedenen SMB-Mounts liegen, auch wenn es der gleiche Server ist.
RSYNC über SMB nutzt kein Offload
mc, cp --reflink, cat, dd benutzen nicht CopyChunk, nur normale Reads/Writes
GNOME/KDE Datei-Manager: Kommt auf die Version an.