W2k3 Server, DOS-Programm und mehr als 1 Benutzer ist Langsam
Hallo,
super Forum 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
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 ?!
super Forum 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
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 ?!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 23350
Url: https://administrator.de/contentid/23350
Ausgedruckt am: 23.11.2024 um 04:11 Uhr
18 Kommentare
Neuester Kommentar
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
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
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.
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.
@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?
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?
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.
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.
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.
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.
> 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.
>
> 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.
Diese Eintrage müssen auf dem SERVER geändert werden
Diese Eintrage müssen auf dem SERVER geändert werden
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ß
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?
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?
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.
@BrickTop: Versuch das mal, bei mir geht es jetzt.
Herzlichen Dank jedenfalls!
@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. Aber noch nicht getestet... War wohl auch nur so ein Gefühl.die Du ja zunächst an den Clients statt am Server vorgenommen hast auch wieder
rückgängig gemacht?
Herzlichen Dank jedenfalls!
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
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
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
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