2. Teil: Samba "Untersuchung verschiedener Performanceeinflüsse"
Aus NAS-4220
Inhaltsverzeichnis |
Einleitung
Dieser 2.Teil zum Samba Benchmarkbericht ist aus verschiedenen Anfragen entstanden. Ich habe versucht weitere Aspekte zum Benchmarking tiefer zu beleuchten, die einen Einfluss auf die Performance haben können. Hierfür habe ich eine komplett neue Testreihe mit iozone aufgesetzt die speziell bei der Blockgössenermittlung diesmal sogar bis zu 6 Stunden lief. Bei Vergleichen, sofern nicht weiter aufgeführt, beziehe ich mich wie bereits im ersten Bericht auf die Blockgrösse 64KB.
Windows versus Linux
Zu diesem Test muss man im Vorfeld sagen, dass ein Samba Mount auf Linux nur bedingt Sinn macht, das sollten auch die folgenden Tests zeigen. Um das schlechte Performanceergebniss aus dem Test mit Linux zu erklären waren Ubuntu (7.03 Build 20070415) und Knoppix (5.1.1-CD Releasdate 2007-01-04) diesmal die Testkandidaten. Mit sogenannten Live-CDs kann man ohne Installationsaufwand seinem Rechner schnell ein neues Betriebssystem überstülpen. Im Test zeigen beide Linuxe den gleichen Durchsatz. Dieser liegt im Schnitt schreibend bei 3200kbyte/sec und lesend bei 4000kbyte/sec wobei der niedrigste Wert für Windows schreibend bei ungefähr 7600kbyte/sec und lesend bei 10000kbyte/sec liegt. Man kann deutlich erkennen, dass die Samba Technologie in das Windows System performanceorientierter implementiert wurde wobei Linux hier aufgrund der niedrigen Wertes ‚nur’ eine gewisse Möglichkeit bietet Samba Shares anzubinden. Der Test beweist, für Linux sollte NFS immer die erste Wahl sein. Die noch niedrigeren Uploadwerte für Linux aus dem früheren Test wurden hiermit für den allgemeinen Durchsatz widerlegt wobei die ursprünglich zu niedrige Blockgösse hier wohl Ursache für diese schlechte Performance war. Interessant ist im Vergleich jedoch, dass die Downloadrate bei dem früheren Test bei über 18,1 Mbyte lag. Sollte Suse doch ein anderes Cachingverhalten gegenüber den beiden Debian Linuxen haben oder war die Testmethode hier ausschlaggebend? Ich denke das muss ich später in einem Test hier noch nachlegen.
 Lesezugriff |
 Schreibzugriff |
Die Optimale Blockgrösse
Welches ist die optimale Blockgrösse bei der Übertragung? Hier scheint sich schreibend und lesend ein Unterschied abzuzeichnen. Die erste gemeinsame Spitze für den schreibenden Zugriffe von Windows auf das NAS scheint bei 256kbyte zu liegen wobei auch 64Kbyte noch einen sehr guten Wert zurückgibt. Bei höheren Blockgrössen sind Performanceschwankungen zu erkennen, die kein gemeinsames Optimum mehr für die verschiedenen Konfigurationen erkennen lassen. Lesend ist die Performance jedoch zum schreibenden Zugriff vollkommen gegenläufig. Hier lassen sich Spitzen bei 4 und 8 kbyte sowie bei abgeschlagenen 8- 16Mbyte Blockgrösse erkennen.
 Lesezugriff |
 Schreibzugriff |
Konkurrierende Dienste
Welchen Einfluss haben verschiedene Dienste die auf dem NAS eingeschaltet sind auf die Samba Performance? Sollte man die Anzahl der im Hintergrund laufenden Prozesse möglichst niedrig halten? Die Antwort sollte dieser Test veranschaulichen. Wie man erkennen kann, ist diese sehr eindeutig ausgefallen. Ein Performanceverlust ist nicht erkennbar wenn die Services aktiv sind. Im idle Modus benutzen sie nur minimale Systemressourcen vom NAS die sich in den Performance Messungen nicht niederschlagen. Also sollten die Dienste in erster Linie nur aus sicherheitstechnischen Gründen deaktiviert werden, sofern sie nicht benötigt werden..
 Lese-/Schreib-Zugriff |
Das Testsystem war das gleiche wie bereits im Teil1, ein Thinkpad T60, CoreDuo 1,83 GHz mit 3GB RAM und Betriebsystem Windows XP SP2 und NTFS formatiert. Das NAS mit Firmware 2.6.0-n(2007-09-06) ist bestückt mit zwei 500GB Platten (SAMSUNG HD501LJ, Hitachi HDT725050VLA360). Verbunden waren die Geräte über ein Cross-over Kabel.
Hier findet ihr den Link zu den Testprotokollen.
Quellen
Fehlerwurm: Sofern ihr Fehler findet oder aber Information fehlt würde ich euch bitten mir diese mitzuteilen. Ich werde das dann entsprechend erweitern/korrigieren Danke!
Alles © by daddel80, ich habe den Text hier lediglich hineinkopiert und grob aufgearbeitet. Original im Planet3DNow-Forum --Skara 23:05, 17. Dez. 2007 (CET)
