Samba Performanz [Kommentar]

Wie ich vor einer Weile festgestellt habe, ist Samba bei Übertragungen von einzelnen Dateien eben auch auf einen Prozessorkern beschränkt. Gerade bei NAS Geräten, die in der Regel nur wenig Prozessorpower pro Kern haben ist das eher problematisch. Bei meinem Odroid H2+ heißt das im Klartext, dass nur 600 bis 1000 MBit/s (darunter befindet sich ein btrfs Dateisystem mit Komprimierung, die Geschwindigkeit steigert sich aber nicht, wenn ich das Dateisystem ohne Komprimierung einhänge, die Daten die übertragen werden sind aber bereits komprimiert, insofern sollte die Btrfs komprimierung sich auch von selbst deaktivieren) genutzt werden können, wenn keine parallelen Übertragungen stattfinden, sondern nur eine Datei geschrieben wird.

FTP als Alternative?

Als Alternative habe ich somit FTP getestet und komme auf 1,8 GBit/s. Da FTP bei einem NAS aber nicht so wirklich praktisch / komfortabel ist und an vielen stellen auch nicht unterstützt wird (z.B. Multimediageräte wie SAT Receiver), wäre es natürlich schöner, wenn man SMB beschleunigen könnte.

Somit bin ich auf diesen Artikel bei heise gestoßen. Dummerweise hatte ich auf meinem Ubuntu 20.04 noch eine Version kleiner als 4.12 installiert (Randnotz, der heise Artikel geht vor anderthalb Jahren noch von einer “schnellen” Verbreitung aus). Somit blieben zwei Möglichkeiten. Variante 1 ist selbst Samba zu kompilieren (dafür muss man eine Menge Pakete installieren – in meinem Fall rund 140 Pakete) oder eben eine aktuellere Ubuntu Version ohne long term support.

Mein erster Versuch war also der make from scratch Ansatz.

Seltsame Fehler

Das hat zwar funktioniert aber nachher hat der samba Service den Status:

sys_path_to_bdev() failed for path [.]

ausgegeben. Das kam mir seltsam vor. Somit bin ich zu einem vorherigen Stand zurückgekehrt und habe mich entschlossen auf eine neuere Ubuntu Version zu wechseln. Die Kurzform ist: Der Fehler besteht in allen neueren Samba Versionen (möglicherweise nur, wenn man btrfs als Dateisystem nutzt). Es gibt zwar Ansätze das zu beheben (zusätzliche Mountpunkte in der fstab datei) aber auf solche Bastelansätze nur für Samba kann ich auch verzichten.

Performanz Tuning

Also habe ich beschlossen den Fehler zu ignorieren. Wenn er quasi jeden Nutzer betrifft, dann besteht ja die Hoffnung, dass sich irgendwann mal jemand darum kümmert. Wobei die Chancen wohl nicht so riesig sind, wenn der Fehler in Samba schon lange vorhanden ist.

Somit habe ich Neugierig einen neuen Performanztest gemacht und dabei festgestellt, dass ich nichts von den ach so tollen Geschwindigkeitssteigerungen (verringerter Overhead durch Kernel Support via io_uring und Nutzung der schnelleren Verschlüsselung durch Gnutls) lt. Heise Bericht merke.

Wenn man sich den Heise Bericht genauer durchliest, hat man aber auch eher den Eindruck, als wenn eine Pressemitteilung abgeschrieben wurde. Es wird zwar io_uring erwähnt aber nicht, dass das z.B. extra konfiguriert werden muss oder wie.

In meinem Fall mit btrfs und io_uring z.B. so:

[backup]
writeable = yes
path = /data/backup
vfs objects = btrfs, io_uring
btrfs: manipulate snapshots = no
valid users = xyz
writeable = yes
write list = xyz,@xyz
# smb encrypt = required
smb encrypt = desired
force user = xyz

Spezielle Netzwerkkarten für Multikernnutzung oder direkten Speicherzugriff

Eine Alternative zu obigem Ansatz, der bei mir leider nichts gebracht hat, ist die Nutzung von speziellen Netzwerkkarten, die RSS oder RDMA nutzen (die meisten Adapter können das nicht bzw. die Intel Chips wie der 225V können es wohl aber es wird bewusst nicht unterstützt). Somit bleiben z.B. die AQtion Chips übrig, die aber kaum verbaut werden. RSS funktioniert auch nur, wenn sich die entsprechenden Chips beidseitig genutzt werden. Dabei wird die Kommunikation aufgeteilt und somit die Last auf mehrere Prozessorkerne verteilt. Allerdings auch für das Speichermedium. Gerade bei Festplatten hat das also auch Nachteile wegen den dadurch entstehenden verteilten Zugriffen und Kopfbewegungen.

Weitere Informationen siehe auch hier. Bei stärkerer Verbreitung (Linux Kernel 5.15) ggf. auch KSMBD. Der Ansatz hört sich vielversprechend an. Dabei zieht SMB in den Kernel um und soll dadurch schneller werden.

Fazit:

Wer denkt, dass heute Mehrkernnutzung eigentlich selbstverständlich ist, wird bei SMB mal wieder eines besseren belehrt. Es kommt in dem Fall auf einen Kern an. Erstaunlich finde ich, dass man im Netz so wenig Infos dafür findet. Jeder mit einem NAS > 1 GBit sollte damit Probleme haben, wenn SMB genutzt wird und gerade im Windows Kontext gibt es dazu keine echten Alternativen, die auf breiter Basis von vielen Geräten unterstützt werden. Bei Backupsoftware wird teilweise nicht mal FTP unterstützt, geschweige denn NFS oder andere Ansätze.

Erstaunlich finde ich bei solchen Themen immer, dass die kaum jemandem auffallen. Das ging mir damals bei Intel Prozessoren auch schon mal so (5930K und Single Core Last). Gefühlt kauft jeder die dickste Kiste aber ob es dann nachher auch Leistung bringt, prüft scheinbar fast keiner. 😉