Re: Samba und lahme Performance von kleinen Files bei OS/X

On Thu, Nov 17, 2005 at 01:19:49AM +0100, Philipp Maihoefer wrote:
>
> Stefan Held wrote:
> >
> > socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=16384
> >SO_SNDBUF=16384
>
> Hey!
>
> Bis vor einer Woche habe ich auch noch genau vor dem gleichen Rätsel
> gestanden und habe mir das Hirn zermatert, warum ich für 1 MB 3 Std
> brauche :) Über scp ging das kopieren natürlich schnell, also musste es
> ja Samba liegen :)

Nicht zwingend - der Kompressionsoverhead kann durchaus Netzwerk-
probleme verbergen, was ich in der Praxis auch schon oft gesehen habe.

> Bis ich dann in den "Samba Performance HowTos", auf die auch innerhalb
> der smb.conf verwiesen wird gelesen habe was denn der SND und der RCV
> Buffer so genau anstellen.
>
> Offensichtlich ist Windows der Buffer mehr oder weniger egal, denn
> obwohl ich Buffer eingestellt hatte also bei mir die Zeile so aus sah:
>
> socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
>
> (natürlich mit anderen werten, ich glaube irgendwas mit 8000 stand da drin)
>
> Ging der Download, und der Upload sowieso, normal schnell von statten.
>
> Unter Mac OS/X hatte ich dann die bereits erwähnten Performance einbrüche.
>
> Da in der Zeile über den socket options sowas steht wie "auf Linux
> Rechner haben sich die Befehle SO_RCVBUF=xx und SO_SNDBUF=xx als
> Performance steigernd herausgestellt" dachte ich mir sowas wie "hm, du
> hast kein Linux also mal raus damit".
>
> Und TADA! es lief wieder wie geschmiert.

Kurz gesagt, du hast für das Problem in dem Mac Zusammenspiel nur noch
TCP_NODELAY drin?

> Nun stellen sich mir persönlich zwei Fragen:
>
> a) wer macht da irgendwas anders das Linux, das FreeBSD oder gar doch
> das Windows?

Wie ich schon sagte - die Window Geschichte ist nur im Zusammenspiel
mit Packetverlusten von Bedeutung.
Vereinfacht gesagt regelt das die ausstehende Datenmenge auf dem
Netzwerk, es kann bei Packetverlusten passieren, dass das ganze Window
neu übertragen werden muss.

> b) Wozu ist IPTOS_LOWDELAY sinnvoll?

Das ist ein IP-Type-of-Service Feld und wird von einigen Switchen
und manchmal auch Routern zur Priorisierung der Packete akzeptiert.
Während heutige 08/15 Switche das default machen, muss man das auf
Routern in der Regel explizit aktivieren.
Wenn es anwendung finded hat das genauso wie TCP_NODELAY Einfluss
auf die Latenzzeit einer Übertragung.
TCP_NODELAY bewirkt meheres, kurz gesagt sorgt es dafür, das
kleine Datenmengen, die im Sendebuffer stehen sofort aufs Netz gehen
und nicht gewartet wird, bis mehr Daten gesended werden sollen,
damit man die Daten zu größeren Packeten zusammenfassen kann.
Ebenso sorgt es dafür, dass sofort ein Ack dazu kommt und nicht
erst, wenn sowieso was gesended werden muss.
Details dazu, sowie den Windows liest man am besten im Stevens nach.

Nebenbei - die Einstellungen müsste man eigendlich auf den Sockets
beider Seiten machen, da es in der Regel um Round-Trip Zeiten geht,
die sich aus der Sendezeit des Senders und der Ack-Reaktionszeit der
Gegenstelle zusammensetzt.

Da die Window Einstellung keine Bedeutung hat geht es offensichtlich
nur um Latenzzeiten.
In dem Fall wird es doch sehr wahrscheinlich eine ineffiziente
Implementierung sein, da möglicherweise Transaktionen nicht
gleichzeitig aufgesetzt werden.
Da das mit Windows als Server offensichtlich nicht auftritt kann es
eigendlich nur Absicht sein, dass mit Samba kein Interleaving
verwended wird.
Evtl sollte man mal die Parameter beim Mac prüfen, ob man das forcieren
kann - der Samba ist jedenfalls nur Slave, der führt aus was im
aufgetragen wird - wenn das nacheinander passiert hat er keine Chance
was zu verbessern.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(at)bwct.de                                  info(at)bwct.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message