[erledigt] debian 12: Samba upload von Windows Client langsam

[FBT]

Hallo @all

ich habe mir einen neuen File Home Server gebastelt - der alte ist doch schon etwas in die Jahre gekommen. Alles läuft soweit nur der Samba Server im debian bookworm macht mir Sorgen:

Ich erreiche von einem Windows Client (egal ob Win 7, Win 10 oder Win 11) nur einen Upload von etwa 40MB/s im Gigabit Lan.
Freigegeben ist ein share auf einer WD Red 6TB an SATA III angeschlossen (direkt am Mainboard).
Der downland vom Samba share liegt bei ca. 112MB/s - also völlig OK.

Der up/download über NFS share liegt bei etwa ~90MB/s - also auch im Rahmen.

Mein "alter" Fileserver mit einer AMD C60 CPU und debian squeeze! bietet ca, 90 MB/s Samba upload von einem Windows Client.
Mit debian 12 auch nur 40MB/s ...

Ich hatte bisher debian 11/12 i386 und x64 getestet - immer das selbe Verhalten. Auch mit anderer Hardware (mainboard, CPU, NIC)

Ich hatte Anfangs Windows 11 in Verdacht weil Redmont gerne am SMB Protokoll rumschraubt - aber das kann ich mittlerweile auch ausschließen.

Dann kam die Netzwerkarte dran: Intel I219-V - die machte in der Vergangenheit ja auch gerne Probleme unter Linux.
Aber auch eine andere Netzwerkkarte über PCIe angeschlossen oder bonding mit bond0 der beiden Adapter brachte keine Veränderung.


Am Ende gab ich einen samba share auf einer SATA SSD frei:
117MB/s up- und download! Also am oberen Limit im Gigabit LAN ....


Nun zu meiner Frage:
Wie kommt es zu dieser Drosselung beim Samba Upload auf eine Share der auf einer HDD liegt? Liegt es am Samba Server oder am kernel? (debian 12 am aktuellen Stand)
Die Schreibperformance auf die HDD liegt jenseits von 130MB/s (ext4) - mit dd getestet. Daran kann es also auch nicht liegen liegen.

Auch die restliche Hardware kann ich mittlerweile ausschließen. Die CPU langweilt sich auch beim upload - weit unter 10% Last. Auch das journal liefert keine brauchbaren Informationen und mir gehen langsam die Ideen aus.

[QT]

Hallo Fred, hab Dich am Avatar und Namen erkannt

Hast Du mal unterschiedliche SMB Protokollversionen getestet?

Was sagt 1 hdparm Test unter Debian 12 zum HDD Speed? Und wenn Du schon am Experimentieren bist, dann installiere doch mal Unstable für 1 Test und/oder alternativ ne andere Distro noch.

[FBT]

Ich dich am nick

ja, ich habe auch schon an den Samba Protokollen rumgespielt, aktuell sieht es so aus

Code: Alles auswählen

root@DHS02:~# grep protocol /etc/samba/smb.conf
        client min protocol = SMB2_02
        client max protocol = SMB3_11
        server min protocol = SMB2_02
        server max protocol = SMB3_11
root@DHS02:~#

hdparm is OK, es ist auch eine CMR Platte

Code: Alles auswählen

root@DHS02:~# hdparm -I /dev/sdb | grep Model
        Model Number:       WDC WD60EFRX-68MYMN1
root@DHS02:~# hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   8198 MB in  1.98 seconds = 4133.14 MB/sec
 Timing buffered disk reads: 540 MB in  3.00 seconds = 179.82 MB/sec
root@DHS02:~#

zum Vergleich die WD Red NAS SSD auf die ich mit 117MB/s vom Windows Client schreiben kann

Code: Alles auswählen

root@DHS02:~# hdparm -I /dev/sdc | grep Model
        Model Number:       WDC  WDS500G1R0B-68A4Z0
root@DHS02:~# hdparm -tT /dev/sdc

/dev/sdc:
 Timing cached reads:   8234 MB in  1.98 seconds = 4151.56 MB/sec
 Timing buffered disk reads: 1200 MB in  3.00 seconds = 399.39 MB/sec
root@DHS02:~#

Unter debian 11 das gleiche Problem

[FBT]

so, ich habe das mal mit Ubuntu 24.04.1 LTS gegen getestet

amd64 kernel: 6.8.0-47
Samba Version 4.19.5-Ubuntu

komplett gleiches Verhalten
Samba Upload vom Windows Client auf die WD Red 3,5": 40MB/s, auf die SSD 115MB/s

aktuell läuft wieder debian 12.7 i686 - aber auch mit amd64 das selbe Verhalten
i686 kernel: 6.1.0-26-686-pae
Samba Version: 4.17.12-Debian

lt. Websuche scheine ich der einzige zu sein, der das Problem hat oder darüber berichtet. Langsam habe ich die Hardware in Verdacht, obwohl da bis auf das NIC nichts exotisches dabei ist

Mainbaord: ASRock H110M-ITX, aktuellstes BIOS
Prozessor: Intel i3-6100T
LAN: Intel I219-V
RAM: 2x Crucial Ballistix Sport LT DIMM 4GB, DDR4-2400 getaktet mit 2133 MT/s

am alten Server, mit einem ASUS C60M1-I ITX Board, mit AMD C60 CPU (2x 1,1GHz), 4GB RAM und einer Intel PCIe Gbit LAN Karte mit 82574L Controller komme ich mit dem uralt debian 6 auf ca 90MB/s Samba upload auf eine WD RED 3,5", mit debian 12.7 aber auch nur auf 40MB/s, allerdings habe ich keine Neuintallation durchgeführt sondern einfach das boot device getauscht ...

[slu]

Schau mal auf dem Server mit smbstatus wie sich der Client verbindet, bei dem alten Debian war es sicher ein älterer SMB Standard.

Ansonsten kannst Du mal diese Punkte durchgehen, ob da ein sinnvoller dabei ist kann ich dir nicht sagen:
https://github.com/VolkanSah/optimize-Samba-settings

[MSfree]

Langsam habe ich die Hardware in Verdacht, obwohl da bis auf das NIC nichts exotisches dabei ist

Die NIC ist eine Wald-und-Wiesen-Intel-NIC, also nichts exotisches. Die hat auch bei mir nie irgendwelche Probleme unter Linux gehabt. Da dein i3-6100T die AES-Erweiterungen unterstützt, ist auch die aufwändigere Verschlüsselung, die SMB4 verwendet, keine Bremse.

Du schreibst ja oben, daß du auf die freigegebene SSD mit voller Geschwindigkeit schreiben kannst. Das Problem ist also deine WD-Red.

Ein Test mit dd auf die WD-Red ist sinnlos.Da wird nur die lineare Schreibgeschwindigkeit getestet, nicht jedoch der random access. Bei WD hätte ich zuerst mal SMR in Verdacht. WD hatte mal einige WD-Reds, ohne das bekannt zu geben, in SMR-Versionen (shingled magnetic recording) verkauft. SMR-Platte schreiben üblicherweise sehr schnell, solange man Daten nur einmalig in dann linear auf die Platte schreibt. Beim Überschreiben brechen die Teile aber teilweise dramatisch ein.

Ich würde dir empfehlen einfachmal testweise eine andere Platte einzubauen, von der du garantiert weißt, daß es keine SMR-Platte ist (z.B. eine 1TB-Platte). Oft hat man sowas ja noch irgendwo im Fundus liegen.

[FBT]

die WD Red sind CMR Platten und es treten auch sonst auch keine Performance Probleme auf. Schreiben über NFS Share auf die WD RED liegt ja auch im Rahmen. Die gut +50% Performance Verlust treten nur beim Schreiben auf den Samba Share auf.



im debian 12.7 mit Samba Version 4.17.12 verbinden sich die Windows Clients mit Protocoll SMB3_11

am alten sqeeze server mit samba Samba version 3.5.6 wird mir das Protocoll mit smbstatus gar nicht angezeigt, aber wie vermutet wird nur SMBv1 unterstützt, was ja mit ein Grund für das upgrade ist

Code: Alles auswählen

root@DHS02:~# nmap -p445 --script smb-protocols 192.168.178.9
Starting Nmap 7.93 ( https://nmap.org ) at 2024-10-27 09:53 CET
Nmap scan report for 192.168.178.9
Host is up (0.00040s latency).

PORT    STATE SERVICE
445/tcp open  microsoft-ds
MAC Address: xx:xx:xx:xx:xx:xx (Asustek Computer)

Host script results:
| smb-protocols:
|   dialects:
|_    NT LM 0.12 (SMBv1) [dangerous, but default]

Nmap done: 1 IP address (1 host up) scanned in 0.79 seconds
root@DHS02:~#

Sind ~40MB/s upload mit SMB3_11 "normal"? Was mich stutzig macht, dass das Schreiben auf eine SSD über Samba an die Grenzen von Gigabit LAN kommt und auf eine 3,5" HDD gerade mal 40% ankommen. Um ein Problem mit der Platte auszuschließen hatte ich auch unterschiedliche 3,5" und 2,5" Platten getestet - alles CMR Platten. bei ca. 40MB/s ist Schluss ...

[FBT]

ich habe zum Test nun auch ein paar GB Daten von der SSD auf die WD Red im Terminal mit pv kopiert, da wurden mir konstant ~92MB/s angezeigt, was die Performance beim Kopieren über einen NFS share in etwa entspricht. Das ist jetzt nicht gerade ein Top Wert aber OK.

Der Test mit den Samba max server Protokollen ergab folgendes

server max protocol = NT1: ~5MB/s
server max protocol = SM02_02: ~20MB/s

sehr spannend

[MSfree]

Der Test mit den Samba max server Protokollen ergab folgendes

server max protocol = NT1: ~5MB/s
server max protocol = SM02_02: ~20MB/s

sehr spannend

Wie hoch ist die CPU-Last beim Kopieren?
Wie schnell kannst du mit scp von einem anderen Rechner auf die i3-6100T-Kiste kopieren?

[FBT]

die CPU last liegt bei etwa 14% mit 800Mhz mit htop ausgelesen
Wobei ich die CPU Frequenz mit tlp auf 35% limitiert habe, um den Stromverbrauch zu reduzieren.

Es macht aber auch keinen Unterschied, wenn die CPU mit 100% läuft, die Last ist in etwa gleich hoch, der Disk I/O liegt bei etwa 40MB/s lt. htop

In der Zwischenzeit habe ich das auch mit einem Linux Desktop Client getestet. Das Schreiben über Cifs mount liegt auch bei etwa 40MB/s

mit scp komme ich auf 87MB/s

Code: Alles auswählen

fred@11TNHi3:~$ scp 2GB-testfile fred@192.168.178.2:/media/test
fred@192.168.178.2's password:
2GB-testfile                   100% 2000MB  87.1MB/s   00:22
fred@11TNHi3:~$

mit nfs und dd

Code: Alles auswählen

fred@11TNHi3:~$ sudo mount -t nfs -o rw,soft,nolock,async 192.168.178.2:/media/test /mnt
fred@11TNHi3:~$ dd if=/dev/zero of=/mnt/2GB-testfile bs=1M count=2000
2000+0 records in
2000+0 records out
2097152000 bytes (2,1 GB, 2,0 GiB) copied, 23,8986 s, 87,8 MB/s
fred@11TNHi3:~$

[habakug]

Hallo,

ist denn auf dem Samba-Server in der globalen Sektion ein

Code: Alles auswählen

server multi channel support = yes

gesetzt?
Hier [1] und hier [2] einige Hinweise.

Gruß, habakug

[1] https://github.com/VolkanSah/optimize-Samba-settings
[2] https://luka.manojlovic.net/2019/08/04/ ... -on-host2/

[MSfree]

Lies mal das hier:
https://www.reddit.com/r/OpenMediaVault ... &rdt=49588

Vor allem der Abschnitt hier scheint mir vielversprechend zu sein:

Code: Alles auswählen

write cache size = 2097152
min receivefile size = 16384
getwd cache = true

[rhHeini]

Ich denke mal da wirst Du mit so einer Festplatte nicht viel erreichen. Samba hat halt einen eigenen zusätzlichen Overhead was die Performance reduziert. Und Du siehst ausserdem den drastischen Unterschied zwischen einer SSD und einer Festplatte.

[FBT]

danke für die Inputs

@habakug

server multi channel support = yes war nicht gesetzt, brachte aber keine Veränderung

@MSfree

guter Hinweis, aber mit den zitierten Werten bricht die Performance auf 15MB/s ein
aber ich werde dem Ansatz mal folgen - vielleicht finde ich eine Schraube


@rhHeini

das ist auch meine Befürchtung ...



die global section meiner smb.conf sieht jetzt aktuell so aus, vielleicht fällt noch jemand etwas auf

Code: Alles auswählen

[global]
        workgroup = HOMENET
        server string = DHS02
        log file = /var/log/samba/%m
        load printers = no
        invalid users = root
        security = user
        map to guest = Bad Password
        create mask = 0775
        force create mode = 0775
        directory mask = 0775
        force directory mode = 0775
        case sensitive = Yes
        preferred master = no
        server role = standalone server
        server multi channel support = yes
        write cache size = 2097152
        min receivefile size = 16384
        getwd cache = true

prefered master ist aktuell noch der alte Server, deshalb ist der Wert "no"

[FBT]

@MSfree

Danke für den hint!



Ich habe jetzt diese Optionen in die global section eingefügt:

Code: Alles auswählen

        socket options = TCP_NODELAY IPTOS_THROUGHPUT SO_RCVBUF=131072 SO_SNDBUF=131072
        acl allow execute always = true
        acl map full control = yes
        deadtime = 60
        getwd cache = true
        strict sync = no
        sync always = no
        use sendfile = true

jetzt habe ich einen upload von etwa 90MB/s was der performance mit NFS und scp entspricht


Ich werde mal testen wie sich das im Alltag auswirkt, sync disablen gefällt mir nicht so gut

[MSfree]

jetzt habe ich einen upload von etwa 90MB/s ... sync disablen gefällt mir nicht so gut

Gut, dann hast du die Handbremse ja gefunden.

sync abzuschalten dürfte keine negativen Auswirkungen haben. Daten werden dann halt etwas länger im Cache gehalten und nicht jeder Datenblock sofort auf die Platte geschrieben. Bei schnellen SSDs fällt sync kaum auf, aber bei Festplatten kann das letztlich lahm werden.

Nur, wenn du genau in dem Moment zwischen Empfang der Daten und dem Schreiben auf die Platte einen Stromausfall hättest, wäre der Datenblock verloren. Aber Stromausfälle bekommt man in der Regel ja mit, so daß man den Datentransfer nach dem Reboot wieder starten kann.

[FBT]

ja, danke

ich werde noch aber ein wenig mit den Optionen spielen, aber grundsätzlich scheint es gelöst zu sein

Aber warum ich das nicht selbst gefunden habe? Hab mir in den letzten Tagen einen Wolf gesucht - aber offensichtlich mit den falschen Suchbegriffen

[MSfree]

Hab mir in den letzten Tagen einen Wolf gesucht - aber offensichtlich mit den falschen Suchbegriffen

Ist ja keine Schande
Ich habe nach samba performance problem gesucht
Englische Suchbegriffe führen einen meist besser zum Ziel.

[FBT]

Abschließend war nur ein Paramenter ausschlaggebend für den Performance Schub:

strict sync = no

alle anderen gesetzten Parameter hatten nur noch wenig Einfluß auf die Performance, das alleine brachte den upload auf den Samba share von ~40MB/s auf ~90MB/s

lt. https://www.samba.org/samba/docs/4.9/ma ... onf.5.html ist der default Wert für strict sync = yes

die anderen Parameter habe ich mal auf default gelassen


/etc/samba/smb.conf

Code: Alles auswählen

[global]
        .
        .
        .

#       --- performance optimizing ---
	## default: socket options = TCP_NODELAY 
        #socket options = TCP_NODELAY IPTOS_THROUGHPUT SO_RCVBUF=131072 SO_SNDBUF=131072
        
        ## default: acl allow execute always = no
        #acl allow execute always = true
        
        ## default: acl map full control = yes
        #acl map full control = yes
        
        ## default: deadtime = 0
        #deadtime = 60
        
        ## default: getwd cache = yes
        #getwd cache = yes
        
        ## default: min receivefile size = 0
        #min receivefile size = 16384
        
        ## default: strict sync = yes
        strict sync = no
        
        ## default: sync always = no
        #sync always = yes
        
        ## default: use sendfile = no
        #use sendfile = yes

Danke an alle die mitgeholfen haben!