Samba langsam

[ChoMar]

So, ich kram mal den Uralt-Thread wieder raus, weil ich die samba-config von hier noch genau so (oder zumindest fast) einsetze.

Mein Problem ist aber ein neues:
Mit neuer Hardware (NAS-Seitig) habe ich es unter Win Vista geschafft, mich mit den lese- und schreibraten nahe am theoretischen Optimum vom Gigabit-Netzwerk und den HDDs (Raid5) zu bewegen: 80-110 MB schreibend und lesend (lesend ist bei 100+). Das ganze bei einer großen datei, aber kleine gingen immernoch enorm fix.
Jetzt hab ich meinen Hauptrechner von Vista auf Win 7 aktualisiert (zusammen mit ner SSD) und auf einmal wirds komisch.
Die Schreibraten sind immernoch akzeptabel mit 60-80, die Leseraten liegen jedoch DARUNTER. Bei kleinen Dateien bricht das ganze auch mal komplett auf 10-20 ein. Vor allem letzteres ist leicht störend.

Gibt es bei Win7 irgend was neues, was ich in betracht ziehen sollte? Vor allem, warum ist das ganze Lesend langsamer als Schreibend? Das ist neu...

[CyberSun]

Hallo Zusammen,

jetzt schreib ich doch mal in diesen Thread mein Problem rein, da ich sonst nirgends was dazu finde.
Und zwar hatte ich auf dem selben Server wie jetzt auch ein aktuelles Debian Lenny mit Samba. Von einem Vista Rechner konnte ich mit 50-70MB/sek schreiben und lesen. Jetzt hab ich den Server komplett neu installiert (kein Update) auf Debian Squeeze mit Samba 3.5.. und jetzt hab ich nur noch schreibraten von 10-13MB/sek und leseraten von 20-25MB/sek. Das ist definitiv zu wenig!

An was liegen die extrem schlechten Schreib/Leseraten beim Debian Squeeze und Samba 3.5?

[Six]

Bzgl. MS Windows 7 und Samba 3.5+:
Der Network-Stack von 7 und Vista ist identisch. Aber in MS Windows 7 (zumindest in Pro und besser) ist Frame-Autotuning und RDC (das ist eine Art Netzwerkkompression) angeschaltet. Beides ist in reinen SMB2 Netzen sehr nützlich, kann aber negative Auswirkungen auf die Kommunikation mit Software haben, die noch auf SMB1 setzt. So weit ich weiß, ist Samba 3.5.x eine SMB1 Software.

Jedenfalls kann man das in MS Windows 7 abstellen. Dazu eine Eingabeaufforderung mit Admin-Rechten starten, dann:

Code: Alles auswählen

netsh interface tcp set global autotuning=disabled
ocsetup MSRDC-Infrastructure /uninstall

Das sollte es sein.

Bzgl. lahmer Samba 3.5.
Die hier besprochenen Tips greifen auch für Samba in Squeeze. Experimentieren musst du aber selber.

[Zenturio19]

An was liegen die extrem schlechten Schreib/Leseraten beim Debian Squeeze und Samba 3.5?

Ich kann das nicht bestätigen. Ich hab' die letzten 14 Tage einen Rechner mit Debian 6.01 aufgesetzt, Samba installiert (welche Version das jetzt aktuell bzw. standardmäßig war - keine Ahnung). Von einem Win7-Rechner hab' ich da Daten (große Dateien) mit 70-90 MB/sek herum geschaufelt.

Liegt's vielleicht bei Dir am Treiber der NIC?

LG

[CyberSun]

Bzgl. MS Windows 7 und Samba 3.5+:
Der Network-Stack von 7 und Vista ist identisch. Aber in MS Windows 7 (zumindest in Pro und besser) ist Frame-Autotuning und RDC (das ist eine Art Netzwerkkompression) angeschaltet. Beides ist in reinen SMB2 Netzen sehr nützlich, kann aber negative Auswirkungen auf die Kommunikation mit Software haben, die noch auf SMB1 setzt. So weit ich weiß, ist Samba 3.5.x eine SMB1 Software.

Jedenfalls kann man das in MS Windows 7 abstellen. Dazu eine Eingabeaufforderung mit Admin-Rechten starten, dann:

Code: Alles auswählen

netsh interface tcp set global autotuning=disabled
ocsetup MSRDC-Infrastructure /uninstall

Das sollte es sein.

Bzgl. lahmer Samba 3.5.
Die hier besprochenen Tips greifen auch für Samba in Squeeze. Experimentieren musst du aber selber.

Danke für den Tip, hab ich auch gleich mal ausprobiert. Hat auch etwas geholfen. Schreibrate ist jetzt bei großen Datein bei 14-20MB/sek. Nur komm ich damit immer bei weitem nicht auf den damaligen Wert.
Hardware ist soweit gleich geblieben, und die Netzwerkdatentransver zwischen zwei Linuxrechnern liegt bei guten 100MB/sek (ohne Samba).
Beim Kopieren von Win7/Vista zum Sambarechner blinkt auch nur sehr selten das Netzwerklicht am Switch und die Festplatten sind auch nur alle 2-3 Sekunden am arbeiten. CPU Auslastung liegt auch im normalem bereich (15-20%).

Kann die extrem langsame Geschwindigkeit auch von einer fehlerhaften smb.conf kommen? Hab sie unter GADMIN-SAMBA und SWAT erstellt/configuriert.

Werde heute Abend mal eine ältere Live-Distri von Ubuntu mit Samba 3.2 testen, mal schaun obs besser ist.

@Zenturio19
Kannst du vielleicht deine SMB.CONF hier bitte posten, dann test ichs mal bei mir. Denke der rest ist bei dir alles standard nach ner frischen Installation.
Treiberprobleme denke ich nicht, dass ich die habe. Ging ja mit der Lenny distri ja schon super und ist nen standard AMD64 Mobo von Asus (Sokel 939). Oder wie kann ich erkennen, ob und wo da was nicht stimmt?

[Zenturio19]

@Zenturio19, Kannst du vielleicht deine SMB.CONF hier bitte posten, dann test ichs mal bei mir. De

Ich hab' Dir meine smb.conf temproär hier her gestellt - ich bin kein Profi, ob es optimal ist, weiß ich nicht, funzt aber (hab' für Verbesserungsvorschäge auch ein offenes Ohr).

LG

[ChoMar]

Meine smb.conf gibts übrigens weiter vorne, die ist an sich ziemlich gut getuned...
ABER...

netsh interface tcp set global autotuning=disabled
ocsetup MSRDC-Infrastructure /uninstall

hat nichts gebracht.
Aber ich habe das Problem näher eingegrenzt;
Teilweise ist das ganze echt schnell, 100 MB/s und mehr.

Manchmal bricht es aber auch völlig ein, 40 und weniger.
Trifft so auf beide Richtungen zu.
Jemand ne ahnung, worauf ich evtl. bei Wireshark oder so achten könnte, um dem ganzen auf die Spur zu kommen?

[Six]

Meine smb.conf gibts übrigens weiter vorne, die ist an sich ziemlich gut getuned...

SMB Geschwindigkeitsoptimierung ist aber keine one-size-fits-all Angelegenheit. Was bei dem einen gut funktioniert, reißt bei jemand anderem die Performance in den Keller. Da muss man an seinem individuellen Setup experimentieren.

ABER...

netsh interface tcp set global autotuning=disabled
ocsetup MSRDC-Infrastructure /uninstall

hat nichts gebracht.
Aber ich habe das Problem näher eingegrenzt;
Teilweise ist das ganze echt schnell, 100 MB/s und mehr.

Manchmal bricht es aber auch völlig ein, 40 und weniger.
Trifft so auf beide Richtungen zu.
Jemand ne ahnung, worauf ich evtl. bei Wireshark oder so achten könnte, um dem ganzen auf die Spur zu kommen?

Vielleicht ein Hardwareproblem? Viel Action auf Broadcast bedeutet, dass vermutlich ein NIC im LAN im Eimer ist. Viele CRCs bedeutet, dass ein Kabel nicht zuverlässig überträgt. Zwinge SND und RCV Link Speed und Duplex auf und fahre weiter runter bzw rauf, bis die Probleme verschwinden bzw. auftreten.

[ChoMar]

SMB Geschwindigkeitsoptimierung ist aber keine one-size-fits-all Angelegenheit.

Ich weiß, die damals hab ich ja mit dir zusammen erarbeitet. Die Socket Options hab ich seit damals auch wieder verändert (SO_SNDBUF, SO_RCVBUF und max xmit), aber es stehen ja auch comments drin.
Und im gegensatz zu Zenturios Config hab ich die Socket Options drin, dafür hat er ne anspruchsvollere Authentifizierung *g*

Zwinge SND und RCV Link Speed und Duplex auf und fahre weiter runter bzw rauf, bis die Probleme verschwinden bzw. auftreten.

Duplex könnt ich experimentieren, aber sobald ich ihn runter auf 100 MBit bringe bin ich eh weit unterhalb des Problembereichs.
Aber ich werd mir die Tage noch mal alles im Wireshark genauer anschauen. Braucht halt nur etwas zeit.

[ChoMar]

Da ich den Thread als "backup" meiner Standartkonfig habe erlaube ich mir mal, ihn wieder auszugraben um einige änderungen am Initscript (/etc/init.d/samba) von Samba vorzustellen, die mir scheinbar helfen.
Vieleicht kann sie ja jemand näher erklären, cih weiß nämlich nur ungefähr, was das macht. Auf jeden fall finde ich das diskussionswürdig (modifikationen bei start-stop-deamon):

Code: Alles auswählen

start)
                log_daemon_msg "Starting Samba daemons"
                # Make sure we have our PIDDIR, even if it's on a tmpfs
                install -o root -g root -m 755 -d $PIDDIR

                if [ -n `which testparm` ]
                then
                        NMBD_DISABLED=`testparm -s --parameter-name='disable netbios' 2>/dev/null`
                fi
                if [ "$NMBD_DISABLED" != 'Yes' ]; then
                        log_progress_msg "nmbd"
                        if ! start-stop-daemon --start --nicelevel -9 --procsched rr:50 --iosched real-time:3 --quiet --oknodo --exec /usr/sbin/nmbd -- -D
                        then
                                log_end_msg 1
                                exit 1
                        fi
                fi

                if [ "$RUN_MODE" != "inetd" ]; then
                        log_progress_msg "smbd"
                        if ! start-stop-daemon --nicelevel -9 --procsched rr:50 --iosched real-time:3 --quiet --oknodo --exec /usr/sbin/smbd -- -D; then
                                log_end_msg 1
                                exit 1
                        fi
                fi

                log_end_msg 0

--nicelevel -9: setzt den Prozess auf Priorität -9, was Samba mehr CPU geben sollte
--procsched rr:50: Setzt den Prozessscheduler auf RoundRobin und die Priorität auf 50 (typ:priorität). Aber da hörts dann auf. Werte mit Trial and Error ermittelt. fifo währe eine andere option, erwies sich aber als schädlich. Getestet habe ich jeweils (rr und fifo) 30,50 und 80. bei 50 hatte ich die meiste leistung und das system lief zuverlässig
--iosched real-time:3 ändert das verhalten des ioschedulers. (Klasse:Priorität) eine Priorität von zwei hat dazu geführt, das samba nicht mehr erreichbar war. eine von über 4 auch. Ich weiß ehrlich gesagt nicht mal ob die priorität rückwärts oder vorwärts läuft.

eigentlich sollte es reichen,d as ganze nur für den smbd und nicht den nmbd zu machen

Gefunden habe ich das ganze hier
http://man.cx/start-stop-daemon%288%29/de

Achtung: Die Änderungen greiffen auf jeden fall performance von anderen Anwendungen ab.

Vieleicht kann jemand die Werte genauer erklären oder so?

[Six]

Mit diesen Einstellungen habe ich noch nie gespielt.

[ChoMar]

Yeah, und so wirklich gut dokumentiert scheint das ganze nicht zu sein...
Ich werd damit noch ne runde rumspielen, weil es scheint doch merklich auswirkungen zu haben, vor allem wenn noch andere Sachen laufen...
Hier wird ein bisschen von dem zeug erklärt: http://www.askapache.com/optimize/optim ... onice.html

[ChoMar]

Ich möchte mich einfach mal bei meinem vergangenen Selbst für diesen Thread bedanken.
Es ist mir gelungen, mein HeimNAS sehr Performant wieder aufzusetzen. (mal schauen, was die nächsten Tage bringen)
Und vielen Dank an das Debianforum, das dieser alte Thread noch existierte und gut zu finden war.