Linux-Magazin-Logo Die Zeitschrift für Linux-Professionals

Fileserver-Benchmarking mit Dbench, Tbench und Smbtorture

Wettkampf-Regeln

Volker Lendecke

Samba ist schnell. Um diese Behauptung zu belegen, aber auch um Engpässe zu finden und geeignete Tuningmaßnahmen zu testen, muss ein Fileserver-Benchmark her. Der oft zitierte Netbench ist allerdings sehr aufwändig zu handhaben.

Ob Sambas Version 3[1] unter Linux wirklich zweieinhalbmal so schnell ist wie Windows 2003 Server, wie jüngst vom britischen Magazin "IT Week" gemessen[2] und in Abbildung 1 zu sehen, sei einmal dahingestellt. Zumindest aber hat die freie SMB-Implementierung bei gleicher Hardware kein Problem mit der Performance gegenüber Windows und skaliert sehr gut auf großer und leistungsfähiger Hardware.

Abbildung 1: Das britischen Magazin "IT Week" hat jüngst per Netbench gemessen, dass Samba 3 unter Linux zweieinhalbmal so schnell ist wie Windows 2003 Server.

Damit den Samba-Entwicklern eine Performance-Diskussion - wie sie einst Linux selbst erlebte (siehe Kasten "Der historische Mindcraft-Schock") - erspart bleibt, muss es in der Lage sein, mit Windows vergleichbare Ergebnisse vorzuweisen. IT Week benutzt wie die meisten anderen Studien als Messtool den aufwändigen Netbench[3] von Ziff-Davis. Der Test gibt einen Wert für eine Transferleistung abhängig von der Anzahl der Clients aus und damit einen Anhaltswert für die Skalierbarkeit und Sättigungsgrenze eines SMB-Servers.

Der historische Mindcraft-Schock

1999 wurde der berühmt-berüchtigte Mindcraft-Benchmark publiziert, der Windows 2000 eine bessere Leistung und insbesondere Skalierbarkeit bescheinigte als Linux[4]. Obwohl die technischen und finanziellen Umstände für diese Veröffentlichung etwas dubios waren, eins hat sie gezeigt: Linux hatte damals ein Skalierungsproblem auf Multiprozessormaschinen.

Dadurch angestoßen machten die Kernelprogrammierer das IP-Subsystem als ersten großen Teilbereich des Linux-Kerns wirklich Multiprozessor-tauglich, indem sie statt des großen Kernel-Locks viele kleine Sperren einbauten. Diese Arbeit wirkt bis heute: Das Netzwerk-Subsystem hat sich seit dem 2.4er Kernel deutlich weniger verändert als der Rest des Kernels.

Inwieweit Netbench-Ergebnisse praxistauglich sind, ist jedoch streitig: Das Programm simuliert offenbar über alle Maßen viele Schreiboperationen, was für Fileserver in Office-Umgebungen untypisch ist, in ihnen dominieren Leseoperationen. Konkurrierende Zugriffe auf eine Datei und die Zugriffszeiten auf Access-Dateien misst er gar nicht. Zum Überprüfen eigener Tuningmaßnahmen taugt der Netbench aber allemal.

Der Netbench ist nichts für den kleinen Mann

Netbench setzt ein Labor mit vielen Clients voraus, die zeitgleich auf dem (Samba-)Server eine definierte Last simulieren. Aber wer hat schon 30 oder noch mehr PCs, die einen Server quälen? Und selbst wenn, der Netbench-Test hängt von viel zu vielen Parametern ab, um klare Hinweise für eine saubere Analyse von Leistungsproblemen zu geben. Beispielsweise übt das Client-Betriebssystem massiv Einfluss auf die Messung aus; der TCP-Stack von Windows 95 arbeitet völlig anders als der von Windows NT oder 2000!

Daher hat Andrew Tridgell, einer der beiden Samba-Erfinder, eine viel leichter realisierba-re Alternative ersonnen: Er beobachtete dazu einen Netbench-Lauf mit Tcpdump und las die SMB-Operationen aus. Mit diesen Erkenntnissen stand ihm der Weg für ein eigenes, weniger aufwändiges Testtool offen.

Im Wesentlichen bestimmen drei Komponenten die Server-seitige Performance: das Netzwerk-Subsystem, Samba selbst und das Filesystem beziehungsweise die Festplatten. Um die Analyse zu vereinfachen, hat Tridgell zwei Tools geschrieben, die einen Netbench-Lauf auf ihre wesentlichen Operationen herunterkochen: Dbench und Tbench. Dbench simuliert exakt die Dateisystem-Zugriffe, die Netbench einem Samba-Server zumutet. Das Gegenstück Tbench besteht aus einem Server und einem Client, die das Gleiche über ein Netzwerk vollführen, ohne jedoch die Festplatte erwähnenswert zu behelligen.

Wer die Tests seinem eigenen Samba-Server angedeihen lassen will, muss aber wissen, dass beide Programme rein interne Entwicklungstools sind, die selbst nach dem Maßstab von Kommandozeilen-Programmen recht umständlich zu bedienen sind. Die Benchmarks sind auch kein Bestandteil der Samba-Distribution, sondern müssen per CVS bezogen werden. Das Kommando

cvs -d pserver:samba.org:/data/cvs co dbench

lädt die Quellen herunter.

Kein Configure, kein Support

Unter Linux genügt danach ein »make« im Unterverzeichnis »dbench«, um die drei Programme »dbench«, »tbench_srv« und »tbench« zu erzeugen. Admins, die Tbench zwischen zwei verschiedenen Rechnern ausführen wollen, müssen den Quellcode ändern und neu kompilieren, weil »localhost« in der Datei »sockio.c« hart kodiert ist.

Da alle drei Programme sehr einfach sind, sollten sie auf anderen Plattformen ebenfalls gut kompilieren. Wer trotzdem damit Probleme hat, ist leider auf sich selbst gestellt. Es gibt kein »configure« und auch definitiv keinen Support auf Mailinglisten.

Im Verzeichnis »dbench« liegen die Dateien »client_plain.txt« und »client_ oplocks.txt«. Sie listen die von Netbench aufgezeichneten Daten, jeweils ohne und mit Server-seitig aktivierten Oplocks. Dbench und Tbench lesen standardmäßig die Datei »client_oplocks.txt« ein, mit »-c Datei« kann man einen beliebigen anderen Test durchführen.

Dbench lässt sich nun aufrufen, wobei es die Anzahl der simulierten Clients als Parameter übergeben haben will. Danach gibt es die Anzahl der ausgeführten Operationen und die lokal gemessenen MByte pro Sekunde aus:

linux:~/dbench # ./dbench 10
10 clients started
   0     62477  131.38 MB/sec
Throughput 131.375 MB/sec 10 procs

Ein Dbench-Lauf entspricht den etwas mehr als 60000 Operationen, die ein Netbench normalerweise ausführt.

Testkonfiguration

Alle Tests liefen auf einem Laptop IBM X31 mit 1,4-GHz-CPU (Centrino) und 768 MByte RAM. Die Maschine »linux« ist eine VMware 4.0.1 mit 384 MByte RAM, Suse Linux Enterprise Server 8 und Samba 3.0.1rc2.

Primäres Ziel ist es, die Bedienung der Programme zu demonstrieren, weshalb das Betrachten der Praxisrelevanz der mit VMware ermittelten Werte unterbleiben darf. Aus dem gleichem Grund erspart der Autor seinen Lesern die Ergebnisse des korrespondierenden Smbtorture-Laufs bei einem gleich ausgestatteten Windows 2003 Server.

Tbench testet die reine Netzwerk-Performance

Der Tbench besteht aus dem Server »tbench_srv« und dem »tbench«-Client. Der »tbench_srv« wartet auf Port 7003 auf einen Kontaktanbahnungsversuch des Tbench:

linux:~/dbench # ./tbench_srv
waiting for connections

Von einer anderen Maschine kommend kann man nun den (speziell kompilierten) Tbench-Client aufrufen

vlendec@delphin:/data/dbench> ./tbench 10
10 clients started
   0     62477  52.81 MB/sec
Throughput 52.8061 MB/sec 10 procs

und so das Netzwerk-Subsystem mit einer eingeschränkten, definierten Last anschauen.

Eine richtige Tortur

Natürlich ist es am interessantesten, aus der Tridgell'schen Analyse der Netbench-Operationen auch den vollständigen Test nachzuvollziehen. Das geht mit einem Unterprogramm der Testsuite Smbtorture. Smbtorture steckt zwar bereits im Samba-Quellcode, wird jedoch normalerweise nicht mit kompiliert. Wer will, muss also explizit »make torture« aufrufen, um das Binary »smbtorture« zu erhalten.

Smbtorture will in dem Verzeichnis aufgerufen werden, in dem auch die Dateien »client_plain.txt« und »client_ oplocks.txt« liegen:

vlendec@delphin:/data/dbench> smbtorture //linux/tmp -U vl%asdf -N 10 NBENCH
host=linux share=tmp user=vl myname=delphin
Running NBENCH
10 clients started
   1     62364  18,00 MB/sec

Throughput 17,9969 MB/sec
NBENCH took 193,386 secs

Fazit

Bei aller Skepsis, die gegenüber synthetischen Benchmarks angebracht ist, eins scheint sich zu bewahrheiten: Die Smbtorture-Ergebnisse bilden eine gute Annäherung an die des originalen Netbench-Test. Der Vergleich zwischen den Netbench-Daten der IT Week und jenen, die sich mit den hier vorgestellten Tools ergeben, legen diesen Verdacht zu Gunsten Sambas sehr nahe.

Dbench, Tbench und Smbtorture eignen sich jedenfalls hervorragend, um den Erfolg (oder den Misserfolg) eigener Tuningmaßnahmen an der Netzwerk-Konfiguration oder der Serversoftware und -hardware zu belegen. (jk)

Infos:

[1] Samba-Projekt: [http://samba.org]

[2] Benchmarkwerte Samba 3 gegen Windows Server 2003, gemessen von IT Week: [http://www.itweek.co.uk/News/1144312] und [http://www.itweek.co.uk/news/1144289]

[3] Netbench: [http://www.etestinglabs.com/benchmarks/netbench/netbench.asp?visitor=]

[4] Mindcraft-Ergebnisse 1999: http://www.mindcraft.com/whitepapers/openbench1.html]

Der Autor

Volker Lendecke ist Mitglied im Samba-Team und Mitgründer der Service Network GmbH in Göttingen. Dort ist er für Samba, Training und Netzwerksicherheit zuständig.