Schlechte SAMBA/CIFS Performance

[vanquish]

Hallo,

ich habe nach langem Überlegen meinen Fileserver auf Solaris/ZFS (ESXi Basis) umgestellt. Nach anfänglichen Schwierigkeiten läuft der Server mit den Shares.
Nur leider ist die Performance ziemlich schlecht. Mehr als ~10 MB/s schreibend und ~ 15 MB/s lesend sind nicht drin.

An der Hardware sollte es nicht liegen: Phenom X4, 3x1 TB RAIDZ, 8 GB RAM, INTEL GB LAN

Eventuell liegt es an der Tatsache, dass die Platten verschlüsselt sind. Was ich mir aber nicht vorstellen kann. Selbst mein Uralt-NAS mit einem Marvell Chip und 800 MHz schafft mit aktivierter Verschlüsselung unter Samba ~ 5 MB/s schreibend. Von meinem "alten" Linux-Server, der auf gleicher Hardware lief, ist das Solaris-System von der Performance her meilenweit entfernt.

Im Moment bin ich ratlos ...

 

[bluesunset]

Nimm NFSv4 oder einen Samba4 Server in Verbindung mit Vista/Win7 Clients (SMB2).

 

[gea]

Ich würde mal ein dataset ohne Verschlüsselung vergleichen.
Auch sollten auf Windows Seite keine Kopiertools wie Teracopy etc benutzt werden
siehe SMB reads are slow on OpenIndiana + NAPP-IT

zum ESXi und dem virtualisierten SAN:
Hat Solaris direkten Zugriff auf den Controller und die Platten per Pass-through?

ps:
Solaris benutzt per default kein SAMBA sondern einen eigenen CIFS server im kernel.

 

[vanquish]

@ bluesunset:

NFS ist zwar schön. Aber selbst Windows 7 Professional hat keinen eigenen NFS Client mit an Board. In einer gemischten Umgebung ist leider SAMBA/CIFS der kleinste gemeinsame Nenner.

@ gea:

Die unverschlüsslte Variante werde ich morgen einmal testen. Heute wird das nichts mehr.
Der Datenaustasuch fand jeweils mit dem Windows Explorer statt. Es waren keine speziellen Tools o. ä. im Einsatz.
Da ich den Server jetzt doch nicht auf ein neues System aufgesetzt habe, konnte ich die Platten "nur" mittels RDM weiterreichen. Ist zwar nicht ganz das gleiche wie DirectPath I/O aber es sollte von der Performance nicht allzuviel ausmachen. Wichtig war mir bei dieser Lösung ohnehin eher die Tatsache, dass ich die Platten einfach ausbauen kann und ich im Notfall mittels Solaris Boot-CD direkt auf die Platten Zugriff habe.

 

[gea]

@ bluesunset:
Da ich den Server jetzt doch nicht auf ein neues System aufgesetzt habe, konnte ich die Platten "nur" mittels RDM weiterreichen. Ist zwar nicht ganz das gleiche wie DirectPath I/O aber es sollte von der Performance nicht allzuviel ausmachen.

Ich würde mal zum Vergleich Solaris auf der Hardware installieren.
Ich bin überzeugt, daß es erheblich schneller ist.

Mit pass-through bleibt diese Performance nahezu erhalten.

 

[vanquish]

Hallo,

nachdem ich vergangenes Wochenende endlich dazu gekommen bin meinem Problem zu Leibe zu rücken, möchte ich hier noch das Ergebnis bzw. die Lösung meines Problems für alle anderen.

Zu meinem Eingangspost ist hinzuzufügen, dass sich die genannte Schreib- und Leseperformance zum damaligen Zeitpunkt auf eine Ressourcenzuteilung von zwei CPU-Cores für Solaris unter ESXi bezog. Wurden auch die beiden anderen Kerne noch zur Verfügung gestellt, stieg die Performance auf ~ 13 MB/s bzw. ~ 17 MB/s. Mir fiel dabei auf, dass alle Cores beim Schreiben oder Lesen immer fast vollständig ausgelastet waren. Was auch erklärt, dass die Performance auf einem Solaris ohne ESXi-Unterbau wie erwartet war. Davon ausgehend habe ich zunächst die Performance auf einem Solaris (verschlüsselt und unverschlüsselt) getestet. Als Testplatte kam eine Samsung Spinpoint F1 HD753LJ zum Einsatz. Diese ist etwas älter als meine genannten 1-TB-Platten. Performancetechnisch nehmen sie sich aber nicht viel.
Der einfache Lese- und Schreibtest (ISO-File) brachte ~ 55 MB/s bzw. ~ 40 MB/s. Das aktivieren der Verschlüsselung hatte keinen signifikanten Einfluss auf die Performance. Die Werte unterliegen meiner Auge-*-Pi-Toleranz. --> Das Problem liegt also irgendwo zwischen ESXi und dem OS.

Ein Windows 7 mit durchgeschalteter Platte brachte fast die gleichen Werte wie unter einer nativen Systemumgebung ~ 50 MB/s bzw. ~ 35 MB/s. Also habe ich zum ESXi näher recherchiert und bin auf den folgenden Beitrag gestossen:

Troubleshooting a high system CPU usage issue on Linux/Solaris

Nachdem ich den MTU-Wert des ESXi-LAN-Hostadapters und des Solaris-LAN-Adapters von 1500 auf 9000 angehoben habe, war das Problem gelöst. Die CPU-Last sank auf Normalniveau und die SAMBA-Performance war endlich so wie erwartet ~ 48 MB/s bzw. ~ 34 MB/s. Aber Achtung: Der Router muss Jumbo-Frames Unterstützen! Die Lösung ist also nicht für jeden Anwendungsfall geeignet.

Ich hoffe, dass ich dem ein oder anderen helfen und viel Arbeit ersparen konnte.

 

[bluesunset]

Da ist trotzdem noch was im argen. Deine 30+ MB/sec schafft auch ein Dual P3 mit AES ohne Jumbo Frames.

 

[vanquish]

Das kommt von der Performance der Platten schon hin. Mehr liefern meine "alten" Platten (~3 oder 4 Jahre) einfach nicht.
Samsung SpinPoint F1 mit 750 GByte : Benchmarks: FileCopy Test - Artikel Hartware.net
Man kann sie mit den heutigen Platten einfach nicht vergleichen. Unter Laborbedigungen sind es sicher ein paar MB/s mehr.
Ich plane aber bereits die Platten im Laufe des Jahres durch grössere zu ersetzen. Evtl. werde ich aber bei Gelegenheit einmal eine aktuelle WD mit 5900 u/min. testen und sehen was dabei heraus kommt.
Wenn Du einen Vorschlag hast wie ich die Performance erhöhen kann, nehme ich ihn gerne an. Ich will auch nicht ausschließen, dass das System mehr zu leisten vermag und bin für konkrete Hinweis natürlich dankbar.

 

[bluesunset]

60MB/sec schaffen Samsungs ersten SATA HDDs mit 160GB (zwei 80GB Magnetscheiben) aus anno 2004.
Kannst du mal ein normales Linux mit XFS als Dateisystem zum testen aufsetzen?

 

[gea]

Unter gleichen Rahmenbedingungen sollte XFS bei geringerer Datensicherheit und weniger Features allenfalls minimal schneller sein.
Wie greift Solaris denn auf die Platte zu: per pass-through (direkter Hardwarezugriff) oder via ESXi datastore als virtuelle disk.

In zweiten Fall wären die Datenraten ok.