LinuxSamba

LinuxSamba

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: [1]
[2] Benchmarkwerte Samba 3 gegen Windows Server 2003, gemessen von IT Week: [2] und [3]
[3] Netbench: [4]
[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.
Dieser Online-Artikel kann Links enthalten, die auf nicht mehr vorhandene Seiten verweisen. Wir ändern solche "broken links" nur in wenigen Ausnahmefällen. Der Online-Artikel soll möglichst unverändert der gedruckten Fassung entsprechen. Druckerfreundliche Version | Feedback zu dieser Seite | © 2004 Linux New Media AG | Last modified: 2003-12-03 19:09 Nach oben

Sizing für Samba

Ausfürlicher Artikel

http://lug.krems.cc/docu/samba/appb_03.html

Grobe Annahmen

Ein Proposal-Projekt bescherte uns die Frage nach dem Sizing von Samba. Hier meine Ergebnisse: Im Gegensatz zu uns haben HP und IBM entsprechende White Papers veröffentlicht (s. Anlage). Das Buch "Using Samba" hat auch ein entsprechendes Kapitel; im Netz ist allerdings nur die Version von 1999. Linuxvoodo bringt ein kleines HP Sizing.

Hauptspeicher: Pro Client rechnet man 512-768KB. Pro Share 2MB (nehme an, share level security, also hier nicht relevant). Ein Printer auch 2MB. Basissystem nochmal >96MB. Die 15.000 User der Barmer brauchen also 8 bis 12GB, plus 30GB wenn jeder seinen eigenen Printer hat (? Was ich nicht glaube, da fast ausschließlich von über LAN angeschlossenen Laserdruckern die Rede ist.)

CPU: Wird laut IBM beim Logon am heftigsten genutzt. Wenn der Durchsatz hier funktioniert, funktioniert er auch im laufenden Betrieb.

Durchsatz: Beim Login holen sich die User 10MB Profil * 15.000 -> 150GB. Wenn alle User (Angestellte des öffentlichen Dienstes :-) sich innerhalb einer halben Stunde anmelden, braucht man einen Durchsatz von 1500Gbit / 1800 Sekunden -> 850 Mbit/sec. NetBench für 2 CPU PRIMERGY BX620 S2, Xeon, 800 Mhz bus gibt 1600 Mbit/s. Kann einer das nochmal auf FibreChannel Controller umrechnen? :-)

Und wir wissen, dass der HDI (unter Windows) einen 4fach-Cluster aus 4Wege-Systemen für 5000 User hat (wobei für die Last die Hälfte ausreichen würde).

Mein Vorschlag ist, aus Gründen der Einheitlichkeit entsprechend BX600 S2 Blades für die geforderten Services zu konfigurieren: Name Services: 2 Blades zu 2 CPU pro Standort, also 4 Blades gesamt Boot Services: Keine Ahnung Print Services: 2 Blades zu 4 CPU pro Standort, also 4 Blades File Services: Gute Frage. 4 Blades zu 4 CPU pro Standort, also 8 Blades, verteilt auf zwei Cluster? Mit 2 FC-Anschlüssen.

Pro CPU rechne ich immer 2GB.

Einwände?