Mehrplatzversion Datenzugriff manchmal langsam

[Bernd Reinhardt]

Hallo.
Ich habe bei Kunden jeweils mehrere Arbeitsplätze. Bei einem Kunden läuft ein Programm seit ca. 2 Jahren auf folgender Konstellation:
DBF-NTX Daten werden in Zeitabständen gepackt damit keine leeren Datensätze das ganze verlangsamen.
XP bekommt keine Updates. XP SP3 und xBase Version 1.9.33. SMB2 greift hier ja nicht.

1. PC mit WIN XP mit Programm und den Daten im selben Verzeichnis
2. PC mit WIN XP und Programm auf dem Rechner. Zugriff auf die Daten von PC1 über virtuelles Laufwerk
3. PC mit WIN XP und Programm auf dem Rechner. Zugriff auf die Daten von PC1 über virtuelles Laufwerk
4. PC wie 2 und 3.

Es gibt wenige und nur kurze Schreibzugriffe. Ein Rlock und Flock nur über die Dauer vom Daten schreiben.
use
lock
schreibe Daten in Datei
unlock
Seit kurzen kommt es vor, das sich Rechner öfters am Tag gegenseitig blockieren. Dann dauert ein
use ca. 60 sec.
Normalerweise unter 1 sec.
PING usw. liefern aber immer gleich gute Werte. Das Netzwerk ist schnell.

Kennt noch jemand einen solchen Effekt, bzw. was könnte die Ursache sein.
Der Kunde wird schon so langsam ungeduldig.

Gruß
Bernd

[Koverhage]

Wurde ein PC erneuert ?

[brandelh]

Wurden die DATEN-Verzeichnisse aus der Überwachung durch den Virenscanner ausgenommen ?
Ich persönlich nutze nur noch UNC Namen, also keine Laufwerksbuchstaben im Netz, ob es aber daran liegt weiß ich nicht.

Ein SHARED USE sollte immer funktionieren, solange niemand EXCLUSIV auf der Datei ist.

[Bernd Reinhardt]

Hallo.
Es wurde an der Hardware und an der Software nichts verändert. (wurde mir hoch und heilig versprochen).
Wir hatten früher mal Probleme im Netzwerk und haben von damaliger Zeit (glaube noch von 1. im
Programm folgenden Eintrag.

DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY, 1000000)
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKDELAY, 20)

Ich habe mir nun überlegt ob es sinnvoller wäre die Zeiten und Versuche ganz weiter runter zu nehmen und den Fehler
dann über den errorblock begin sequence recover bzw. neterr abzufangen und die Anzahl der Versuche dann
quasi selber zu machen.

Ich wüsste nicht wo ich sonst noch ansetzen könnte.

Gruß
Bernd

[Bernd Reinhardt]

Hallo Herbert.
Ein shared use sollte immer funktionieren, und tut es meist.
Wenn aber mehrere Arbeitsplätze auf die Daten "LESEND" zugreifen kommt es halt doch
öfters am Tag zu Verzögerungen bis zu 1 min.
Dieses Verhalten sollte nicht sein, ist es aber LEIDER.

Gruß
Bernd

[brandelh]

Bei 6 Stationen müsste das komplett ohne diese Schalter gehen. Ich denke auch, dass es besser ist weniger Versuche (du machst 10x mehr als der Standard und wartest 20/100 statt 15/100 Sekunden; Alaska schreibt dazu 15ms aber 1/100 Sekunden als Einheit => 150ms ) automatisch zu machen und dann dem Anwender zu sagen "Datei ist gesperrt, erneut versuchen ?" ... da die Menschen sehr unterschiedliche Antwortzeiten haben, sollte das die Konflikte entschärfen.

ich würde zusätzlich auch DBE_LOCKMODE auf LOCKING_EXTENDED setzen, dadurch muss die Indexdatei nicht beim lesen gesperrt werden.
Wenn es mit dem LOCK gut funktioniert, kann man auch überlegen, ob du die Dateien offen läßt, aber eigentlich ist das Öffnen in einem LAN kein Problem.

PS: die Konstante müsste bei DBE_LOCKMODE LOCKING_STANDARD => LOCKING_EXTENDED sein, aber weiter unten wird dann von EXTENDED_LOCKING geschrieben, am Besten in der CH nachsehen

[brandelh]

Bei 6 Rechnern und nur gelegentlichem Zugriff könntest du aber die Dateien auch EXCLUSIV öffnen, das geht schneller und alle Operationen in er Datei sind viel schneller !
Nach USE müss man ja immer auf NETERR() testen und notfalls die Meldung "Datei gesperrt, bitte nochmal versuchen" bringen. Bei 6 Usern und nur kurzen Zugriffen, sollte das selten vorkommen.

Ab und zu die Indexdateien löschen und neu aufbauen ...

[Bernd Reinhardt]

Hallo.

Den Versuch mit DBE_LOCKMODE auf LOCKING_EXTENDED werde ich mal machen und die anderen Werte auf Standard setzen.
Es wird viel lesend auf die Daten zugegriffen, deshalb scheidet exclusive aus.
Auswahl von Kunden, Baustellen, Artikeln für Erstellung eines Lieferscheines.
Somit sind die Dateien lesend geöffnet und sind dann auch längere Zeit offen.
Nur beim Lieferscheindaten in die Datenbank zu schreiben wird ein RLOCK bzw. FLOCK über kurze Zeit gemacht.

Gruß
Bernd

[brandelh]

Dann solltest du auf jeden fall den LOCK_MODE ändern, dieser beschleunigt insbesondere LESE Operationen !

Auch eine Umstellung auf FOXCDX bzw. DBFCDX könnte nützlich sein, da die Indexdateien viel kleiner und Memofelder kürzer als 512 Byte sind.

Zur Problemeingrenzung solltest du auf jeden Fall eine Protokolldatei für jeden Rechner anlegen, Beispiel:

Code: Alles auswählen

cProtokoll := cPfadZumDatenverzeichnis+netname()
set alternate to (cProtokoll)
set alternate on
...
Protokoll("USE ... Befehl ausführen")
USE ...
if neterr()
   ? "Neterr()"
   Protokoll() // z.B. ohne Textparameter auswerten, sonst starten ...
   quit ?
endif
Protokoll() // z.B. ohne Textparameter auswerten, sonst starten ...
...
Protokoll("Index ... öffnen")
set index to ...
Protokoll() 
...
set alternate to
...
function Protokoll(cText) 
    static nDauer := 0, cTxt 
    if empty(cText) // "" oder NIL
       nDauer += seconds()
       if nDauer > 0.2 // alle USE set index etc. Befehle sollten in 0.2 Sekunden erledigt sein, eventuell diesen Wert ändern !
          ? dtos(date())+time(),"Sek.: ",nDauer," für ",cTxt
       endif
    else
       nDauer -= seconds()
       cText := var2char(cText) // ab 1.90.355: Var2Char( <xValue> ) --> cString 
    endif
return nil

Im Besten Fall hat nur ein Rechner Probleme (=> HARDWARE prüfen (Kabel, Netzwerkkarte), Virenscanner ? ...)
Oder immer bei einem Befehl, dann könnte man überlegen wie man genau diese Stelle schneller hinbekommt.
Bei einer zufälligen Verteilung ... könnte z.B. ein Virenscanner (der die Platten beschäftigt) auf dem Datenrechner oder ein aufwändiger 3D-Bildschirmschoner das System belasten.
Auch das Laden großer Dateien auf dem Rechner ... halt alles was die Platten bremst.

Eventuell sollte man auf diesem Rechner an SSD Laufwerke denken, die sind viel schneller. Sicherungen sind dann aber sehr wichtig, irgendwann knallt die SSD, aber auch Festplatten leben nicht ewig.

[Bernd Reinhardt]

Hallo Hubert.
Das mit dem Protokoll habe ich mir auch schon überlegt.
Vielleicht lässt sich damit der Punkt besser eingrenzen.

In der xBase Doku habe ich keine eindeutige Beschreibung der DBFDBE_Lockretry gefunden.
DBE_Lockmode steht bei ntxdbe. muss das dann bei component_order oder component_data eingetragen werden.
Gibt es Lockretry für COMPONENT_DATA und COMPONENT_ORDER oder nur für DATA


DbeInfo (COMPONENT_DATA, DBE_LOCKMODE, LOCKING_EXTENDED)
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKRETRY, 100000)
DbeInfo( COMPONENT_DATA, DBFDBE_LOCKDELAY, 15)
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKRETRY, 100000)
DbeInfo( COMPONENT_ORDER, NTXDBE_LOCKDELAY, 15)

Gibt es hierzu eine bessere Info was man im Netzwerk einstellen sollte.

Gruß
Bernd

[brandelh]

eigentlich ist es dort (in der 1.90.355) eindeutig beschrieben, intern wird LOCK_RETRY mal versucht den LOCK zu bekommen, falls es fehlschlägt wird LOCK_DELAY/100 Sekunden bis zum nächsten Versuch gewartet ... das kann dazu führen, dass sich 3 oder 4 Rechner eine ganze Zeit gegenseitig blockieren (eventuell ist intern noch ein Zufallsgenerator aktiv ?) ...

Ich würde die RETRY und DELAY Einträge löschen und sehen ob es mit Standard geht.
Die Parameterbeschreibung ist ab und an widersprüchlich, wo sieht man daher nach den Parametern ?

in der CH Datei !

Hier:
#include "Dmlb.ch"
#include "DbfDbe.ch"

wahrscheinlich muss man es für beides angeben, aber in der CH Datei sieht man genau was es wo gibt und wo nicht ...
Ansonsten probieren und den compiler entscheiden lassen

[AUGE_OHR]

hi,

... SMB2 greift hier ja nicht.

seit NT gibt es SMB (1) was bei File basierenden System ( DBF Dateien ) und Resourcen den gemeinsamen Zugriff im Netzwerk regelt.

Dann dauert ein use ca. 60 sec.

schon mal mit http://support.microsoft.com/kb/150384 versucht ?

das "rumspielen" mit DbInfo() hat nichts mit dem Problem zu tun und sollte nicht geändert werden bevor alles läuft.
wenn auf die DBF Dateien auch noch mit Cl*pper zugegriffen wird darf man LOCKING_EXTENDED nicht verwenden !

bei einem P2P mit XP fällt das "ops lock" bei wenigen Workstationen oft gar nicht auf, aber wenn eine neue Workstation
oder ein Netzwerk Drucker hinzukommt, kann das Limit überschritten sein und die Fehler häufen sich.

such mal im Forum nach "Lanman" (Workstation / Server) was für Registry Einträge für SMB (1) "wo" ( PC ) ausgeführt werden.

Welcher Datenbankserver

Du hattest ja diesen Thread geöffnet.

Für File basierenden System ( DBF Dateien ) benötigst du nur einen File Server.
Für SQL benötigst du ein Betriebssystem auf dem sich ein SQL Server installieren lässt.

File basierenden System haben das Problem der "Verwaltung" grosser Menge einzelner Dateien und entsprechen noch dem DOS Standard. Netzlaufwerksbuchstaben, begrenzt auf A-Z, werden durch Ordner und UNC Path ergänzt was auch per Internet möglich "wäre".
Bei den nächsten Windows Version von Windows "munkelt" man das die Dateiverwaltung eine SQL Datenbank sein soll ...

p.s. man kann auch mehrere Server, für den Einsatz Zweck optimiert, in einem Netzwerk haben.

[Rolf Ramacher]

Hallo Bernd

versuch das mal

Code: Alles auswählen

Hinweis zu Netzwerken:

-	OP-Locking ausschalten
beim Client HKEY/Local_Machine\System\CurrentControlSet/Services
MRXSmb\Parameters\OpLocksDisable=1
beim Server – bis Services \Lanman\Server\Parameters\EnableOplocks=0
es reicht eigentlich beim Server
-	Antivirprogramm keine dbf/ntx/cdx/fdt/dbt - scannen
-	Power.Saiving der Netzwerkkarte ausschalten
-	Auto-Disconnect Server ausschalten
-	Kein Vista ohne SP 


Langes öffnen beim use:

-	Gleiche bis Services \SharingViolation\Delay=0 bzw. Retrieves=0 – nur Server

DbAppend schon mal Probleme

1-	Einstellung nach Services \Lanmanworkstation\DisableFlushOnCleaning=1
2-	Latenzzeit ist eintscheidend – testen mit ping z.B. 

[brandelh]

Für File basierenden System ( DBF Dateien ) benötigst du nur einen File Server.
Für SQL benötigst du ein Betriebssystem auf dem sich ein SQL Server installieren lässt.

das könnte man so interpretieren, dass man "spezielle" Betriebssysteme braucht. Dem ist nicht so.

Grundsätzlich kann jedes NT++ System sowohl Client als auch Server Dienste übernehmen (bei XP Home bin ich mir nicht sicher).
Ein Windows 2000 Pro Rechner würde als Server sogar viele davon eliminieren ...
Ein SQL Server läuft auf jedem dieser Systeme ... und MySQL oder PostGreSQL mit SQLexpress (sofort) oder Xbase++ 2.0 (irgend wann einmal) würde deine Probleme auch für die Zukunft eliminieren.
Ich persönlich würde IMMER SQLexpress vorziehen und ein für alle mal auf Datenobjekte setzen.
Ab 2.0 sind gleichnamige schnelle möglich, vorher macht man halt eine Klasse mit dem Datenmodell und den nötigen Methoden ...

[AUGE_OHR]

hi,

das könnte man so interpretieren, dass man "spezielle" Betriebssysteme braucht. Dem ist nicht so.

als File Server "könnte" man auch ein modernes NAS nehmen aber auf dem könntest du nicht unbedingt einen SQL Server installieren.

[georg]

Hallo,


also, NAS für Netzwerkzugriff von vielen Arbeitsplätzen - irgendwie bin ich da inzwischen ein gebranntes Kind.

Mein häusliches Ready NAS NV+ zeigt inzwischen deutliche Ausfallerscheinungen: kein Netzwerktraffic, aber beim Öffnen einer 300 KB grosse Excel-Datei "Netzwerk überlastet".

An meinem Arbeitsplatz hat man die Novell-Server durch NAS ersetzt, und jetzt sind die Latenzen im Netzwerk so gross, dass Xbase-Programme, die auf LIBMYSQL bzw. SQLXpp zugreifen, nicht mehr laufen. Das gleiche Programm, auf die lokale Platte kopiert, funktioniert einwandfrei.

Aber vielleicht sind das ja die zwei Ausnahmen, während alle anderen diese Probleme nicht kennen.

[Bernd Reinhardt]

Hallo.
War gestern beim Kunden und habe mir die Sache mal angesehen.
Die Zugriffszeiten und Anzahl der Versuche (DbEinfo) auf Standard gesetzt.
Es ist tatsächlich so, wenn zwei oder drei Programme lesend auf Daten zugreifen,
dann blockieren die sich gegenseitig bis zu 20 sec.
Ich muss mein logging noch verfeinern ob das bei use oder index passiert.
Das Programm läuft ansonsten ohne Probleme.
In der Systemstemsteuerung habe ich mir mal die geöffneten Dateien angeschaut.
Es sind bis zu 47 Dateien die kurzfristig offen sind, das dürfte aber auch nicht stören.

Je nachdem wie die Programme zeitlich die Dateien lesend öffnen kommt es zu dieser Verzögerung.
Da ständig etwas gemacht wurde, kann die Netzwerkkarte nicht in Standby gehen.
Das Netz selbst ist auch ausreichend schnell.
Kann mir das Verhalten nicht erklären.

Gruß
Bernd

[brandelh]

zu NAS:

Man muss schon sehr genau ausloten, was man braucht ...

ich habe hier ein Synology DS411slim ( http://www.synology.de/products/product ... m&lang=deu)
Eine normale Xbase Anwendung (Suchen, Datensatz bearbeiten etc.) mit 2 bis 3 Personen ist damit kein Problem ... solange keiner große Dateien lädt
Ich hatte diese gewählt, weil sie (auch dank der 2.5" Platten) sehr leise und stromsparend ist ( max 15 Watt im Betrieb) ...

Mehr würde ich der kleinen aber auch nicht zumuten, schließlich gibt es für jedes Produkt eine Anwederzielgruppe, und dieses hier
http://www.synology.de/products/product ... B&lang=deu

könnte wahrscheinlich mehr erledigen ... ABER es braucht 30 Watt im Betrieb und wenn die Hardware versagt, wie kommt man an die Daten ?

Aktuell würde ich mir lieber einen leisen (Server)-PC mit der 4. Generation der i5 holen.
In der CT haben sie so einen Rechner auf 10 Watt im IDLE gebracht, mit einer SSD bestückt ist der rasend schnell wenn wirklich was zu erledigen ist.
Mit einem Server Betriebssystem, lokaler DBF und Terminalserver Anwendungsverteilung erscheint mir das als der aktuell sinnvollste Weg Xbase++ Anwendungen im normalen Rahmen zu verteilen.
Natürlich kann man auch noch einen SQL Server darauf laufen lassen, wenn man die DBF nicht mehr möchte.

Und wenn der Rechner defekt ist, kann man leicht Ersatzteile beschaffen oder die SSD gleich an einen anderen hängen ...

NAS nimmt einem viel Arbeit ab, aber ein PC ist flexibler ...

[brandelh]

Es ist tatsächlich so, wenn zwei oder drei Programme lesend auf Daten zugreifen,
dann blockieren die sich gegenseitig bis zu 20 sec.

das kann durch LOCKING_EXTENDED besser werden ...

In der Systemstemsteuerung habe ich mir mal die geöffneten Dateien angeschaut.
Es sind bis zu 47 Dateien die kurzfristig offen sind, das dürfte aber auch nicht stören.

pro Anwendung / User oder insgesamt ?

DBF Dateien sind in der Regel ja nicht wirklich groß, aber der Zugriff erfolgt SHARED in 512 Byte Blöcken.
Eine moderne Festplatte lädt 100 MB Dateien auf einmal so schnell wie einen 512 Byte Block ... mit einer SSD kann man das beschleunigen.

[Tom]

Ich erinnere mich daran, dass ein Alaska-Mitarbeiter auf einer der letzten DevCons davon berichtet hat, dass es vor allem in heterogenen Netzwerken mit einigen schwächeren Rechnern/Netzwerkkarten/ähnlichem dazu kommen kann, dass durch die Folge der Rechneranmeldung das Performanceniveau allgemein sinkt, weil die schwächste Komponente mit hoher Priorität versorgt wird. Es gab auch einen Hinweis darauf, wie man das mit einem eigenen Tool beeinflussen könnte. Vielleicht erinnert sich jemand besser als ich.

[Koverhage]

Ich habe das so im Kopf: Sobald ein schneller Rechner dabei ist, kommen die langsamen kaum mehr zum Zuge.
Kann mich aber auch täuschen.

Die Frage die sich mir bei dem Thread stellt, wird alleine beim Lesen ein Lock ausgeführt ?

[brandelh]

Die Frage die sich mir bei dem Thread stellt, wird alleine beim Lesen ein Lock ausgeführt ?

Hallo Klaus,

sobald eine Indexdatei im Spiel ist, wird bei jeder Satzbewegung (also Skippen, locaten, seeken) die komplette Indexdatei gesperrt (automatisch intern).
Nur wenn man auf LOCKING_EXTENDED geht, dann wird nur noch für das Schreiben in Dateien auch die Indexe gesperrt.

[AUGE_OHR]

An meinem Arbeitsplatz hat man die Novell-Server durch NAS ersetzt ...

oh je
Da man ja mehr als 1 x Server im Netzwerk haben kann verwende ich die alten Novell Server v3.2x ( + v4 NLM) weiterhin als File Server für DBF Dateien im Intranet.

mit File Server wollte ich nur andeuten das keine weiter Dienste laufen (müssen) und das dass OS sich nur um die Dateien und Verzeichnisse kümmert.

[brandelh]

Irgendwann sind die alten Kisten einfach nicht mehr zuverlässig genug ...

[AUGE_OHR]

Irgendwann sind die alten Kisten einfach nicht mehr zuverlässig genug ...

naja ... neue Hardware geht schneller kaputt !!!