Schreibgeschwindigkeit auf Sambashare programmabhaengig

19/11/2015 - 14:22 von Peter Blancke | Report spam
Guten Tag,

in einem Netzwerk laufen Win7-Prof-64-Bit-Kisten und ein Sambaserver
(Debian/Wheezy, Samba Version: 2:3.6.6-6+deb7u5).

Bei _einem_ Programm (Programm "Strakat", so eine Art CAD-Software)
ist die _Schreib_geschwindigkeit auf ein Samba-Share etwa zehnmal
langsamer als ein Schreiben auf ein freigegebenes Share auf einer
der Windows-CLients im gleichen Netzwerk. Die Lesegeschwindigkeit
ist hingegen bei beiden, Samba-Share und Windows-Share, gleich.

Der Programmhersteller kann sich das nicht erklaeren, sagte mir
aber, dasz beim Schreibvorgang die zu schreibende Datei in "sehr
vielen kleinen Haeppchen" geschrieben ist. Tja, was solche
Auskuenfte auch immer aussagen. Moeglicherweise meint er damit, dasz
die zu schreibende Datei zig mal zum Schreiben geoeffnet und wieder
geschlossen wird, er wuszte es aber nicht genau.

Zugriffe anderer Programme (grosze Word-Dateien etc.) als auch
Kopieraktionen groszer Dateien zeigen keine Zeitunterschiede im
Schreiben auf ein Samba-Share oder ein Share auf einem
Windows-CLient.

Ausschlieszlich das Programm "Strakat" zeigt beim _Schreiben_ diese
miserablen Zeiten.

Aber dieser Hinweis auf das Schreiben "in sehr vielen kleinen
Haeppchen" gibt mir zu denken. In welche Richtung musz ich bei der
Sambakonfiguration suchen, wo ich die Schreibgeschwindigkeit
optimieren koennte?

Grusz,

Peter Blancke

Hoc est enim verbum meum!
 

Lesen sie die antworten

#1 Marcel Mueller
19/11/2015 - 15:12 | Warnen spam
On 19.11.15 14.22, Peter Blancke wrote:
Bei _einem_ Programm (Programm "Strakat", so eine Art CAD-Software)
ist die _Schreib_geschwindigkeit auf ein Samba-Share etwa zehnmal
langsamer als ein Schreiben auf ein freigegebenes Share auf einer
der Windows-CLients im gleichen Netzwerk. Die Lesegeschwindigkeit
ist hingegen bei beiden, Samba-Share und Windows-Share, gleich.

Der Programmhersteller kann sich das nicht erklaeren, sagte mir
aber, dasz beim Schreibvorgang die zu schreibende Datei in "sehr
vielen kleinen Haeppchen" geschrieben ist.



Das dürfte als Erklàrung reichen. Offenbar cachet Windows hier etwas, wo
Linux eher auf Datenkonsistenz setzt. Oder aber eine Optimierung wird
von Samba nicht unterstützt.

Tja, was solche
Auskuenfte auch immer aussagen. Moeglicherweise meint er damit, dasz
die zu schreibende Datei zig mal zum Schreiben geoeffnet und wieder
geschlossen wird, er wuszte es aber nicht genau.



Das wàre auch unter Windows lahm.
Es dürften eher Schreibzugriffe auf eine geöffnete Datei mit sehr
kleinen Größen (z.B. nur eine Hand voll Bytes) sein.

Aber dieser Hinweis auf das Schreiben "in sehr vielen kleinen
Haeppchen" gibt mir zu denken. In welche Richtung musz ich bei der
Sambakonfiguration suchen, wo ich die Schreibgeschwindigkeit
optimieren koennte?



Wàre erst mal zu klàren, ob das überhaupt möglich ist.

Ich würde mal einen Netzwerk-Trace mitlaufen lassen (Wireshark) und
gucken, was da bei der Kommunikation mit dem Windows-Server anders
làuft. Der erste Ansatz wàre das Protokoll-Level. Vielleicht kommt mit
Samba keine SMB2 Verbindung zustande. SMB2 ist auf Durchsatz optimiert
worden. Das war vorher ziemlich ineffizient.

Eine mögliche Maßnahme wàre eine Aktualisierung der Samba-Version.
Ältere Versionen implementieren nicht alle Protokolloptionen.
Ansonsten müsste man mal einen Blick auf die Captures werfen, was da
anders làuft. Da können hier bestimmt auch einige unterstützen.

Ein Blick in die Konfiguration könnte auch helfen. Aber ich halte es für
unwahrscheinlich, dass etwas derart performancerelevantes zwar
existiert, aber per Default abgeschaltet ist. Das macht man eigentlich
nur, wenn es (noch) nicht zuverlàssig funktioniert - womit wir wieder
beim Samba-Update wàren.

Ein Bug-Report bei Samba könnte auch sinnvoll sein. Damit der überhaupt
bearbeitet wird, müssen die Wireshark-Captures mit Windows und mit Samba
für denselben Speichervorgang (gleiche Datei) dabei sein. Daraus können
die automatisierte Testfàlle generieren. Ferner sollte der Test gegen
eine aktuelle (stabile) Sambaversion laufen und nicht gegen etwas Altes.
Andernfalls macht da kaum jemand einen Finger krumm. Mit einem solchen
Testfall ist es aber für die Programmierer vielleicht gar nicht so viel
Arbeit. Und solche Tickets werden oft bevorzugt behandelt. Da es nicht
sicherheitsrelevant ist, kommt der Fix dann aber auch erst in der
nàchsten Version. Es sein denn, man kompiliert Samba selber.


Marcel

Ähnliche fragen