Pfad "d:\$Directory"

[Matrix316]

Problem: Wir haben hier auf Windows 2003 R2 eine DFS Replikation laufen. Alle unbestimmte Zeitabschnitte, stockt der Server. Jetzt habe ich festgestellt (mit ProcessMonitor) dass der Server immer stockt, wenn die dfsr.exe mit ReadFile auf den Pfad "d:\$Directory" zugreift (und zwar pro Sekunde ca. 100 mal oder mehr). Nur was ist $Directory? Hat jemand irgendwann schonmal $Directory in kombination mit einem Pfad gesehen? Google bringt irgendwie überhaupt keine Ergebnisse. Bing auch net.

[BoRaaS]

Neee, sagt mir gar nix. Kannst du in den Ordner irgendwie reinschauen ?
Also vorher evt. erst den Besitz übernehmen.

[Matrix316]

Es gibt keinen Ordner "$Directory", das ist ja das komische.

Ich sehe im Process Monitor, dass die dfsr exe im Stagingordner liest und sein log schreibt (und vieles mehr) und irgendwann macht er ReadFile auf "d:\$Directory" - und dann stockt der ganze Server (Raid 5 mit 11 750 GB Platten). Wir haben sogar zwei Storage Server, einen Dell und einen von IBM (weil wir erst dachten, es läge am Dell und seinem Raid Controller). Beide replizieren sich Daten (über Gigabit) und auf beiden tritt das auf. Vorher war nur der Dell da, der auf einen anderen Standort replizierte (über 2 MBit), aber da stockte es auch schon.

[BoRaaS]

Hm wir haben ja auch ein DFS bei uns. Ich schaue da mal nach ob sowas ähnliches abläuft.

[Matrix316]

Alles klar. "Die Firma dankt schonmal im vorraus." ;) Was auffällt ist, dass auf dem entfernten Standort (über die 2 Mbit Leitung), dieses Read auf $Directory viel seltener passiert als auf dem IBM hier (wobei dort auf dem Server auch nicht gearbeitet wird - was auf dem Dell im Gigabit aber auch nicht der Fall ist).

[HeldImZelt]

Sieht auf den ersten Blick wie eine nicht referenzierte Variable aus. Ich kenne aber das System nicht und kann kein Urteil darüber abgeben, ob diese Art der Übergabe beabsichtigt ist. Es muss kein Fehler sein.

Zu der "Dollar" Schreibweise fallen mir spontan die NTFS Metafiles (http://en.wikipedia.org/wiki/NTFS#Metafiles) ein. Da gibt es aber kein $Directory.

[Panasonic]

$ steht in MS-Domänen für Adminfreigaben. Evtl. wird die dfsr.exe nicht mit den erforderlichen Rechten ausgeführt?

[Matrix316]

Das "Result" ist "SUCCESS" und es hat sich nie jemand ohne Administratorrechten angemeldet, der das ausführen hätte können. Aber man müsste es mal checken. Aber das komische ist, das Problem trat erst auf einem DELL Server auf. Jetzt haben wir den durch einen frisch eingerichteten von IBM ausgetauscht und der gleiche Fehler passiert.

Das mit den Metafiles könnte was sein, weil DFSR setzt ja auf NTFS auf. Muss ich mal googlen...

Hier ist mal ein Bild des Process Monitors und der Leistungsanzeige. Wenn unten grün und blau an der Decke sind (also über 100) und oben das ReadFile auf "$Direcory" geht, dann hängt der Server bzw. der Zugriff auf das Storage Raid System was dranhängt.

http://s5.directupload.net/images/090701/dtffwela.png (http://www.directupload.net)

EDIT: Was mir noch aufgefallen ist, dass WENN es "blau" ist, also Read auf "Directory" gemacht wird, dann steht praktisch die Dfsr.exe. Es gibt kein EA lesen, kein EA schreiben und kein EA andere (laut Taskmanager).

[Panasonic]

Habe wenig Zeit, wirf doch mal hier einen Blick rein, evtl. ist es für Dich interessant: http://www.mombu.com/microsoft/windows-server-dfs-and-frs/t-slow-transfers-710357.html

[Matrix316]

Naja, die Replikation ist ja nicht unbedingt langsam. Es stockt bzw. stoppt nur ab und zu. Auch nicht unbedingt regelmäßig, sondern manchmal alle paar Minuten, manchmal nur einmal die Stunde. Im GB Netz lokal dauert es keine Sekunde bis z.B. eine Datei repliziert ist. Nur wenn oben die Aktion läuft, geht garnichts - auf dem ganzen Raidverbund nicht.

[BoRaaS]

So, ich kann das bei uns nicht nachvollziehen.
Repliziert ihr einzelne Ordner unter Laufwerk D: oder alles unterhalb von D: ??
Magst du evt die DFs Replikationseinstellungen mal posten ? Also welche Verzeichnisse, Staging Größen etc.

[Panasonic]

Die Staging-Größen konnten tatsächlich interessant sein, such danach mal in der DFS-R Onlinehilfe!

[Matrix316]

So, ich kann das bei uns nicht nachvollziehen.
Repliziert ihr einzelne Ordner unter Laufwerk D: oder alles unterhalb von D: ??
Magst du evt die DFs Replikationseinstellungen mal posten ? Also welche Verzeichnisse, Staging Größen etc.
Aaalso, mal zum drumherum:

D:\ ist ein Storage System bestehend aus (lass mich lügen) 11 x 750 GB Platten zu einem Raid 5 Verbund der insgesamt ca. 6,13 TB bietet. Auf D:\ befinden sich diverse Ordner im DFS Namespace, von denen zur Zeit 2 repliziert werden. Beide Ordner haben ca. 1 TB, bestehend vorwiegend aus jpeg Bilder und PDF Files.

Staging ist bei jedem Ordner auf 122880 MB gesetzt. Conflict and Deleted auf 19800 MB.

Hier mal ein schnell gekritzeltes Bild.
Links ist quasi die Ausgangssituation, der IBM Server am Backup Standort wurde frisch aufgesetzt und in die Replikation eingebunden, bis er dann den Dell hier am Produktionsstandort ersetzen sollte, weil es hier stockte.

http://s4.directupload.net/images/090701/ezfkoukx.png (http://www.directupload.net)

[BoRaaS]

Hmm, ich habe echt keinen Plan, sieht eigentlich ganz ok so aus.
Kannst du evt. nochmal schauen wie die I/O Warteschlange des Subsystems ausschaut ? Nicht das ihr zu wenig "Spindeln" habt.

[Matrix316]

Hmm, ich habe echt keinen Plan, sieht eigentlich ganz ok so aus.
Kannst du evt. nochmal schauen wie die I/O Warteschlange des Subsystems ausschaut ? Nicht das ihr zu wenig "Spindeln" habt.
Man sieht oben, die durchschnittliche Warteschlange des Physikalischen Speichers (grün in Perfmon). Und die geht auch deutlich in die Höhe. Wir haben jetzt eine Idee vom Dell Service, dass vielleicht die 750GB 7200er SATA Platten zu langsam sind. Das sind 11 Stück pro Verbund. (es arbeiten ca. 40 Mitarbeiter auf dem System, jeder hat zwei freigegebene Verzeichnisse als Laufwerk eingebunden)

[BoRaaS]

Weil selbiges Problem hatten wir auch. 7 x 300GB Platten plus Hotspare.
War einfach zuviel I/O Last auf dem Subsystem. Bei uns liegen auf dem Server aber auch die Profile und Nutzerordner. Haben das ganze jetzt auf 22 x 140GB Platten umgestellt, läuft seitdem erheblich besser. Vorallem sind die neuen Platten auch 15k SAS Platten.

[Matrix316]

Benutzerordner sind auch auf dem Server. Das mit den mehr aber kleineren Platten wäre schon eine gute Idee...(da bräuchten wir nur schlappe 55 150 GB Platten X-D

[DasAuge.]

Matrix316 hast recht mit deinem letzen Beitrag, aber dennoch traue dem nicht ganz. werde dir morgen ganz genau antworten können.
grüsse aus Rom cioa

[BoRaaS]

Benutzerordner sind auch auf dem Server. Das mit den mehr aber kleineren Platten wäre schon eine gute Idee...(da bräuchten wir nur schlappe 55 150 GB Platten X-D
Habt ihr die persönlichen Ordner (also die Outlokk Pst Files) auch dort liegen ??
Naja ansonsten nehmt ihr halt 300GB Platten. Aber der Unterschied zwischen den 7200 Sata Platten und den 15000 SAS Platten ist schon ein Unterschied

[Matrix316]

Habt ihr die persönlichen Ordner (also die Outlokk Pst Files) auch dort liegen ??
Naja ansonsten nehmt ihr halt 300GB Platten. Aber der Unterschied zwischen den 7200 Sata Platten und den 15000 SAS Platten ist schon ein Unterschied
Die waren mal dort, aber die haben wir jetzt ins persönliche Profil gelegt, so dass Outlook nicht auf den Server zugreift. Hat aber nichts gebracht.

[BoRaaS]

Hmm, oder habt ihr zu große Dateien die immer wieder durch die Änderungen repliziert werden müssen ??
Die neuse DFSR.exe schon eingespielt ?
Ansonsten schau mal hier Aktives Verzeichnis (http://blogs.technet.com/deds/archive/2008/06/26/aktuelle-dfsn-und-dfsr-hotfixes.aspx)

[Matrix316]

Aaalso, hab jetzt rausgefunden (im Microsoft Technet Forum), dass $Directory eine "special NTFS metadata file structure" ist und wir mal CHDSK laufen lassen sollten. Frage wäre, wie lange das dann dauert. ;)

[BoRaaS]

Och bei den paar TB wohl einige Stunden :wink:

[Panasonic]

Auf einem fetten RAID doch nicht.

[Matrix316]

Sieht so aus, als obs was ganz anneres wäre, nämlich wir erstellen über Web Anwendungen massenweise PDF Anschreiben, die mit Chrystal Reports generiert werden. Und immer wenn so eins generiert wird, kommt das readfile auf $Directory im procmon...

[Haarmann]

Matrix316

Teile und Herrsche ;)

Eine 750er dazu und die Daten auf 2 RAID5 mit Hotspare, oder gleich R6, gibt immer nioch die rund 6TB, verteilen. Das Schreiben hängt bei jedem RAID5 an der Parität... ganz besonders, wenn die Blockgrössen, durch massenweise Platten, immer grösser werden.

[Matrix316]

Aaalso, es hat sich rausgestellt, dass die Replikation doch ein Grund ist. Heute zwischen 9 und 13 Uhr, hat zwischen dem Hauptstandort und dem Backupstandort über die 2 MBit Leitung keine Replikation stattgefunden (oder zumindest nur minimal, also statt wie eingestellter 512 kbit nur 100~200 kbit und es gab keine Hänger. Jetzt repliziert er wieder munter drauf los, und die readfile auf $directory tauchen wieder massig auf...

[Matrix316]

Noch was: Gestern abend (und am Samstag) konnten wir diedes Readfile auf $Directory und die Hänger feststellen, obwohl insgesamt nur ca. 4 Leute auf dem System gearbeitet hatten. Wie kann das sein?

EDIT: Ganz interessant ist, dass wir ja hier den IBM und den Dell Server haben und es auf beiden hängt, obwohl nur auf dem IBM überhaupt produktiv gearbeitet wird. Es hängt aber nicht gleichzeitig, sondern erst erscheinen die Readfile auf $Directory auf dem IBM und dann mit etwas versatz - so als ob die Hänger repliziert werden - auf dem Dell Rechner.

Keiner sowas schonmal gesehen?

[Matrix316]

Jetzt was ganz anderes: Wenn ich auf dem Server in ein Verzeichnis gehe wo tausende von Dateien sind, erscheint im process monitor auch "Readfile" auf "$Directory", nur vom explorer.exe Prozess. Es dauert halt ein wenig bis der Ordner alle Dateien anzeigt. Allerdings stockt das ganze System da nicht.

Und vor jedem Readfile auf $Directory macht der DSFR Process QueryDirectory auf seinem Stagingordner.

UND, wenn die Bandbreite bei der Replikation niedriger ist, tauchen die Störungen weniger häufig auf, als wenn die Bandbreite höher ist.

Kann es sein, dass es einfach nur der Zugriff, von dfsr, auf die Dateien bzw. dem Stagingordner ist, der den Prozess zum halten bringt, weil einfach der Zugriff auf die Dateien und Ordner stockt?

[Matrix316]

Ok, es sieht so aus, als ob es die RDC Funktion gewesen war. Die war auf einem DFS Verzeichnis aktiv, was viele neue Dateien in Ordner bekam in denen viele Dateien vorhanden waren. Als ich die RDC dann deaktiviert hatte, lief es plötzlich fast ohne einen Hänger. Bei einem anderen Verzeichnis, wo nicht so viele neue Dateien kommen, aber wo die Userprofile liegen (wo sich die zig pst Dateien befinden) habe ich noch RDC aktiviert, weil ich nicht weiß, ob es so gut ist, wenn dauernd die teils Gigabyte (und mehr) großen PST Dateien komplett kopiert werden...

[BoRaaS]

aber wo die Userprofile liegen (wo sich die zig pst Dateien befinden) habe ich noch RDC aktiviert, weil ich nicht weiß, ob es so gut ist, wenn dauernd die teils Gigabyte (und mehr) großen PST Dateien komplett kopiert werden...

Funktioniert bei den PST Dateien hervorragend. Haben auch noch keine defekten PST Files gehabt.
Aber Vorsicht (http://blogs.technet.com/askperf/archive/2007/01/21/network-stored-pst-files-don-t-do-it.aspx)

[Matrix316]

Was Vorsicht? :)

[BoRaaS]

Was Vorsicht? :)
Naja da ist ein Link hinter "Vorsicht" :D
Geht halt darum das man PST nicht unbedingt auf ein Netzlaufwerk legen sollte, obwohl es natürlich viele/(alle) machen. Wir in der Firma natürlich auch.

[Matrix316]

Ok, die Phase haben wir schon durch und letztens alle PST Dateien ins lokale Profil verschoben, aber besser wurde es im Netz nicht. Die Leute hatten dann nur teils Probleme sich an den Rechnern anzumelden, weil auf c nicht genug Platz war, wenn sich mal wieder mehrere an einem Rechner angemeldet hatten. ;)