PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : SuSE 10.2 + Samba -> Performance-Einbuße bei Access-Datenbank



Blade
20.01.07, 12:01
Hallo Zusammen,
nach einigen Stunden der Konfiguration läuft nun der neue File-/E-Mail-/Web-/etc. Sever mit rund 30 Clients, vornehmlich Windoof-Kisten. Der alte Server SuSE 9.0 wurde aus Sicherheitsgründen gekillt und ein neues 10.2er Betriebssystem installiert.

Bei gleicher Samba-Konfiguration zeigt sich nun folgendes Problem, zu dem ich im Moment keinen Rat weiß, und welches unter 9.0 nicht auftrat:
- Unter 10.2 gleiche Samba-Konfiguration wie unter 9.0 vorgenommen
- Access-Datenbank (Access97) auf Samba-Server installiert
- Frontends der Access-Datenbank sind auf den Workstations der Clients installiert
- Wenn nur ein Client auf die Datenbank zugreift, läuft sie ganz normal schnell
- Wenn zwei oder mehr Clients darauf zugreifen, ergeben sich beim Fenster Wechsel, besonders beim Schließen von Anwendungs-Fenstern in der Datenbank deutlich merkliche Verzögerungen im Ablauf (Performance-Einbrüchhe). Es schein so, als wartet die Datenbank ganz kurz und führt dann erst verzögert den Befehl aus. Fehlfunktionen/Fehlermeldungen gibt es keine.

Bin für jeden Hinweis dankbar.

chris_e
29.01.07, 12:43
Hallo,

habe genau das gleiche Problem, jedoch beim Update von SuSE 9.0 auf SuSE 9.3. Vermutlich dürfte es an der neueren Samba-Version liegen. Habt Ihr dazu schon eine Lösung?

Blade
29.01.07, 18:43
Hallo chris_e,
tut mir Leid für Dich, bin aber froh, dass ich mit dem Problem nicht allein rumdoktere. Sobald ich etwas herausgefunden habe, werde ich es hier posten.

Blade
29.01.07, 20:24
Habe heute Abend mal wieder das Samba-Howto studiert und folgenden Passus gefunden:

Regardless, oplocks should always be disabled if you are sharing a database file (e.g., Microsoft Access) between multiple clients, because any break the first client receives will affect synchronization of the entire file (not just the single record), which will result in a noticeable performance impairment and, more likely, problems accessing the database in the first place. Notably, Microsoft Outlook's personal folders (*.pst) react quite badly to oplocks. If in doubt, disable oplocks and tune your system from that point.
Eintragen kann man das im global- und share-Abschnitt der Server-Config mit:

You can disable oplocks on a per-share basis with the following:

[acctdata]
oplocks = False
level2 oplocks = False

The default oplock type is Level1. Level2 oplocks are enabled on a per-share basis in the smb.conf file.
Alternately, you could disable oplocks on a per-file basis within the share:

veto oplock files = /*.mdb/*.MDB/*.dbf/*.DBF/

Habe es heute Abend gleich mal in die Samba.Config im Büro eingetragen und werde morgen vom Effekt berichten. Die Erklärung im Samba-Howto liest sich schlüssig. Ich hatte schon vermutet, dass es irgend wie mit den Zugriffsrechten zusammenhängt.

chris_e
01.02.07, 17:56
Hallo Blade,

habe diese Parameter in meiner smb.conf ausprobiert, aber leider keine nennenswerte Verbesserung festgestellt. Hast du andere Erfahrungen gemacht?

Das mit den "veto oplock files" hatte ich auch früher schon probiert, hat auch nichts gebracht.

Blade
01.02.07, 18:49
Hallo chris_e,
sorry, aber ich kam jeden Abend recht spät heim.
Leider auch nein -> trotz Eintrag keine Veränderung zu verspüren.
Ich werde weiter nach der Ursache forschen und mich umhören. :(

emba
03.02.07, 17:00
wenn ihr der ursache wirklich auf den grund gehen wollt, hilft - neben trial&error - nur folgendes:

- die zwei sambaversionen (die "gute" alte und die "langsamere" neue) hinsichtlich defaultparameter (testparm -sv) vergleichen

- den netzwerkverkehr zwischen den maschinen analysieren

- traces der smbds analysieren

- zu guter letzt: gdb/ valgrind

greez

Blade
03.02.07, 19:47
Danke für Deinen Tipp, gerade mal wegen testparm -sv ...
Doch mein alter Server SuSE 9.0 ist leider schon platt gemacht,
darum brint mir der Vergleich leider nichts mehr.
Werde aber mal den tesparm mit meinem SuSE 9.3 und 10.2er
Server fahren. Mal sehen wie wir da weiter kommen und
die Ursache eingrenzen können.