Dateizugriff extrem langsam - Hintergrundsuche?

[quake 10]

Hallo,

 

habe ein riesen Performanceproblem bei Netzwerkzugriffen, welches ich auf das Betriebssystem zurückführen kann, aber nicht abgeschaltet bekomme.

 

Server: Windows 2008 Server und Suse Enterprise auf vSphere

Netzwerk: Gbit HP Procurve und 9 Remotestandorte per VPN mit 2,3 Mbit

Clients: XP und Windows 7

Software: Office 2003

 

Nun mein Problem

Befinde mich gerade in der Umstellung der Clients von XP auf Windows 7. Am lokalen Standort sind schon einige neue PCs mit Windows 7 im Betrieb, die im Netzwerk deutlich besser laufen könnten. Nun habe ich den ersten Remotestandort ebenfalls mit neuen Geräten ausgestattet und bekomme extreme Probleme beim öffnen von Dateien auf Netzlaufwerken. Beim Öffnen einer Worddatei öffnet sich diese zwar schnell, friert dann aber ohne ersichtlichen Grund ein und ist erst nach einigen Sekunden/Minuten je nach Größe des Freigabe-Ordners bearbeitbar. Mit XP-Clients kein Problem.

 

Ich habe schon alle möglichen Änderungen durchgeführt.

Windows Search - abgeschaltet

Virenschutz - ausgeschaltet

DNS - funktioniert tadellos

Word - neu installiert, keine Security-Eintrag in Registry

 

Jetzt habe ich beim Zugriff auf eine Netzwerk-Freigabe mit dem ProzessMonitor gesehen, daß Windows anscheinend nach dem Öffnen der Datei eine Dateiliste aller auf der Freigabe befindlichen Dateien erstellt obwohl die Indizierung ausgeschaltet ist. Sobald die Dateiliste vollständig ist, steht die Datei zur Bearbeitung zur Verfügung. Bei Freigaben mit vielen Dateien eine Katastrophe, zumal es sich hier um ca. 230000 Dateien in 30 Unterordnern handelt

 

Da es sich nicht nur um Office-Dateien, sonder z.B. auch Bild-Dateien handelt, kann es nur Windows selber sein. Seltsamerweise sind PDF-Dateien nicht betroffen. Bei Zugriff auf eine lokale Datei, wird diese Liste nicht erstellt.

 

Im ProzessMonitor wird dieser Vorgang als QueryDirectory mit der Dateiliste als Result aufgeführt. Dies wird auch am lokalen Standort ausgeführt, fällte hier nur nicht so auf, da man ja direkt am Rechenzentrum sitzt.

 

Wie kann ich diesen Vorgang unterbinden?

Bitte dringend um eure Hilfe, bin mit meinem Latein am Ende. Habe das Internet schon dreimal komplett durchgelesen ;)

[blub 115]

Hallo,

Ich kenne diese Problembeschreibung ("Langsamer Zugriff auf Freigaben, wenn dort sehr viele Dateien liegen"), wenn in den Netzwerkeinstellungen die MTU-Size nicht zur Fenstergröße passt. Setz die MTU-Size an einem Client mal etwas runter, ca. 1300. 

Dazu gibts Tools bzw. irgendwo liegt auch ein RegKey dazu

 

blub

[quake 10]

Danke erstmal für den Tip.

 

Das werde ich mal testen, da die Auswertung der VPN-Verbindung (Watchguard-Router) über netsh eine maximale Größe von 1390 empfiehlt. Das könnte auf jeden Fall Verbindungsabbrüche verhindern, auch wenn dadurch die Bandbreite etwas verringert würde.

 

Allerdings beseitigt das noch nicht das Problem, daß Windows nach dem Öffnen einer Datei, eine kompette Dateiliste des Freigabeordners erstellt. Dies würde auch bei Änderung des MTU passieren.

[quake 10]

... keiner mehr Ideen?

 

Ich habe jetzt noch die Erstellung der Thumbs.db auf Netzwerkordnern deaktiviert - bringt auch nichts!

Windows Search bzw. Offlinedateien deaktiviert - kein Erfolg!

MTU angepaßt - keine Änderung!

 

Warum wird bloß diese Dateiliste erstellt?

Das ist definitiv die Bremse, da in dem Ordner das Laden der knapp 45000 Dateinamen richtig Zeit in Anspruch nimmt. Auf dem Server ist keine Auslastung zu erkennen. Es ist auch vollkommen egal, ob ich auf die Freigabe eines Windows 2008 oder auf eine Samba-Freigabe des Suse zugreife. Bei Zugriff auf einen Freigabeordner mit nur hundert Dateien, geht es natürlich viel schneller.

 

Bin jetzt echt am verzweifeln, da auch eine kontaktierte Supportfirma mit wirklichen Profis keine Idee hat.

[XP-Fan 216]

Hallo,

 

versuche mal das TCP Tuning von Windows 7 zu deaktivieren und den TCP Offload einzuschalten, könnte helfen.

 

In einer administrativen cmd ( Als Admin ausführen ) auf einem PC testen, nach dem Ausführen der Befehle den Rechner neustarten.

 

Zum Abschalten:

netsh int tcp set global autotuninglevel=disabled

 

Weiterhin könnte es helfen den TCP Chimney Offload zu aktivieren:

netsh int tcp set global chimney=enabled

 

Zum Zurücksetzen falls erfolglos:

netsh int tcp set global autotuninglevel=enabled

netsh int tcp set global chimney=disabled

[quake 10]

Ich dachte schon, ich mache mir selbst Vorschläge... :p

 

Die Einstellungen habe ich gerade probiert, wobei ich die chimney-Option gar nicht kannte.

 

Das hat schonmal etwas gebracht, wenngleich das Hauptproblem direkt nach dem Laden der Datei bleibt. Trotzdem sieht man einen Fortschritt. Die Kiste startet recht fix und steht sehr schnell zur Verfügung.

 

Ich muß aber auch gestehen, daß ich die SMB-Signierung vorhin mal deaktiviert habe und erstmal damit weitertesten wollte.

 

Deaktivieren:

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

 

Aktivieren (...der vollständigkeithalber):

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/Nsi

sc config mrxsmb20 start = auto

 

...trotzdem ein großes Danke...

[quake 10]

Zur Verdeutlichung was da abgeht, habe ich mal einen gefilterten Ausschnitt aus dem ProcessMonitor beigefügt.

 

Am Anfang wird die Normal.dot geladen. In Zeile 13 ist die Datei test.doc fertig geladen in der Anwendung. Ab Zeile 17 folgt dann die Auflistung des Ordnerinhalts, jeweils fast immer genau 137 Dateinamen. Im rechten Ausschnitt ist ein Ausschnitt der Details zu erkennen.

 

Erst wenn dieses Listing fertig ist, kann in Word gearbeitet werden. Am lokalen Standort dauert das nur einige Sekunden, vom Remote-Standort geht für Minuten nichts. Andere Anwendungen können allerdings ohne Einschränkungen während der Abfrage benutzt werden.

 

Vielleicht kann ja mal jemand ohne dieses Problem mit dem ProcessMonitor bei sich schauen, ob es dort auch dieses QueryDirectory auf einem umfangreichen UNC-Pfad gibt.

[mcdaniels 29]

Hallo,

hast du eventuell ein aktuelleres Office zur Verfügung, um festzustellen, ob das Problem auch mit zb. Office 2010 auftritt?

 

Ich denke hier u.a. auch an das Supportende von Office 2003 im April 2014...

 

Hast du das Office File Validation Add In installiert? Wenn ja, dann versuch mal das zu deinstallieren und teste erneut.

 

 

LG

Daniel

bearbeitet 19. Juni 2013 von mcdaniels

[quake 10]

Hallo,

 

eine beauftragte Supportfirma hat das schon unter anderen Versionen (bis office 2013) mit gleichem Ergebnis getestet. Der Microsoft Support (Ticket besteht noch) hat bisher auch keine Lösung.

 

Das ist ja echt zum heulen :( !!! Nun hat vermutlich jeder das beschriebene Problem, nur fällt es nicht auf, wenn man direkt an der Freigabe sitzt. Aber von einem Remote-Standort ist es wirklich eine große Katastrophe bei Freigaben mit einer Vielzahl von Dateien.

 

Auch wenn man SMB2 ausschaltet, MRU anpaßt, Office FileValidation abschaltet....es bleibt extrem langsam!

 

Ich bin mittlerweile der Meinung, das es irgendetwas zwischen 32 und 64 bit ist. Da Microsoft ja selber nur die Verwendung von 32bit-Office auf 64bit-Windows empfiehlt, würde mich mal interessieren, ob dieses Verhalten bei einem 64bit-Office auch auftritt.

 

Wer hat es und kann das mal testen? Würde mir und vielen anderen sehr helfen.

Wenn es dann nicht auftritt, ist es ein vermutlich ein Fehler beim Umsetzen der 32bit-Kompatibilität (.dll o.ä.).

 

Mit gleichem Verhalten bei anderen Dateitypen (z.B. jpg) kann ich gut leben, weil es bei mir eher die Ausnahme ist.

 

 

LG

Markus

[Ewum 0]

Markus,

 

wenn Du den Server neu startest, ist dann das Problem zumindest kurzfristig behoben? So ist es zumindest in unserem Netzwerk. Das Öffnen von Office Dateien geht bisweilen auf den Clients ziemlich langsam - Serverneustart - alles ok. Leider kenne ich die Ursache auch noch nicht.

 

Schöne Grüße,

 

Uwe

[Daniel -MSFT- 129]

Du hast nicht die SMB-Signierung abgeschaltet, sondern die erweiterten, neueren SMB-Protokollversionen v2... How to shoot yourself into the foot

bearbeitet 30. Juli 2014 von Daniel -MSFT-

[zahni 550]

@Daniel,

 

jetzt bist Du auch reingefallen ;)

Schau mal auf das Datum.

[Daniel -MSFT- 129]

Boah, wie ich das hasse. Vielen Dank für den Hinweis. Warum gibt es da nicht eine fette Warnung ⚠ in der Mobilansicht?

[silencar 0]

Hallo,

 

Datum hin oder her, dass Problem ist nach wie vor nicht gelöst und betrifft nach dem Umstieg auf Windows 7 auch mich.

Netzlaufwerk mit über 200.000 Dokumenten. Word 2003 blieb nach öffnen eines Dokuments für mehrere Sekunden "ohne Rückmeldung". Mit Word 2007 kann mit der Datei zwar direkt gearbeitet werden. Dennoch verursacht das Öffnen UND das Schließen jeweils für mehrere Sekunden eine hohe (sinnlose) Netzwerkauslastung (siehe Taskmanager).  (Frage zum erwähnten Netzwerktimeout: verursacht ein Netzwerktimeout Traffic?)

Die Ursache ist in Windows 7 allein oder in der Kombi mit Office zu suchen.

Und ich würde sehr gerne diesen unnützen Traffic vermeiden.

Gruß an die Microsoft-Entwickler - wäre schön wenn ihr da ne Lösung hättet.

 

BG

Mike

bearbeitet 29. August 2014 von silencar

[=BT=Viper 11]

Hi, ich denke wir haben das gleiche Problem

 

http://www.mcseboard.de/topic/200210-zugriff-auf-große-netzwerkordner-als-user-sehr-langsam/

 

Probier das mal http://www.computerwissen.de/windows/windows-probleme-loesen/artikel/windows-7-ordner-oeffnen-dauert-ewig-hier-ist-die-loesung.html

 

Habe bei mir nicht sofort eine Besserung fest gestellt, kann aber auch gut sein das man etwas warten muss, gerade bei großen Ordnern.

bearbeitet 26. November 2014 von =BT=Viper