bricktop
Goto Top

W2k3 Server, DOS-Programm und mehr als 1 Benutzer ist Langsam

Hallo,

super Forum face-smile Habe hier schon sehr viele gute Ratschläge befolgt - Vielen Dank dafür.
Nun habe ich folgendes Problem und vielleicht hat ein anderer Admin noch eine Idee?!

Server: W2k3 - Workstations XP - FastEthernet-Netzwerk (Switch von LevelOne)
Auf dem Server ist unser Warenwirtschaftsprg. gespeichert. Ist ein DOS-Programm aber das lief bis jetzt (Server NT, WS: W98) super. Seit der Umstellung auf W2k3 und XP läuft das Programm nur dann schnell, wenn nur einer in dem Programm arbeitet face-sad

Sobald >1 Benutzer mit dem Programm arbeiten, wird es sehr langsam - Er pausiert bei Eingaben (sobald er was vom Server benötigt) teilweise 1-2 Sekunden. Das seltsame daran: Das ist nicht immer so... Manchmal geht es gewohnt schnell. Umstellung auf 100MBit Half brachte auch nichts (empfiehlt der Hersteller der Software)

SMB signieren wenn angefordert=Aktiv / SMB immer signieren = Deaktivert (Bei Server und WS über GPO habe ich auch schon ausprobiert. Brachte nichts.

Habe schon so einiges probiert - Brachte alles nichts. DNS / NetBios ist da und läuft auch 100%
Bin da echt bald am Ende...

Für jeden Ratschlag/Tip bin ich echt dankbar... Die Leute in der Firma jammern bereits...

Lg
BrickTop

p.S: Gibt es da eine Einstellung die ich übersehen habe? Wie z.B: SHARED USE = FAST ?! face-wink

Content-Key: 23350

Url: https://administrator.de/contentid/23350

Ausgedruckt am: 29.03.2024 um 05:03 Uhr

Mitglied: Biber
Biber 11.01.2006 um 20:13:36 Uhr
Goto Top
Moin BrickTop,

ist ein bisschen früh, um da weise Tipps zu geben..
Dazu müsste man/frau wenigstens wissen, was für eine Applikation aus ungefähr welchem Entstehungszeitraum das war.

Die meisten dieser WW-Programme aus älteren Tagen sind ja Clipper-Programme, die wiederum auch damals schon eine Menge (Applikations-unabhängige) Parameter vorgesehen hatten für Speichernutzung/temporäres Verzeichnis/ max. File Handles und ähnliches und/oder sich über externe Variablen oder config-Dateien beeinflussen ließen.

Ohne solche dokumentierten Parameter sehe ich wenig Chancen - so auf Verdacht lassen sich bestenfalls die Umgebungsvariablen für TEMP/TMP überprüfen (ob die lokal sind oder ob er etwa einen Netzwerkordner für die temporären Trümmer nutzt) und ob vielleicht die Anzahl FileHandles in der config.nt der Engpass ist.

Das Share-Verhalten (also die Behandlung von verschiedenen Prozessen/Usern geöffneter Dateien) bekommst Du IMHO nicht mehr konform zur damaligen SHARE.exe hin bei Windowsversionen diesseits von WinNT.

Gibt es noch Details über die Applikation?`
Gruß Biber
Mitglied: Samtpfote
Samtpfote 11.01.2006 um 20:49:01 Uhr
Goto Top
1. wenn Clipper-App schließe ich mich Biber an: config.sys Finetuning...
2. Versuchs doch mal mit den Kompatibilitätseinstellungen bei der exe.
Mitglied: BrickTop
BrickTop 11.01.2006 um 21:19:53 Uhr
Goto Top
@Biber
Vielen Dank erstmal für Deine Hilfe. Die Anwendung ist eine alte Warenwirtschaft (Erstmalig so um 1983 entwickelt. Die DOS Version wurde jedoch noch bis ca. 97/98 gepflegt. Zum Einsatz kommt Datenbanktechnik von MicroFocus. Geschrieben ist die Software (glaube ich) mit Cobol)

Die Idee mit der Config.NT hatte ich (... vergessen) noch gar nicht. Das werde ich morgen in der Firma gleich mal testen.

Temp sollte lokal sein - Werde ich morgen aber auch nochmal nachschauen.

@Samtpfote
Auch Dir thx. Config.Nt wird gecheckt - Kompatibilitätseinstellungen hatte ich probiert - Bringen nichts.

Werde das morgen mal probieren und berichten (Für evtl. weitereführende Hilfe wäre ich dankbar)

Gruß
BrickTop
Mitglied: Samtpfote
Samtpfote 11.01.2006 um 21:27:50 Uhr
Goto Top
Habe bei einem Kunden in einer W2K3/XP Umgebung eine ca. 20 jährige Cobol App mit folgenden Werten in der Config.NT am Laufen:

FILES=100
FCBS=25,25
STACKS=9,128

Es gab am Anfang erhebliche Probleme durch Verzögerungen beim Zugriff.... ich kann mich leider nicht mehr erinnern, wodurch ich es zum Laufen gebracht habe... wenn Du möchtest kann ich ein wenig recherchieren. (BTrieve Datenbank + Novell 3.12 Server)

A.
Mitglied: Biber
Biber 11.01.2006 um 21:56:08 Uhr
Goto Top
@BrickTop/@Kitkat
FILES=100 --> ist auf jeden Fall sinnvoll
FCBS --> diese File Control Blocks: ja bei Baujahr '83... aber nicht mehr verwendet bei DOS'en nach 3.3; schaden aber auch nicht.
Stacks=9,128 oder auch höher (15,256)
eventuell noch Buffers=40 dazu.

@all:
Mit den Kompatibilitäts-Optionen hatte ich auch schon mal rumexperimentiert.
Ich konnte ABSOLUT KEINE Effekte feststellen, weder positiv noch negativ.
Haben die bei irgendjemand schon mal geholfen?
Mitglied: Samtpfote
Samtpfote 11.01.2006 um 22:18:27 Uhr
Goto Top
@nager:
jaaaaaaaaaa.... es gab ein paar alte windows 3.1 programme die ich sonst nicht zum Laufen gebracht hätte.
Mitglied: Biber
Biber 11.01.2006 um 22:24:44 Uhr
Goto Top
es gab ein paar alte windows 3.1 programme die ich sonst nicht zum Laufen gebracht hätte.

Na, wenn Du Deine Krallen funkeln lässt, laufen die freiwillig...
Glaube nicht, dass M$'s Kompat-Features was damit zu tun haben face-wink

Grüße an die Samtigste
Biber
Mitglied: BrickTop
BrickTop 12.01.2006 um 21:42:50 Uhr
Goto Top
@Biber
Vielen Dank - Die Werte haben etwas mehr Leistung gebracht (Besonders das mit dem Stacks - man das sind ja echt noch die tollen alten DOS-Sachen...) - so toll wie unter NT läuft das aber nicht mehr... Wird wohl doch Zeit für die Windows-Version face-sad
Werde da noch ein wenig mehr dran bauen. Nachdem ich heute morgen (hatte noch keinen Kaffee...) versehentlich in der Konsole del *.* eingegeben habe ; Sollte eigentlich *.pif draus werden... Hmmm face-plain Letzte Datensicherung war ja 2 Tage her ($#$§")

@all
Auch euch vielen Dank für die vielen Ratschläge!

Also mit den Kompatibilitäts-Optionen habe ich auch noch NIE was bemerkt... Tolles Feature, so wertvoll wie Eisregen face-wink

Gruß
BrickTop
Mitglied: Biber
Biber 12.01.2006 um 21:52:50 Uhr
Goto Top
*lacht*
... versehentlich in der Konsole del *.* ....

Du hast es gut...
...brauchst nicht mehr lange überlegen, ob Du am Wochenende ins Kino oder in die Disco gehst...

Werde an Dich denken.. *feixxxxxxxx
Mitglied: Praktiken
Praktiken 10.04.2007 um 13:36:24 Uhr
Goto Top
Auch wenn schon älter:

Hier des Rätsels Lösung:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]

SharingViolationDelay = dword:0
SharingViolationRetries = dword:0

LanmanServer\Parameters\EnableOpLocks = 0
LanmanServer\Parameters\EnableOpLockForceClose = 1
LanmanServer\Parameters\CachedOpenLimit = 0
LanmanServer\Parameters\UseEnableOpLocks = 0
LanmanWorkstation\Parameters\UseOpportunisticLocking = 0
LanmanWorkstation\Parameters\UtilizeNtCaching = 0

und schon laufen alle alten DOS-Programme wieder mit der gewohnten Geschwindigkeit.
Mitglied: 53114
53114 05.09.2007 um 15:45:49 Uhr
Goto Top
Auch wenn schon älter:

Hier des Rätsels Lösung:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]

SharingViolationDelay = dword:0
SharingViolationRetries = dword:0

LanmanServer\Parameters\EnableOpLocks = 0
LanmanServer\Parameters\EnableOpLockForceClose
= 1
LanmanServer\Parameters\CachedOpenLimit = 0

LanmanServer\Parameters\UseEnableOpLocks = 0

LanmanWorkstation\Parameters\UseOpportunisticLocking
= 0
LanmanWorkstation\Parameters\UtilizeNtCaching
= 0

und schon laufen alle alten DOS-Programme
wieder mit der gewohnten Geschwindigkeit.

Habe dieses Problem auf XP-Clients auch. Der Server ist W2K, ebenso die meisten Clients (auf denen alles tadellos läuft). Leider muß ich für SWX jetzt XP-Clients haben.

Das bei uns verwendete Programm ist ein Windowsprogramm, das ein Menü anbietet. Aus diesem heraus werden dann einzelne DOS-Programme gestartet.

Ich habe auf den XP-Clients die o.g. Werte eingetragen, aber es stellt sich leider keine Besserung ein... Hat noch jemand eine Idee? Das Gejammere nervt schon. face-wink
Mitglied: BrickTop
BrickTop 05.09.2007 um 15:50:48 Uhr
Goto Top
Möchte Dich ja nicht beunruhigen aber wir haben da keine vernünftige Lösung für gefunden. Habe jetzt auf die Windows-Version umgestellt…

Solltest Du jedoch etwas finden, wie es anders läuft – Bitte noch mal melden. Bin da immer noch interessiert dran.

Gruß
BrickTop

Das nölen der Benutzer ging mir echt an die Substanz… Ich kann Dich verstehen!
Mitglied: Praktiken
Praktiken 05.09.2007 um 16:32:57 Uhr
Goto Top
> Auch wenn schon älter:
>
> Hier des Rätsels Lösung:
>
>
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
>
> SharingViolationDelay = dword:0
> SharingViolationRetries = dword:0
>
> LanmanServer\Parameters\EnableOpLocks =

>
LanmanServer\Parameters\EnableOpLockForceClose
> = 1
> LanmanServer\Parameters\CachedOpenLimit
= 0
>
>
LanmanServer\Parameters\UseEnableOpLocks = 0
>
>
LanmanWorkstation\Parameters\UseOpportunisticLocking
> = 0
>
LanmanWorkstation\Parameters\UtilizeNtCaching
> = 0
>
> und schon laufen alle alten
DOS-Programme
> wieder mit der gewohnten
Geschwindigkeit.

Habe dieses Problem auf XP-Clients auch. Der
Server ist W2K, ebenso die meisten Clients
(auf denen alles tadellos läuft). Leider
muß ich für SWX jetzt XP-Clients
haben.

Das bei uns verwendete Programm ist ein
Windowsprogramm, das ein Menü anbietet.
Aus diesem heraus werden dann einzelne
DOS-Programme gestartet.

Ich habe auf den XP-Clients die o.g. Werte
eingetragen, aber es stellt sich leider keine
Besserung ein... Hat noch jemand eine Idee?
Das Gejammere nervt schon. face-wink

Diese Eintrage müssen auf dem SERVER geändert werden face-wink
Mitglied: 53114
53114 05.09.2007 um 22:06:24 Uhr
Goto Top
Diese Eintrage müssen auf dem SERVER geändert werden face-wink

Also: das scheint echt was zu bringen, ich hab allerdings das Gefühl, daß die W2K-Clients jetzt (etwas) langsamer sind. Außerdem noch eine Sache: die "Datenbank" läuft über Dateifreigaben, d.h. lesen geht immer, schreiben nur, wenn grad kein anderer an dem Datensatz in der .dat-Datei wurstelt. Es gibt da jetzt hoffentlich nicht die Gefahr, daß ich da Beschädigungen reinbekomme?

Danke nochmal und Gruß
Mitglied: Praktiken
Praktiken 06.09.2007 um 09:36:37 Uhr
Goto Top
Das Sperren des Datensatzes während der Bearbeitung ist vollkommen richtig und normal. Beim w2k und w2k3 Server hat microsoft das locking der Dateien wieder einmal willkürlich geändert. Das hat zur Folge, das Dateien die im 16Bit Dos-Modus vom Client auf dem Server geöffnet werden, vom Server gelockt werden. Bis hierhin noch normal. Dann jedoch, wenn die Datei vom Client wieder "losgelassen" wurde, waren diese bis zu 10 sekunden weiterhin gelockt. Während dieser Zeit hatten andere Clienten keinen Zugriff darauf und hatten somit hänger oder blieben während dieser Zeit einfach stehen. Das Ändern der Parameter behebt dieses Problem. Das File wird unmittelbar nach Zugriff wieder freigegeben.

Zum Thema: Die Clients scheinen jetzt langsamer zu sein: Hast Du die Einträge, die Du ja zunächst an den Clients statt am Server vorgenommen hast auch wieder rückgängig gemacht?
Mitglied: 53114
53114 06.09.2007 um 10:38:01 Uhr
Goto Top
OK, gut. Ich hatte nur die Befürchtung, daß das Sperren nicht mehr richtig funktioniert. Und weshalb ich das am Server ändern mußte, der mit W2K-Clients ja einwandfrei funktionierte, ist mir noch nicht klar. Hab jetzt allerdings leider auch keine Zeit, mich damit groß auseinander zu setzen. Hauptsache, das Genöle hört auf. face-wink
@BrickTop: Versuch das mal, bei mir geht es jetzt.

Zum Thema: Die Clients [d.h. W2K-Clients. Kollege] scheinen jetzt langsamer zu sein: Hast Du die Einträge,
die Du ja zunächst an den Clients statt am Server vorgenommen hast auch wieder
rückgängig gemacht?
Jetzt ja. face-wink Aber noch nicht getestet... War wohl auch nur so ein Gefühl.

Herzlichen Dank jedenfalls!
Mitglied: 53114
53114 13.06.2008 um 09:22:46 Uhr
Goto Top
Zu diesem Thread habe ich auch noch mal eine Frage.

Bei uns haben wir festgestellt, daß bestimmte Sachen in dem DOS-Programm unter XP deutlich langsamer sind als unter W2K. Wir haben dann testweise die Shares, die das DOS-Programm braucht, auf einen Samba-Server umgezogen, aber das brachte auch gar nichts. (Wir hatten auf dem W2K3-Server SMB-Signierung deaktiviert und den Tipp von Praktiken angewandt).

Jetzt haben wir uns mal den Netzwerkverkehr angesehen und festgestellt, daß unter XP eine viel größere Anzahl sehr kleiner Pakete als unter W2K übertragen werden und also auch viel weniger große Pakete (MTU ist bei beiden Clients auf standardmäßig 1500 eingestellt).

Hat da jemand eine Idee?

Danke und Grüße
Mitglied: 53114
53114 18.07.2008 um 08:44:09 Uhr
Goto Top
Habe endlich die Lösung gefunden!
Es liegt am sogenannten Opportunistic Locking (hier gut erklärt: http://www.superbase.com/services_tech_support_oplocks.htm )!

Schaltet man das serverseitig aus, sollte das Problem weitgehend behoben sein.

Dazu muß man einen Registry-Key am SERVER eintragen (wie auch im Beitrag unter dem Link oben beschrieben):

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

EnableOplocks REG_DWORD 0 oder 1
Default: 1 (true)

Diesen Wert muß man auf 0 setzen!!

Wenn dieser DWORD-Wert nicht existiert, einfach anlegen und auf 0 setzen.


Am CLIENT kann man das auch machen, hier gibt es folgenden Schlüssel:

\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRXSmb\Parameters

OplocksDisabled REG_DWORD 0 oder 1
Standard: 0 (nicht deaktiviert)

Diesen Wert auf 1 setzen.

Wenn dieser DWORD-Wert nicht existiert, wie oben schon gesagt einfach anlegen und auf 1 setzen.


Grüße