Inoffizielles deutsches Xbase-Forum

Hallo Forum,

bei einem Anwender läuft eine von mir geschriebene Xbase-
Netzwerkapplikation, der Server unter Linux/Samba und die
Clients unter Win7 64Bit aber teilweise auch noch unter WinXP
32Bit. Bei der Generierung einer Freinummerndatei ist mir
aufgefallen, dass die Win7 Clients inakzeptabel viel länger
brauchen als die WinXP Clients. Daraufhin habe ich ein kleines
Testprogramm geschrieben welches eine leere DBF mit einem
7 Bytes langen Character-Feld erzeugt, diese exklusiv (!) öffnet,
10000 leere Datensätze anfügt, alle Datensätze mit GOTO
durchläuft, alle Datensätze mit SKIP durchläuft und schließlich
alle Datensätze mit REPLACE und SKIP durchläuft. Hier sind die
gemessenen Zeiten, und zwar ausgeklammert für den Win7
Client und (eingeklammert) für den WinXP Client:

10000x APPEND BLANK: 32.04 Sek. (0.13 Sek.)
10000x GOTO: 0.03 Sek. (0.02 Sek.)
10000x SKIP: 0.05 Sek. (0.01 Sek.)
10000x REPLACE + SKIP: 16.21 Sek. (0.14 Sek.)

Auffallend ist, dass der Win7 Client für Schreiboperationen auf
die DBF (APPEND BLANK / REPLACE) inakzeptabel viel mehr Zeit
braucht als der WinXP Client, beim APPEND BLANK sogar die
etwa 250-fache Zeit ! Wurde die DBF nicht auf dem Server über
das Netzwerk sondern auf den lokalen HDs der Clients bearbeitet,
waren beide Clients etwa gleich schnell.

Deaktivierung von Anti-Viren Scannern sowie von SMB2 auf den
Win7 Clients brachte keine spürbar kürzeren Zeiten. Was könnte
die Ursache sein ?

Gruß
Karl

Karl Fischer hat geschrieben:der Server unter Linux/Samba und die Clients unter Win7 64Bit aber teilweise auch noch unter WinXP 32Bit.

eine interessante Kombination mit 3 "Unbekannten" ...
Linux/Samba als File Server haben wohl nicht so viele am laufen ...

Samba konnte in den älteren Versionen kein SMB2 ... XP kennt nur SMB1 aber die Win7 Stationen möchten gerne SMB2 ...

für die beschriebenen Symptom gibt es einige "Ops Lock Hacks"

if DbAppend()/DbCommit() are slow ( kb825433 )
•
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters\DisableFlushOnCleanup = 1

aber es ist nur ein Teil der Lösung denn es gibt auch welche für den Server. Dummerweise braucht man dafür eine Windows Registry ...
(kb296264, kb150384, kb825433 , Q844350 und Q843418)

Eine Erfahrung die ich vor Kurzem machen mußte war, das ein Programm im Netzwerk nur deswegen extrem langsam lief, weil der Netzwerkpfad nicht gemappt, sondern als UNC angegeben war. Das war zwar mit einem Windows-Server, aber vielleicht ist das ja auch auf Deine Kombination übertragbar?

Jan

ich habe auch einen Samba Server laufen und Kunden von mir auch. Man müßte mal einen Blick in die Smb.conf werfen um zu sehen, was da drin steht. Da könnte noch die eine oder andere Schraube sein, an der man evtl. drehen kann.

Hallo Manfred,

hier ist die smb.conf:

[global]
workgroup = FISCHER
server string = KFLI03
printing = cups
printcap name = cups
load printers = yes
log file = /var/log/samba/%m.log
max log size = 50
oplocks = no
level2 oplocks = no
kernel oplocks = no
# =============CODEPAGESETTINGS==============================
# Wichtig !! Dient zum Setzen der Codepage, damit Umlaute
# richtig dargestellt werden. Es muss in Locale die richtige
# Codepage eigestellt sein und zwar: de_DE.ISO-8859-1
unix charset = ISO-8859-1
dos charset = 850
display charset = ISO-8859-1
# ===========================================================
security = ADS
encrypt passwords = yes
log level = 2
socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
os level = 2
veto files = /*.eml/*.nws/riched20.dll/*.(*)/
# Winbind Options
local master = no
preferred master = no
wins server = 192.168.0.241
domain master = no
domain logons = no
name resolve order = host wins lmhosts bcast
winbind separator = /
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
template shell = /bin/bash
winbind use default domain = yes
winbind enum users = yes
winbind enum groups = yes
password server = ...
realm = Fischer.local
client use spnego = yes
# [printers]
# comment = Alle Drucker
# path = /tmp
# public = yes
# guest ok = no
# writeable = no
# printable = yes
# [homes]
# comment = User Heimatverzeichnis
# path = /home/%U
# browseable = no
# writeable = yes
# guest ok = no
# public = no
[daten]
comment = Datenverzeichnis
path = /var/shares/daten
admin users = @domänen-admins
writeable = yes
create mask = 2660
directory mask = 2770
force create mode = 2660
force directory mode = 2770

Gruss
Karl

Hallo Karl,

hast Du mal (nur zum test) die Oplocks auf Yes gesetzt? Ich hatte das auch mal bei einem Kunden. Es ist zwar nicht die goldene Lösung, kann aber das Tempo verändern. Läuft der Linux Server direkt, oder z.b. in einer VM?

Hallo Manfred,

oplocks "yes" hatten wir, und es hat uns Probleme bereitet. Der
Linux-Server läuft direkt ohne VM ...

Gruß
Karl

Karl Fischer hat geschrieben:oplocks "yes" hatten wir, und es hat uns Probleme bereitet.

die Frage welche Samba Version du benutzt ist noch offen !

wenn du XP Clients hast dann könnte deine Samba Version < v3.5 sein womit es sich auf SMB1 reduzieren würde.
unter XP musstest du, mittels Lanmanager, ein Laufwerk "map"(pen) ... machst du das auch beim Win7 Client ?

wenn dein Samba Server > v3.5 ist dann sollte er SMB2 beherrschen so das du es mit UNC-Path versuchen kannst ob sich ein Unterschied ergibt.

was allgemein die Linux / Samba Server Seite angeht würde ich da mal in deren Foren nachfragen.
Windows Server mögen "gemischte" Client OS() Versionen nicht so gerne ...

Frage : hast du kb825433 ausprobiert ?

Samba Version: 3.5.16

Auf Win7 Client bisher versucht:

- SMB2 deaktiviert: keine Veränderung
- UNC-Pfad: keine Veränderung
- kb825433: keine Veränderung
- Oplocks-Einstellungen: keine Veränderung

Gruss
Karl