Der Samba-Server verwendet TCP zur Kommunikation mit dem Client. Um die wirkliche Performance beurteilen zu können, sollte sie mit der anderer Programme verglichen werden, die ebenfalls TCP verwenden. Die am leichtesten verfügbaren Programme dieser Art sind ftp oder andere auf TCP basierende SMB-Server.

Um Samba mit anderen Servern wie Windows-NT- oder Windows-for-Workgroups-Servern vergleichen zu können, müssen alle Protokolle außer TCP entweder auf dem Client oder auf dem Server deaktiviert werden. Ansonsten besteht die Möglichkeit, unwissentlich ein gänzlich anderes Protokoll (wie NetBEUI) zu verwenden. Die resultierenden Ergebnisse wären unbrauchbar.

Allgemein kann gesagt werden, dass Samba ähnliche Durchsatzraten wie ftp erzielt. Es sollte ein deutliches Stück schneller als NFS arbeiten, wobei dies vom System abhängt.

Es gibt einige Vergleiche zwischen Samba und Novell, NFS oder NT. In manchen schneidet Samba am besten ab, in anderen am schlechtesten. Es ist zu vermuten, dass der größte beeinflussende Faktor nicht Samba selbst, sondern die Kombination von Hardware und Treibern der verschiedenen Systeme ist. Bei der Verwendung ähnlicher Hardware sollte Samba sehr wohl wettbewerbsfähig sein.

Es gibt einige Socket-Optionen, die die Performance eines TCP-basierten Servers wie Samba stark beeinflussen können.

Die von Samba verwendeten Socket-Optionen können sowohl mit der Option -O auf der Befehlszeile gesetzt werden als auch in der Datei smb.conf.

Der Abschnitt zu socket options in der Manpage zu smb.conf beschreibt deren Verwendung und gibt diesbezügliche Empfehlungen.

Die Socket-Optionen richtig zu setzen kann einen großen Einfluss auf die Performance haben; sind sie jedoch falsch gesetzt, kann dies die Performance ebenso sehr verschlechtern. Die korrekten Parameter sind in hohem Maße vom lokalen Netzwerk abhängig.

Die Socket-Option TCP_NODELAY ist diejenige, die den größten Leistungsunterschied für die meisten Netzwerke auszumachen scheint. Viele Anwender berichten, dass das Hinzufügen von socket options = TCP_NODELAY die Lese-Performance eines Samba-Laufwerks verdoppelt. Die beste Erklärung hierfür scheint, dass der Microsoft TCP/IP-Stack sehr langsam beim Senden von TCP-ACKs ist.

Es wurde berichtet, dass das Setzen von socket options = SO_RCVBUF=8192 in smb.conf die Samba-Performance auf dem Loopback-Interface (IP 127.0.0.1) stark verschlechtert. Es wird daher empfohlen, vor dem Setzen jeglicher socket options die Auswirkungen quantitativ auf dem zu konfigurierenden Server zu messen.

Die Option read size beeinflusst die Überschneidungen von Platten-Schreib/Lese-Vorgängen mit Netzwerk-Schreib/Lese-Vorgängen. Wenn die von einigen SMB-Befehlen (momentan SMBwrite, SMBwriteX und SMBreadbraw) transferierte Datenmenge über diesem Wert liegt, beginnt der Server bereits Daten zu schreiben, bevor er noch das ganze TCP-Paket vom Netzwerk empfangen hat. Im Falle von SMBreadbraw beginnt er Daten an das Netz zu senden, bevor er noch alle Daten von der Platte gelesen hat.

Diese Überschneidung funktioniert am besten, wenn die Platten- und Netzwerk-Zugriffsgeschwindigkeit ungefähr gleich sind. Bei großen Unterschieden zwischen diesen beiden Werten hat dieser Parameter wenig Auswirkung.

Der Standard-Wert ist 16384, jedoch wurde bisher wenig experimentiert, um den optimalen Wert zu finden, es ist außerdem anzunehmen, dass dieser Wert stark zwischen einzelnen Systemen variiert. Ein Wert über 65536 ist nutzlos und verursacht nur unnötig hohe Speicherbelegung.

Beim Verbindungsaufbau verhandeln Client und Server einen Wert namens maximum transmit size, der die Größe nahzu aller SMB-Befehle beschränkt. Der Startwert für diese Verhandlung kann mit der Option max xmit in smb.conf gesetzt werden. Beachten Sie, dass dies die maximale Größe der SMB-Anfragen ist, die Samba akzeptiert, jedoch nicht die maximale Größe, die der Client akzeptiert. Der Client legt die von ihm akzeptierte maximale SMB-Anfragen-Größe fest, und Samba berücksichtigt dieses Limit.

Dieser Wert beträgt standardmäßig 65536 Bytes (das Maximum), aber es ist möglich, dass manche Clients mit einer kleineren Übertragungseinheit schneller arbeiten. Werte unter 2048 verursachen meist ernsthafte Probleme. Im Normalfall ist der Standard-Wert der beste.

Wird der Log-Level (auch als debug level bekannt) auf Werte größer als 2 gesetzt, resultiert dies meist in einem starken Performance-Einbruch. Dies liegt daran, dass der Server nach jeder Operation das Logfile „flusht“.

Die read raw-Operation ist eine optimierte Lese-Operation mit geringer Latenz-Zeit. Ein Server kann diese wahlweise unterstützen, Samba trägt dem dadurch Rechnung, dass die Unterstützung für read raw optional ist, wobei diese standardmäßig aktiv ist.

In einigen Fällen können Clients mit dem Parameter read raw nicht besonders gut umgehen. Dann hat seine Verwendung eine schlechtere Performance zur Folge als die Verwendung der konventionellen Lese-Operation.

Es liegt nahe, die Option read raw = no auszuprobieren und die Auswirkungen im jeweiligen Netzwerk zu prüfen. Diese Einstellung kann die Performance steigern, verringern oder auch gar nicht beeinflussen. Nur ein Test kann dies wirklich zeigen.

Die write raw-Operation ist eine optimierte Schreiboperation mit geringer Latenz-Zeit. Ein Server kann diese wahlweise unterstützen; Samba trägt dem dadurch Rechnung, dass die Unterstützung für write raw optional ist, wobei diese standardmäßig aktiv ist.

Einige Maschinen arbeiten mit write raw langsamer als mit normalem Schreiben. In diesem Fall erscheint es besser, diese Option zu ändern.

„Slow Logins“ hängen so gut wie immer mit der Zeit zusammen, die benötigt wird, um das Passwort zu überprüfen. Das Verwenden des niedrigstmöglichen password level wird dies verbessern.

Oft kann ein Geschwindigkeitsproblem auf den Client zurückgeführt werden. Der Client (z.B. Windows for Workgroups) kann oft noch auf bessere TCP-Performance getunt werden. Lesen Sie diesbezüglich die jeweiligen Abschnitte in ???.

Ein Samba-Anwender hat das Folgende an die Samba-Mailingliste geschrieben:

Ich verwende auf meinem Server Gentoo Linux und Samba 2.2.8a. Unlängst habe ich meinen Kernel von linux-2.4.19-gentoo-r10 auf linux-2.4.20-wolk4.0s geändert. Nun habe ich ein Performance-Problem mit Samba. Viele von euch werden vielleicht sagen, „Versuche es mit den ursprünglichen Kernel-Sourcen!“. Tja, ich habe das versucht, und es hat nicht funktioniert. Ich habe ein 100-MBit-LAN und zwei Rechner (Linux und Windows 2000). Der Linux-Server gibt Verzeichnisse mit DivX-Dateien frei, der Windows-Client spielt diese über das LAN ab. Zuvor, als ich noch den 2.4.19-Kernel verwendet habe, lief alles sauber, aber nun stocken und stoppen die Filme. Der Versuch, die Dateien vom Server auf den Windows-Rechner zu schieben, zeigte, dass dies schrecklich langsam ist.

Die Antwort, die er erhalten hat, war diese:

Besorge dir das mii-Tool und überprüfe die Duplex-Einstellungen auf deiner Netzwerkkarte. Meine Vermutung ist, dass dies ein Problem in der Verbindungsschicht ist, keines in der Anwendungsschicht. Überprüfe außerdem, ob die Ausgaben von ifconfig in Hinblick auf Kollisionen usw. normal für Ethernet erscheinen.

Unser Samba-PDC-Server verwaltet seit drei Jahren ohne Probleme 3 Tbyte Daten für unsere mehr als 500 Benutzer [Windows NT/XP]. Heute wurden alle Freigaben plötzlich sehr langsam. Außerdem begann der Haupt-smbd-Prozess damit, neue Sub-smbd-Prozesse zu starten, so dass wir schließlich über 1600 laufende smbd-Prozesse hatten (normalerweise haben wir durchschnittlich 250). Dies brachte den SUN E3500-Cluster zweimal zum Absturz. Nach vielem Suchen habe ich entschieden, rm /var/locks/*.tdb auszuführen. Endlich bin ich wieder glücklich!

Frage: Gibt es eine Methode, um die tdb-Dateien in gutem Zustand zu halten? Wie kann ich frühzeitig feststellen, dass diese Dateien beschädigt sind?

Antwort: Führe tdbbackup nach jedem Stopp und vor jedem Start von nmbd aus. (Anmerkung des Übersetzers: Eine Möglichkeit ist, dies in das rcsmb/rcnmb-Skript aufzunehmen, das viele Distributionen verwenden.)

Frage: Was ich noch bemerken möchte, ist, dass die Antwortzeiten der Dienste bei weitem niedriger erscheinen als vor dem Bereinigen der Sperrdateien. Gibt es Möglichkeiten, diese im Top-Zustand zu halten?

Antwort: Ja. Selbe Antwort wie zuvor!

Der Administrator einer Site hat über sehr verblüffende Symptome berichtet, die mit MYOB Premier zusammenhängen, das seine Datendateien öffnet und darauf zugreift. Einige Operationen würden zwischen 40 und 45 Sekunden dauern.

Es stellte sich heraus, dass das Drucker-Überwachungsprogramm, das auf den Windows-Clients läuft, das Problem verursacht hat. Aus den Log-Dateien wurde dessen Aktivität im 1-Sekunden-Takt ersichtlich.

Das Stoppen dieses Überwachungsprogramms ergab Netzwerkzugriffe in normaler (schneller) Geschwindigkeit. Das Neustarten des Programmes ließ die Geschwindigkeit wieder stark abfallen. Der Drucker war ein Canon lbp810, und der betreffende Task hieß so ähnlich wie CAPON (exakte Schreibweise unbekannt). Die Überwachungssoftware zeigte einen „Druck wird ausgeführt“-Dialog auf dem Windows-Client.

Wir haben dies festgestellt, indem wir eine frische Windows-Installation verwendeten und die Anwendung bei jedem Installationsschritt einer anderen Software ausprobiert haben (wir mussten dies oft tun ...).

Und die Moral von der Geschicht': Überprüfe alles (andere Software eingeschlossen)!