Netzwerkgeschwindigkeit

[Koverhage]

Folgendes Problem:
Server Windows 7
3 Arbeitsplätze mit XP
1. Arbeitsplatz ruft die Anwendung auf, alles OK
2. Arbeitsplatz ruft die Anwendung auf, die Geschwindigkeit geht in die Knie, sodass ein anständiges Arbeiten fast nicht möglich ist.

Wenn jetzt der 2. Arbeitsplatz die Anwendung beendet, bleibt die Geschwindigkeit, erst wenn auch der 1. Arbeitsplatz das Programm
beendet und neu startet, ist die Geschwindigkeit wieder normal, bis ein anderer Arbeitsplatz die Anwendung aufruft.

Auf den Arbeitsplätzen ist Avira Antivir installiert, bei Guard ist unter Ausnahmen das komplette Laufwerk des Servers ausgeschlossen.

An welchen Schrauben kann bzw. muss ich drehen damit es einigermaßen normal läuft ?

[Rolf Ramacher]

Hi Klaus,

ich kenne jetzt nicht windows 7 Server. aber ich würde auf Netzwerkeinstellung am Server denken.

[brandelh]

Diese Beschreibung habe ich hier schon mal gelesen, war es von Tom oder Markus ?

[Tom]

Das Spiel hatten wir auch gerade mehrfach. In einer sehr ähnlichen Topologie half es, die mit den Rechnern ausgelieferten Billig-Netzwerkkarten gegen bessere auszutauschen. In einer anderen Situation war tatsächlich das abgeschaltete OpLocking (+ alle "Nebeneinstellungen", also CachedOpenLimit u.ä.) der Verursacher; nach dem Wiedereinschalten ging die Netzwerkperformance verblüffend in die Höhe, und Fehler sind seitdem (ist vor zwei Wochen passiert) trotz enorm intensiver Nutzung nicht aufgetreten.

[Koverhage]

Hallo Tom,

OPLocking auf Server einschalten oder auf den Workstations ?
Auf dem Server dürften die Einstellungen bisher nicht vorhanden sein.

[Tom]

Im vorliegenden Fall war das OpLocking serverseitig abgeschaltet. Und dort wurde es auch wieder eingeschaltet. Die Workstations standen auf ihren Defaults, OpLocking war also prinzipiell aktiv, wurde aber vom Server verweigert.

[AUGE_OHR]

Im vorliegenden Fall war das OpLocking serverseitig abgeschaltet. Und dort wurde es auch wieder eingeschaltet. Die Workstations standen auf ihren Defaults, OpLocking war also prinzipiell aktiv, wurde aber vom Server verweigert.

NOPE !!! Nur wenn man auf dem Server UND den Workstationen die "richtigen" SMB1 Einstellungen macht funktioniert es.

p.s. XP als Workstation kann man in einem Win 7 Netzwerk auch mit SMB2 verwenden. ( WindowsXP-KB922120-v6-x86-DEU.exe )

[Tom]

NO_NOPE. Wenn auf dem Server OpLocking explizit ausgeschaltet ist, gilt das auch für die Workstations, selbst dann, wenn dort keine OpLocking-Einstellungen vorgenommen sind, diese also defaultmäßig opportunistisch locken wollten. Genau das war hier der Fall.

[AUGE_OHR]

Wenn auf dem Server OpLocking explizit ausgeschaltet ist, gilt das auch für die Workstations, selbst dann, wenn dort keine OpLocking-Einstellungen vorgenommen sind, diese also defaultmäßig opportunistisch locken wollten. Genau das war hier der Fall.

kein Wunder das bei dir Ops-Locking nicht funktioniert den es nützt gar nichts wenn man "nur" am Server die Einstellungen macht da es um den "lokalen" Cache der Workstation geht.

[Tom]

Wer lesen kann, ist klar im Vorteil, gelle?

OpLocking ist standardmäßig (frisch ausgeliefertes Windows ab NT) an. Wenn man es abschalten will, kann man das a) bei allen Workstations tun (...\lanman\workstation), b) am Server (...\lanman\server) oder c) - und wenn man auf Nummer sicher gehen will -, überall. Im vorliegenden Fall war das OpLocking am Server deaktiviert und damit eben nicht mehr aktiv, denn die Workstations können noch so sehr nach OpLocks schreien: Wenn der Server das verweigert, gibt's eben keine. Die Folge waren dramatische Performanceeinbußen. Um es wieder zu aktivieren, genügte es, die Reg-Schlüssel beim Server wieder zu löschen, denn die Workstations standen nach wie vor auf ihren Defaults, wollten also eigentlich OpLocken.

Und noch einmal, für Fußgänger. Das OpLocking war AUS, wie uns allen ja auch empfohlen wird. Es war definitiv aus, obwohl die Keys nur am Server gesetzt waren (ich kann die Benzinpumpe abklemmen ODER kein Gas geben, das Auto fährt in beiden Fällen nicht). Nach der Löschung dieser Keys ist es jetzt wieder an, was man daran merkt, dass die Arbeit im Netz deutlich schneller geworden ist. Will sagen: In bestimmten Fällen, die wir derzeit noch analysieren, führt die Abschaltung des OpLockings im intensiven konkurrierenden Betrieb zu dramatischen Geschwindigkeitseinbußen. Jetzt warten wir darauf, ob die avisierten Datenfehler, die ja die Begründung für die Abschaltung des OpLockings waren, eintreten.

[AUGE_OHR]

Wer lesen kann, ist klar im Vorteil, gelle?

spricht du mit dir selbst ?

OpLocking ist standardmäßig (frisch ausgeliefertes Windows ab NT) an. Wenn man es abschalten will, kann man das a) bei allen Workstations tun (...\lanman\workstation), b) am Server (...\lanman\server) oder c) - und wenn man auf Nummer sicher gehen will -, überall.

NEIN es funktioniert NUR c.) !!!
Es muss auf dem Server OplocksDisabled = 1 und EnableOpLocks = 0 als "minimum" gesetzt werden
UND auf der Workstationen UseOpportunisticLocking = 0

Wenn NUR auf der Workstation UseOpportunisticLocking = 0 gesetzt ist, aber der Server nicht "gesetzt" wurde tritt noch ein "anderes" Problem auf
( Stichwort Netzwerk Port )

offensichtlich ist dir nicht klar "was" die Ops Lock Registry Setting überhaupt "wie" machen.
Du solltest einen Fachmann fragen wenn du weiterhin "Problem" mit Netzwerk hast so wie ich es 3 Tage lang gemacht habe.

[Tom]

Jimmy -

Dir scheint nicht ganz klar zu sein, was ein Protokoll ist und macht. Auch zu SMB2 und Deinem Lieblingsthema "Port Soundso" hast Du ja eine Menge gesagt, und nur ein Teil davon stimmte. Geschenkt.

Wenn der Redirector bzw. der Client OpLocks anfordert, der Server dies aber nicht zulässt, ist der Drops gelutscht - OpLocking findet nicht statt. Die "Schalter" sind als Reihe zu begreifen - wenn einer aus ist, fließt kein Strom. Wenn alle bis auf einen aus sind, aber der eine wieder eingeschaltet wird, fließt der Strom wieder. Solange der aber aus bleibt, nutzt es überhaupt nichts, die anderen Schalter zu betätigen. Da es sich in Netzen im Client-Server-Verhältnis um eine n-zu-eins-Beziehung handelt, gewährt der Server solchen Clients nach meiner Beobachtung (und ich habe sehr intensiv beobachtet) allerdings OpLocking, auf denen es eingeschaltet ist (sofern bei ihm auch), selbst dann, wenn es auf einzelnen Clients abgeschaltet ist. Die Servereinstellungen aber sind der "Main Switch", denn der Server regelt das Chaching nach wie vor. Ich könnte den Beweis hierfür führen, aber das könntest Du auch selbst.

Es gibt viele Feinheiten in diesem Zusammenhang (insgesamt 3 OpLocking-Typen und vieles mehr), und auch viele Stellschrauben, an denen man drehen kann (vor allem für den Caching-Vorgang selbst), davon abgesehen sicher viele "Fachleute", die einem drei Tage lang den Wolf zu diesem Thema erzählen können, weil sie lustige Registry-Keys gefunden haben, die anscheinend irgendwas bewirken, aber unterm Strich ist es an oder aus, Punkt. Ein Protokoll regelt die Kommunikation zwischen mindestens zwei Partnern, und nur das, was beide Partner für das jeweilige Protokoll akzeptieren, findet auch statt. Wenn Du jemandem die Hand schütteln willst, der diesen Vorgang nicht kennt, kannst Du so lange in der Luft herumwedeln, bis sie warm wird - der andere wird die Hand nicht greifen, um sie mit seiner zu schütteln. Dieser Vorgang ist ein protokollarischer.

Noch einmal zum Verständnis: Beim OpLocking geht es darum, dass die Clients das Caching von Dateien auf dem Server kontrollieren. Hierbei wird - leider - grundsätzlich von einer exclusiven Nutzung ausgegangen, was zwar die Performance steigert, aber im konkurrierenden Zugriff zu Problemen führen kann, eigentlich sogar muss. Ob solche Probleme aber auftreten, scheint von der Leistungsfähigkeit des Servers, der Netzwerkstruktur, der Größe der verarbeiteten Dateien und einer Menge weiterer Parameter abzuhängen. Nach meiner vorläufigen Einschätzung ist es so, dass OpLocking möglicherweise eingeschaltet bleiben kann, vielleicht sogar sollte, wenn zwar viel lesend auf Tabellen zugegriffen wird, Schreibzugriffe aber nur in einem sehr engen Zeitfenster und im Verhältnis zur Gesamtnutzung der Dateien äußerst selten stattfinden.

Und wenn man - den vielen Anweisungen, die im Netz kursieren, folgend - nunmehr überall sämtliche Parameter gesetzt hat, die von offizieller Stelle genannt oder von irgendwem "herausgefunden" worden sind, um OpLocking abzuschalten, muss man die natürlich auch brav allesamt wieder entfernen/umsetzen. Wenn man aber nur am Server ausgeschaltet hat, was auch definitiv die Beendigung des OpLockings zur Folge hatte, muss man es auch nur dort wieder einschalten.

[AUGE_OHR]

hi,

du sprichst hier von Server "Cache" :
a.) du kannst ihn "nutzen"
b.) du kannst ihn "umgehen"

beides hat aber NICHTS mit dem Ops Lock Problem zu tun da die Daten
1.) evtl. unvollständig angekommen
2.) gar nicht "abgesendet"
3.) noch in "warte" Stellung sind.

sie sind also "wenn" dann schon "kaputt" auf dem Server angekommen oder noch gar nicht "unterwegs"

Ops Locking soll mit "voll" gefüllten Datenpaketen für Performance sorgen.
File basierende Datenbanken, wie Xbase ( alle Versionen ), arbeiten Record bezogen.
Die Grösse eines Datensatz ist ca. "Header"+ (FELDer * Länge), also bei 100 Felder Type "C",10 gerade mal 1Kb.

nun sollte ein COMMIT bewirken das die Daten vom Client an den Server "übertragen" werden wo sie dann im Server Cache landen.
um den ganzen Vorgang im Netzwerk zu starten sendet zuerst der Client eine "Anfrage" und wartet auf eine Antwort des Server.

Die "Antwort" des Server zum "senden" beinhaltet das "flushen" ( wenn beim Server "enable" )
des "lokalen" Ops Lock Cache ( wenn beim Cient "enable" ) und die "Rückmeldung".
... und hier könnte nun "das" Ops Lock Problem im Multi-User Betrieb auftreten.

wenn hier nun "lange" Zeit eine Workstation auf eine "Antwort" wartet könnte ein Indiz für ein Kommunikations-Problem vorliegen.
unter Win 7 sollte man nun im Taskmanager -> Resource-Monitor -> Netzwerk sich ansehen "wo/was" passiert (Server und Client gleichzeitig ! ).

wenn Datensätze "unvollständig" sind oder "fehlen" dann liegt es am "lokalen" Ops Lock Cache und/oder Timing/Kommunikations-Problem (Rückmeldung).

wenn man nun Ops Locking komplett (Server/Client) "disable", also keinen "lokalen" Cache benutzt, wird die Netzwerk Performance bei Record bezogenen Aktionen ein wenig sinken.

wie viel hängt nun wohl auch mit der Hardware zusammen. Ich habe mit "neuerer" Hardware mehr Probleme als mit "alten" PC´s.
auch die (unterschiedlichen) "Build-in" Netzwerk Chipsätze / Firmware mag ich nicht, die "alten" habe alle die "selben" Steckkarten.










Ops Locking ist SMB1 Standart bis incl. XP über Port 139
ab Vista/Win 7 gab es dann den SMB2 Standart mit Port 445 dazu welche "default" wurde.

"default" bedeutet das zuerst das SMB2 über Port 445 versucht eine Verbindung aufzubauen
sollte das nicht klappen wird "runter-geschaltet" auf SMB1 und man kann auf Port 139 das "Handshake" beobachten.









ich bin nun der Meinung das man in einem Win 7 Netzwerk KEINE Ops Lock Einstellungen benötigt wenn die "gesamte" Kommunikation des Server -> Client über SMB2 Port 445 erfolgt.

der KB922120 enthält für XP SP3 einen "neuen" Redirector für den Client damit XP die "umgeleiteten" Anfragen des Server "sofort" erhält und nicht "warten" muss das der Port 139, der evtl noch "sendet", eine Anfrage bekommt.

[brandelh]

Es ist wie im richtigen Leben ...

für ein reibungsloses Zusammenarbeiten, muss alles stimmen (was auch immer),
für Probleme reicht ein kleines Missverständnis (Treiberproblem, Hardwarewackler, Einstellungsoption, etc.)

[Herbert]

Meine Herren, das hatten wir alles mehrfach. Die Suchfunktion bringts an den Tag.

Allerdings ist zu hoffen, dass an den .DBF-Treibern auch noch gearbeitet wird, denn dasselbe Verhalten ist bei Windev wohl auch zu beobachten, aber um Faktoren schwächer.

[Tom]

Hallo, Jimmy.

Du wirfst da einiges durcheinander. Aber wenn Du auf diesem Weg für Dich zu befriedigenden Ergebnissen kommst - okay.

[adrian]

Klaus, wenn Du die definitive Lösung hast, würde mich dies wirklich interessieren.

Wir haben schon einiges Versucht, mit den Tipps, welche hier im Forum schon einige Male diskutiert wurden, doch der gewaltige Sprung habe ich noch nicht erreicht.

adrian

[AUGE_OHR]

Du wirfst da einiges durcheinander.

das einzige was ich durcheinander bringe ist dein völlig falscher Vortrag wo du nicht eine einzige Quelle als Nachweis angibst.

das kannst du deinem Baby als gute Nacht Geschichte erzählen aber nicht erfahrenen User die es selbst ausprobieren können.

[Jan]

Tom und Jimmy,

könnt Ihr beide vielleicht Eure Argumente jeweils mit nachvollziehbaren Messwerten, Zitaten, etc. begründen? Es nützt uns allen nichts, das Ihr beide hier Euren Privatkrieg ausfechtet, und wir Anderen stehen daneben und können nur Worten, aber nicht fachlich begründeten Argumenten folgen. Und das bei einem für alle so wichtigen Thema.

Jan

[Koverhage]

Sobald sich im Dschungelkrieg ein Lichtblick gibt, werde ich es kundtun
Für mich besteht zunächst das Problem: Welche Werte sind standardmäßig gesetzt?
Bei mir habe ich hier einen Win64 mit Win7 Ultimate 8GB Hauptspeicher als Server
Einen Arbeitsplatz XP SP 3, 32 bit und einen Arbeitsplatz mit Win7 Home (64bit).
Also zunächst mal was völlig anderes als beim Kunden.
Bei mir kann ich auch einen Performance Verlust feststellen, vielleicht nicht so wie groß
wie beim Kunden, aber schon spürbar.
Wenn ich jetzt auf der Basis das System schneller machen kann, bedeutet das noch lang nicht, dass dies
auch beim Kunden so wäre.
Bei mir sehen die Standardeinstellungen so aus:

[AUGE_OHR]

könnt Ihr beide vielleicht Eure Argumente jeweils mit nachvollziehbaren Messwerten, Zitaten, etc. begründen?

ich habe mehrfach Messwerte, Diagramme/Snapshot und auch Testcode geliefert und meine "Quellen" genannt.
http://www.xbaseforum.de/viewtopic.php?f=32&t=3979
http://www.xbaseforum.de/viewtopic.php?f=16&t=4300
http://www.xbaseforum.de/viewtopic.php?f=24&t=4649
http://www.xbaseforum.de/viewtopic.php?f=7&t=4451
http://www.xbaseforum.de/viewtopic.php?f=21&t=1567
http://www.xbaseforum.de/viewtopic.php?f=20&t=5039
um nur mal einige zu nennen

Es ist also die Frage an Tom, woher er seine Argumente hat, anzugeben.

Es nützt uns allen nichts, das Ihr beide hier Euren Privatkrieg ausfechtet, und wir Anderen stehen daneben und können nur Worten, aber nicht fachlich begründeten Argumenten folgen. Und das bei einem für alle so wichtigen Thema.

interessant dass eine Diskussion als Privatkrieg angesehen wird.

[AUGE_OHR]

Für mich besteht zunächst das Problem: Welche Werte sind standardmäßig gesetzt?
...
Bei mir sehen die Standardeinstellungen so aus:

dein Bild zeigt ja "nur" den \LanmanServer\Parameters und nicht HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MRxSmb\Parameters

bei einem "frischen" OS() gibt es gewöhnlich keine "disable" Einträge sondern alles ist "default" enable
bei "disable" musst du meistens erst neue "Schlüssel" anlegen damit die "default" überschrieben werden.




unabhängig davon wirst du mit der XP Workstation im "Mix" mit Win 7 weiterhin Probleme haben wenn du nicht :

a.) den neuen XP Redirector benutzt
oder
b.) SMB2 komplett "abschaltest"

wobei ich von 2.) dringendst abrate !!!
du solltest also IMHO den XP Redirector KB922120 v6 (SP3 !!!, v5 SP2) ausprobieren wenn du weiterhin mit XP im "Mix" mit Win 7 benutzen willst.

[Jan]

Jimmy,

ich habe das mit Privatkrieg deswegen geschrieben, weil Ihr Euch Sachen um die Ohren kloppt, ohne die zu belegen. Eine Diskussion kann auch mal gefühlsmäßig werden, sollte aber immer zu einem zu einem eindeutigen Ergebnis führen. Die Diskussion hier zwischen Dir und Tom scheint da aber keineswegs hinzu führen.

Ich habe mal eben in die von Dir aufgeführten Threads reingeschaut (ich bin nicht so ein Nachtmensch wie Du, bei mir steigt die Müdigkeit um diese Uhrzeit doch sehr an). Sorry, wenn ich das so sage, aber Quellen kann ich da so gut wie nicht finden. Abgesehen davon, das etwa die Hälfte der Beiträge garnicht um Oplocks geht, sondern um SMB2. Also zwar ebenfalls ein wichtiges Netzwerkproblem bespricht, aber eben ein ganz anderes. Und die Quellen, die Du anführst, untermauern nicht Deine Aussagen. Klar stehen da (hauptsächlich) MS-Texte drin. Aber nicht mit den Aussagen, die Du immer wieder aufführst. Wie gesagt, nur eben schnell überflogen.

Ich muß natürlich sagen, das ich bislang zum Glück nicht sehr mit solchen Problemen im Netzwerk zu kämpfen hatte. Und ich auch Euer beider Argumente nicht selber nachvollziehen kann. Ich bin also auf Eure Aussagen angewiesen. Um so wichtiger ist es mir, das Ihr die sachlich untermauert. Und es tut mir leid das sagen zu müssen - Jimmy, in allen Diskussionen, die ich eben überflogen habe, scheint es so, als ob alle anderen Diskussionsteilnehmer grundsätzlich nicht Deiner Meinung sind. Und auch nicht deren Meßergebnisse, die sie teilweise aufgeführt haben. Ohne eine fundierte Untermauerung Deiner Ausasgen muß ich also alleine deswegen dahin tendieren, den Anderen zu glauben. Und es muß ohne ausreichende Zitate so lange beim Glauben bleiben, bis ich das alles irgendwann einmal selber testen und prüfen kann.

Du verstehst jetzt sicherlich, warum ich meine Anforderung oben geschrieben habe. Denn garantiert bin ich nicht der einzige, der Probleme mit einer nicht untermauerten Diskussion um dieses wirklich wichtige Thema haben.

Jan

[AUGE_OHR]

hi,

meinen Vorschlag für das "3x XP / Win 7 Server" Problem von "diesem" Thread habe ich ja vorgebracht : KB922120







Inhaltlich liegen Tom und ich gar nicht so weit auseinander bis auf :

a.) reicht das "disable"/"löschen"/"entfernen" aus ( inklusive reboot ) ?
oder muss man "explizit" die einmal angelegten Schlüssel "benutzen" ?

b.) welcher Ops Lock Cache wird "disable"/"abgeschaltet"/"umgangen"
Server oder Client ?

noch nicht angesprochen
c.) wie "sieht" ein Fehler aus
d.) "wo/wann" passiert der Fehler

zu c.) und d.) hatte ich in den o.g. Threads auch Snapshots gemacht und das Thema angesprochen.

[Koverhage]

Jimmy,

kein Problem, hier die SMB Settings.
Aber denke mal das hat damit nichts zu tun, als der Server noch ein XP Server war, war es genauso.