[Anhang B] B.2 Samba-Tuning

B.2 Samba-Tuning

Nach diesen Worten wollen wir nun darüber reden, wie du ein bereits schnelles Netzwerkpaket nehmen und es noch schneller machen kannst.

Benchmarking ist eine obskure und ein wenig schwarze Kunst, aber das Niveau an nötiger Fachkenntnis für einfaches Performance-Tuning ist ziemlich niedrig. Weil des Sambaservers Ziel im Leben der Transfer von Dateien ist, werden wir nur den Durchsatz unter dem Benchmark-Mikroskop untersuchen, nicht die Reaktionszeit zu bestimmten Ereignissen. Nach all dem ist es relativ leicht, die Geschwindogkeit des Dateitransfers zu messen, und Samba leidet nicht zu arg unter Reaktionszeit-Problemen, dass es anspruchsvollere Techniken erforden würde.

Unsere Hauptstrategie für diese Arbeit wird sein:

Finde eine Datei in angemessener Größe zum Kopieren und ein Programm wie smbclient, das über Kopiergeschwindigkeiten berichtet.
Finde eine ruhige (oder eine typische) Zeit, um den Test durchzuführen.
Mach für jeden Test ein paar Mal einen Vorlauf, um die Puffer vorzuladen.
Führe die Tests einige Male durch und achte auf ungewöhnliche Resultate.
Zeichne jeden Lauf im Detail auf.
Vergleiche den Durchschnitt der gültigen Läufe mit den erwarteten Werten.

Nach der Bildung einer Grundlinie mittels dieser Methode können wir einen einzelnen Parameter umstellen und alle Messungen wiederholen. Am Ende dieses Kapitels wird eine leere Tabelle für deine Tests geboten..

B.2.2 Dinge, wo man dran drehen kann

Es gibt buchstäblich Tausende Samba Einstell-Kombinationen, die du bei der Suche nach dem perfekten Server anwenden kannst. Jene von uns, die außerhalb der Systemadministration leben, können jedoch die Zahl der Optionen auf die in diesem Abschnitt angeführten beschränken. Diese Optionen wirken sich am wahrscheinlichsten auf den gesamten Durchsatz aus. Sie werden ungefähr in der Reihenfolge ihres Einsatzes vorgestellt.

B.2.2.1 Log level

Das ist etwas Offensichtliches. Eine Steigerung des Loglevels (Konfigurationsoptionenlog level oder debug level) ist ein guter Weg, ein Problem zu verfolgen, außer wenn du nach einem Performanceproblem suchst! Wie im Kapitel 4, Disk Shares, erwähnt, erzeugt Samba eine Tonne Debugging-Meldungen bei Level 3 und darüber, und sie auf die Platte zu schreiben ist ein langsamer Vorgang. In unseren Tests smbclient/ftp setzte die Erhöhung des Loglevels von 0 bis 3 das ungetunte get speed von 645.3 bis 622.2 KB/s oder um zirka 5 Prozent herunter. Höhere Loglevel waren sogar schlechter.

B.2.2.2 Socket options

Der nächste Punkt zum Nachschauen sind die Konfigurationsoptionen socket options. Diese sind eigentlich Optionen zum Tuning von Host-Systemen, aber sie sind auf einer Pro-Verbindungs-Basis eingerichtet und können von Samba auf den Sockets zurückgesetzt werden, die es durch Zugabe von socket options = option zur [global] -Sektion deiner smb.conf -Datei eingerichtet hat. Nicht alle von diesen Optionen werden von allen Vertreibern unterstützt; schau in die Manual-Pages deiner Distribution bei setsockopt (1) oder socket (5) nach Einzelheiten.

Die Haupt-Optionen sind:

TCP_NODELAY: Lass den Server so viele Pakete als nötig senden, um die Verzögerung niedrig zu halten. Das wird auf Telnet-Verbindungen verwendet, um eine gute Reaktionszeit zu ermöglichen, und wird gebraucht - ein wenig konter-intuitiv - um eine gute Geschwindigkeit zu erhalten, sogar wenn man kleine Anfragen durchführt oder wenn Bestätigungen aufgehalten werden (wie es bei Microsoft TCP/IP vorzukommen scheint). Das ist von selbst 30-50 Prozent Beschleunigung. Übrigens wird in Samba 2.0.4 socket options = TCP_NODELAY der Vorgabewert für diese Option.
IPTOS_LOWDELAY: Das ist eine andere Option, die den Durchsatz gegen weniger Verzögerung austauscht, die aber Router und andere Systeme betrifft, nicht den Server. Alle IPTOS-Optionen sind neu; sie werden nicht von allen Betriebssystemen und Routern unterstützt. Wenn sie unterstützt werden, dann setze IPTOS_LOWDELAY wann immer du TCP_NODELAY einrichtest.
SO_SNDBUF und SO_RCVBUF: Die Sende- und Empfangs-Puffer können oft auf einen höheren Wert als den des Betriebssystems geändert werden. Dies ergibt eine geringfügige Steigerung der Geschwindigkeit (bis es einen Punkt abnehmender Returns erreicht).
SO_KEEPALIVE: Das initiiert einen periodischen (vier Stunden) Check, um nachzuschauen, ob der Client verschwunden ist. Ungültige Verbindungen werden mit Samba's Optionenkeepalive und dead time ein bisschen besser angesprochen. Alle drei sorgen schließlich dafür, tote Verbindungen zu schließen, indem sie dem Betriebssystem ungenützten Speicher und Einträge in der Prozesstabelle zurückgeben.

Es gibt einige andere Socket-Options, die du suchen könntest (z.B. SO_SNDLOWAT), aber sie variieren von Distribution zu Distribution. Du willst wahrscheinlich bei TCP/IP Illustrated nachschauen, wenn du interessiert bist, mehr dieser Optionen für Performance-Tuning bei Samba zu entdecken.

B.2.2.3 read raw und write raw

Das sind wichtige Optionen zur Performance-Konfiguration; sie ermöglichen Samba, große Lese- und Schreibvorgänge auf dem Netzwerk zu benützen, bis zu 64 KB in einem einzigen SMB-Request. Sie brauchen auch die größten SMB-Paketstrukturen, SMBreadraw und SMBwriteraw, von denen die Optionen ihre Namen beziehen. Beachte, dass das nicht dasselbe wie ein Unix raw read ist. Dieser Unix-Term verweist gewöhnlich auf das Lesen von Platten, ohne das Dateisystem zu verwenden, eine ganz andere Bedeutung gegenüber dem hier für Samba beschriebenen.

Früher versagten manche Client-Programme, wenn du versuchtest, read raw zu verwenden. So weit wir wissen, leidet kein Client mehr unter diesem Problem. Read und write raw ist auf yes voreingestellt und sollte so belassen werden, außer du findest, dass du einen von den unsicheren Clients hast.

B.2.2.4 Opportunistic locking

Opportunistic locks, oder oplocks, erlauben Clients Dateien lokal zu cachen und steigern die Performance in der Größenordnung von 30 Prozent. Diese Option ist nun per Voreinstellung eingeschaltet. Für Read-Only-Dateien bieten die fake oplocks dieselbe Funktionalität, ohne wirklich Caching zu machen. Wenn du Dateien hast, die nicht gecacht werden können, kann oplocks abgeschaltet werden.

Datenbank-Dateien sollten nie gecacht werden, noch sollten Dateien, die vom Server und vom Client upgedatet werden und deren Veränderungen sofort sichtbar sein müssen, gecacht werden. Für diese Dateien erlaubt dir die Option veto oplock files, eine Liste einzelner Dateien oder eine Zeichenfolge mit Wildcards anzuführen, um Caching zu vermeiden. oplocks können auf Share-by-Share-Basis ausgeschaltet werden, wenn du große Gruppen von Dateien hast, die du nicht auf Clients gecacht haben willst. Siehe Kapitel 5, Browsing und fortgeschrittene Disk Shares, für mehr Information über Opportunistic Locks.

B.2.2.5 IP-Paketgröße (MTU)

Netzwerke setzen generell ein Limit für die Größe einer einzelnen Übertragung oder eines Pakets. Das nennt man Maximum Segment Size oder, wenn die Größe des Paket-Headers eingeschlossen ist, die Maximum Transport Unit (MTU). Diese MTU wird nicht von Samba eingerichtet, aber Samba muss eine max xmit (Schreib-Größe) größer als die MTU verwenden, oder der Durchsatz wird reduziert. Das wird eingehender in der folgenden Notiz besprochen. Die MTU wird normalerweise auf 1500 Bytes bei Ethernet und 4098 Bytes bei FDDI voreingestellt. Im Allgemeinen, hat man sie zu niedrig, setzt sie den Durchsatz herab, hat man sie zu hoch, verursacht sie ein plötzliches Nachlassen der Performance auf Grund von Fragmentation und Rücksendungen.

Wenn du über einen Router kommunizierst, werden einige Systeme annehmen, der Router sei ein serieller Link (z.B. ein T1), und setzen die MTU auf mehr oder weniger als 536 Bytes. Windows 95 macht diesen Fehler, welcher nahe gelegene Clients veranlasst, eine gute Leistung zu bringen, aber Clients auf der anderen Seite des Routers veranlasst, merkbar langsamer zu sein. Wenn der Client den gegenteiligen Fehler macht und eine große MTU auf einem Link benützt, welcher eine kleine verlangt, werden die Pakete in Fragmente zerteilt. Das verlangsamt Übertragungen ein bisschen, und irgendwelche Netzwerkfehler verursachen mehrere Fragmente, die zurücktransportiert werden müssen, was Samba signifikant verlangsamt. Glücklicherweise kannst du die Größe der Windows-MTU verändern, damit du jeden Fehler verhinderst. Um dies genauer zu verstehen, schau dir "The Windows 95 Networking Frequently Asked Questions (FAQ)" bei http://www.stanford.edu/~llurch/win95netbugs/faq.html an, wo erklärt wird, wie man die Windows-MTU und die Window-Size verändert.

B.2.2.6 Das TCP-Empfangsfenster

TCP/IP arbeitet, indem es Daten in kleine Pakete zerlegt, die von einer Maschine zur anderen transportiert werden können. Wenn jedes Paket übertragen wird, enthält es eine Checksumme, die dem Empfänger erlaubt, das Datenpaket auf potentielle Fehler bei der Übertragung zu prüfen. Theoretisch, wenn ein Paket angekommen und verifiziert ist, sollte ein Bestätigungs-Paket zum Sender zurückgesandt werden, das notwendigerweise "Alles kam gut an: bitte setz fort" sagt.

Um die Dinge in Bewegung zu halten, akzeptiert TCP einen Bereich (Fenster) von Paketen, der einem Sender erlaubt, Übertragungen durchzuführen, ohne auf eine Bestätigung für jedes einzelne Paket warten zu müssen. (Es kann dann eine Gruppe von Bestätigungen bündeln und überträgt sie zur selben Zeit zum Sender zurück.) Mit anderen Worten, dieses Empfangsfenster ist die Zahl der Bytes, die der Sender übertragen kann, bevor er anhalten und auf eine Empfangsbestätigung warten muss. Wie die MTU wird es automatisch gesetzt, gestützt auf den Verbindungstyp. Ein zu kleines Fenster verursacht viel unnötiges Warten auf Bestätigungs-Meldungen. Verschiedene Betriebssysteme setzen moderate Puffergrößen auf einer Pro-Socket-Basis, um ein Programm davon abzuhalten, den ganzen Speicher in Beschlag zu nehmen.

Die Puffergrößen werden in Bytes angegeben, wie SO_SNDBUF=8192 in der Zeile socket options. So ist eine socket options Beispiels-Konfigurationsoption:

socket options = SO_SNDBUF=8192

Normalerweise versucht einer, diese Socket-Options höher als die vorgegebenen zu setzen: 4098 in SunOS 4.1.3 und SVR4, 8192-16384 in AIX, Solaris und BSD. 16384 wurde als ein guter Startpunkt vorgeschlagen: in einem Nicht-Samba-Test, erwähnt in Steven's Buch, ergab es eine 40-prozentige Verbesserung. Du musst experimentieren, weil die Performance wieder nachlässt, wenn du die Größen zu hoch ansetzt. Das wird in Figur B.1 dargestellt, einem Test, der auf einem bestimmten Linuxsystem durchgeführt wurde.

Figur B.1: SO_SNDBUF-Größe und Performance

Eine Einstellung der Socket-Options O_SNDBUF und SO_RCVBUF auf weniger als die Vorgabe ist nicht ratsam. Sie höher zu setzen, verbessert die Performance bis zu einer Netzwerk-spezifischen Grenze. Sobald du aber dieses Limit überschreitest, wird die Performance abrupt gebremst.

B.2.2.7 max xmit

Die mit der MTU und der Fenstergröße direkt in Beziehung stehende Option in Samba ist max xmit. Diese Option setzt den größten Datenblock, den Samba auf einmal zu schreiben versucht. Sie ist machmal als write size bekannt, obwohl das nicht der Name der Samba-Konfigurationsoption ist.

Weil der Prozentsatz jedes Blocks, der für den Overhead notwendig ist, fällt, wenn der Block größer wird, wird max xmit üblicherweise so groß als möglich eingerichtet. Es hat eine Vorgabe durch die obere Grenze des Protokolls, welche 64 Kilobytes beträgt. Der kleinste Wert, der keine signifikanten Verzögerungen verursacht, ist 2048. Wenn er niedrig genug gesetzt wird, limitiert er die höchste Paketgröße, die Samba auszuhandeln vermag. Dies kann genutzt werden, um eine kleine MTU zu simulieren, wenn du eine unzuverlässige Netzwerkverbindung testen musst. Obwohl so ein Test nicht in einem Vorgang zur Herabsetzung der tatsächlichen MTU verwendet werden sollte.

B.2.2.8 read size

Wenn max xmit üblicherweise die Write Size genannt wird, hättest du erwartet, dass read size die maximale Menge von Daten ist, die Samba vom Client via Netzwerk würde lesen wollen. Eigentlich ist es das nicht. Es ist tatsächlich eine Option, um write ahead auszulösen. Das bedeutet, dass, wenn Samba Lesen von der Platte und Schreiben in das Netzwerk (oder umgekehrt) durch die angegebene Menge unterstützt, es beginnt, Netzwerk-Schreibvorgänge mit Platten-Lesevorgängen zu überlappen (oder umgekehrt).

Die Option read size hat keinen großen Performance-Effekt unter Unix, außer du setzt ihren Wert ganz herunter. Jetzt verursacht sie eine feststellbare Verzögerung. Aus diesem Grund ist sie auf 2048 voreingestellt und kann nicht niedriger als 1024 gesetzt werden..

B.2.2.9 read prediction

Außer dass sie Zähler-intuitiv ist, ist diese Option auch obsolet. Sie erlaubt Samba, auf Dateien vorauszulesen, die von den Clients read-only geöffnet werden. Die Option ist in Samba 2.0 (und späten 1.9-Versionen) abgeschaltet, weil sie Opportunistic Locking stört.

B.2.2.10 write cache size

Dieser Parameter wurde in Samba 2.0.7 eingeführt, um die Einstellung der Schreib-Größe von RAID-Disks zu erlauben sowie allgemeines Caching von Schreibvorgängen auf Maschinen mit üppigem Speicher aber langsamen Disks zu gestatten.

Er legt die Größe eines Per-File-Write-Cache in Bytes fest, den Samba für ein Oplocked-File erzeugt. Das kann die Performance signifikant steigern, indem er Schreibvorgänge verursacht, die in riesigen Blockgrößen durchgeführt werden.

Bis zu 10 Schreib-Caches können gleichzeitig unter smbd aktiv sein, jeder von der festgelegten Größe, die den ersten 10 Oplocked-Files zugeordnet sind. Wie bei anderen Dateisystem-Caches, kann ein Absturz, bevor die Daten geschrieben werden, Dateien beschädigen.

Das Setzen von sync always hebt das Schreib-Caching auf, und das Einrichten von strict sync erlaubt Windows-Clients, es aufzuheben. Leider setzt der Windows-Explorer als Vorgabe das Sync-Bit, so kann die Einrichtung von strict sync ein großer Performance-Schlag sein.

Weil er neu ist, haben wir nicht viele Berichte über den Performance-Zuwachs und vermuten bloß, er wird beachtlich sein.

B.2.3 Andere Samba-Optionen

Die folgenden Samba-Optionen wirken sich auf die Performance aus, wenn sie unkorrekt gesetzt werden, sehr ähnlich dem Debug-Level. Sie werden hier erwähnt, damit du weißt, wonach du suchst:

hide files

Indem hide files ein Muster zur Identifizierung von Dateien liefert, die für den Windows-Client versteckt sind, resultiert es in jeder Datei, die mit dem Muster übereinstimmt, in der Einrichtung des DOS-Hidden-Attributs. Es erfordert eine Muster-Übereinstimmung pro Datei, wenn Verzeichnisse aufgelistet werden, und verlangsamt den Server merklich.

lpq cache time

Wenn dein lpq (Inhalt der Drucker-Warteschlange)-Befehl lange Zeit zum Beenden braucht, solltest du die lpq cache time auf einen höheren Wert als die momentane Zeitdauer hinaufsetzen, die für die Ausführung von lpq nötig ist, damit Samba vom Start einer neuen Anfrage zurückgehalten wird, wenn schon eine läuft. Die Vorgabe ist 10 Sekunden, was angemessen ist.

strict locking

Das Setzen der strict locking-Option veranlasst Samba, nach Locks auf jedem Zugriff zu prüfen, nicht wenn gerade der Client danach verlangt. Die Option ist in erster Linie ein Bug-Vermeidungs-Feature und kann schlecht programmierte DOS- und Windows-Applikationen am Zerstören freigegebener Dateien hindern. Aber es ist langsam und sollte typischerweise vermieden werden.

strict sync

Das Setzen von strict sync veranlasst Samba, jedes Paket auf Disk zu schreiben und auf die Beendigung des Schreibvorganges zu warten, wann immer der Client das Sync-Bit in einem Paket setzt. Der Windows 98-Explorer setzt das Bit in allen übertragenen Paketen, sodass, wenn du das einschaltest, jeder bei Windows 98 glauben wird, Sambaserver seien schrecklich langsam.

sync always

Das Setzen von sync always veranlasst Samba, jeden Schreibvorgang direkt auf die Disk zu bringen. Das ist gut, wenn dein Server konstant abstürzt, aber die Performance-Einbußen sind enorm. SMB-Server verwenden normalerweise Oplocks und automatische Wieder-Verbindung, um die zerstörerischen Effekte von Abstürzen zu vermeiden, daher ist das Setzen dieser Option normalerweise nicht notwendig.

wide links

Das Ausschalten von wide links schützt Samba vor dem Verfolgen symbolischer Links in einer File-Share zu Dateien, die nicht in der Share sind. Es ist per Voreinstellung eingeschaltet, weil das Verfolgen von Links in Unix kein Sicherheitsproblem darstellen. Das Ausschalten erfordert einen extra Vorgang beim Öffnen jeder Datei. Wenn du wide links ausschaltest, schalt auf jeden Fall getwd cache ein, um einige der notwendigen Daten zu cachen.

Es gibt auch eine Option follow symlinks, die ausgeschaltet werden kann, um das Verfolgen aller symbolischen Links überhaupt zu vehindern. Nun, diese Option stellt kein Performance-Problem dar.

getwd cache

Diese Option speichert den Pfad zum laufenden Verzeichnis und vermeidet lange Wanderungen durch den Verzeichnisbaum, um es zu entdecken. Sie ergibt eine nette Performance-Verbesserung auf einem Drucker-Server oder wenn du wide links ausgeschaltet hast.

B.2.4 Unsere Empfehlungen

Hier ist eine smb.conf-Datei, welche die empfohlenen Performance-Erweiterungen so weit enthält. Kommentare wurden auf der rechten Seite beigefügt.

[global] 
	log level = 1                      # Default is 0 
	socket options = TCP_NODELAY IPTOS_LOWDELAY 
	read raw = yes                     # Default 
	write raw = yes                    # Default 
	oplocks = yes                      # Default 
	max xmit = 65535                   # Default 
	dead time = 15                     # Default is 0
	getwd cache = yes
	lpq cache = 30
[okplace] 
	veto oplock files = this/that/theotherfile
[badplace] 
	oplocks = no

Using Samba