System.IO.FileSystemWatcher ein Netzwerk-Server-Ordner zu überwachen - Leistungsaspekte

StackOverflow https://stackoverflow.com/questions/151804

Frage

Ich möchte eine Ordnerstruktur auf einem Netzwerkserver für Änderungen beobachten. Die Dateien haben alle eine bestimmte Nebenstelle. Es gibt etwa 200 Ordner im Baum und etwa 1200 Dateien mit der Endung ich gerade bin.

Ich kann keinen Dienst ausgeführt wird auf dem Server schreiben (off-limits!), So hat die Lösung für die Kunden vor Ort sein. Rechtzeitigkeit ist nicht besonders wichtig. Ich kann in Mitteilungen mit einer Minute oder mehr Verzögerung leben. Ich beobachte für Erstellen, Löschen, Umbenennen und Änderungen.

Würde mit .NET System.IO.FileSystemWatcher auf dem Server viel von einer Last erstellen?

Wie wäre es 10 separate Beobachter die Anzahl der Ordner / Dateien zu reduzieren, beobachtet zu werden? (Bis zu 200 von 700 Ordnern, 1200 von 5500 Dateien insgesamt) Mehr Netzwerkverkehr statt weniger? Meine Gedanken sind eine Umbesetzung auf dem Server die überwachten Dateien unter 1 Baum zu setzen. Ich kann nicht immer diese Option habe daher das Team von Beobachtern.

Ich nehme an, die andere Lösung eine periodische Überprüfung ist, wenn der FSW eine übermäßige Last auf dem Server erzeugt, oder wenn es nicht für eine ganze Reihe von SysAdmin Typ Gründen nicht funktioniert.

Gibt es einen besseren Weg, dies zu tun?

War es hilfreich?

Lösung

Von einer Serverbelastung Sicht mit dem IO .FileSystemWatcher für Fernänderungsbenachrichtigungen in dem Szenario, das Sie beschreiben, ist wahrscheinlich die effizienteste Methode möglich. Es nutzt die FindFirstChangeNotification und ReadDirectoryChangesW Win32-API-Funktionen intern, die mit dem Netzwerk-Redirector in einer optimierten Art und Weise wiederum kommunizieren (unter der Annahme, Standard-Windows-Netzwerken : wenn ein Redirector dritter verwendet wird, und es die Dinge nicht überhaupt nicht über die erforderliche Funktionalität unterstützen, arbeiten). Der .NET-Wrapper verwendet auch Asynchron-I / O und alles, weiter maximale Effizienz zu gewährleisten.

Das einzige Problem mit dieser Lösung ist, dass es nicht sehr zuverlässig ist. Anders als mit mit Netzwerkverbindungen behandeln vorübergehend weg (was nicht zu viel von einem Problem, da IO.FileSystemWatcher wird ein Fehlerereignis in diesem Fall Feuer, das Sie behandeln können), hat der zugrunde liegende Mechanismus bestimmte grundlegende Einschränkungen. Aus der MSDN-Dokumentation für die Win32-API-Funktionen:

  • ReadDirectoryChangesW nicht mit ERROR_INVALID_PARAMETER, wenn die Pufferlänge größer als 64 KB ist und die Anwendung ein Verzeichnis über das Netzwerk überwacht. Dies ist aufgrund einer Paketgrößenbeschränkung mit den zugrunde liegenden File-Sharing-Protokollen

  • Benachrichtigungen nicht zurückgegeben werden kann, wenn FindFirstChangeNotification für ein Remote-Dateisystem

Mit anderen Worten: unter hoher Last (wenn Sie einen großen Puffer benötigen würde) oder, schlimmer noch, unter zufälligen Umständen nicht spezifiziert, können Sie nicht die Benachrichtigungen erhalten Sie erwarten. Dies ist auch ein Problem mit dem lokalen Dateisystem-Beobachtern, aber es ist viel eher ein Problem über das Netzwerk. Eine andere Frage hier auf SO Details die inhärenten Probleme mit der Zuverlässigkeit mit der API in etwas mehr Detail.

Wenn die Dateisystem-Beobachter verwenden, sollten Sie Ihre Anwendung in der Lage sein, mit diesen Einschränkungen umgehen. Zum Beispiel:

  • Wenn die Dateien, die Sie für die Sequenznummern gesuchte haben, speichern Sie die letzte Sequenznummer Sie benachrichtigt wurde, so dass man für ‚Lücken‘ auf zukünftige Benachrichtigungen betrachten und bearbeiten Sie die Dateien, für die Sie nicht bekommen mitgeteilt;

  • Bei Empfang einer Benachrichtigung, immer ein vollständiges Verzeichnis Scan tun. Dies kann wirklich schlecht klingen, aber da die Scan ereignisgesteuert ist, ist es noch viel effizienter als stumm Polling. Auch, wie lange, wie Sie die Gesamtzahl der Dateien in einem einzigen Verzeichnis zu halten, sowie die Anzahl der Verzeichnisse zu scannen, unter tausend oder so, die Auswirkungen dieses Vorgangs auf der Leistung sollten ziemlich gering sein sowieso.

mehrere Zuhörer Einrichten ist etwas, das man so viel wie möglich vermeiden soll: wenn überhaupt etwas, das wird die Dinge noch weniger zuverlässig ...

Wie auch immer, wenn Sie absolut Haben Dateisystem-Beobachter zu verwenden, können die Dinge funktionieren OK, solange Sie von den Beschränkungen bewusst sind, und erwarten Sie nicht 1: 1-Benachrichtigung für jede Datei geändert / erstellt.

Also, wenn Sie andere Optionen haben (im Wesentlichen den Prozess mit Schreiben der Dateien, die Sie in einem Nicht-Dateisystem basiert Art und Weise mitteilen: jede regelmäßige RPC-Methode wird eine Verbesserung sein ...), sind diejenigen, auf jeden Fall lohnt ein Blick in aus eine Zuverlässigkeit Sicht.

Andere Tipps

Ich habe die Dateisystem-Beobachter von C # einige Male verwendet. Das erste Mal, wenn ich sie gebraucht, ich hatte Probleme mit ihnen zu arbeiten zu stoppen, vor allem aufgrund der Tatsache, dass ich die Änderungen in dem Thread verarbeitet wurde, der die Änderung berichtet.

Nun aber, schiebe ich nur die Änderung auf eine Warteschlange und verarbeiten, um die Warteschlange auf einem anderen Thread. Dies scheint das Problem zu lösen ich ursprünglich hatte. Für Ihr Problem, könnte man mehrere Beobachter Aufschieben auf die gleiche Warteschlange hat.

Allerdings habe ich diese mit Ihrer Art von Skala von Problem nicht verwendet.

Nach meiner Erfahrung ein FSW schafft keinen hohen Netzwerkverkehr. Wenn jedoch ein Performance-Problem gibt es, Ihr Ansatz mehrere Beobachter verwenden und es auf weniger Ordner beobachtete brechen wird klingt vernünftig.

hatte ich einige große Probleme mit FSW auf Netzlaufwerken, aber: eine Datei immer Löschen des Fehlerereignis warf, nie das gelöschte Ereignis. Ich habe nicht eine Lösung finden, so dass ich vermeiden jetzt FSW zu verwenden, wenn es eine Möglichkeit, um es ist ...

Die MSDN-Dokumentation zeigt , dass können Sie die Filesystemwatcher-Komponente verwenden, um Dateisystem Änderungen in einem Netzwerk Laufwerk zu beobachten.

Es zeigt auch, dass die Beobachter-Komponente für Dateisystem-Änderungsbenachrichtigungen lauscht anstatt periodisch das Ziellaufwerk für Änderungen abzufragen.

Auf der Grundlage, dass die Menge des Netzwerkverkehrs völlig davon abhängig, wie viel Sie die Inhalte dieses Netzlaufwerk zu ändern erwarten. Die FSW-Komponente wird nicht auf das Niveau des Netzwerkverkehrs hinzuzufügen.

Watcher sieht 100% zuverlässig - nur die Puffergröße auf dem Beobachter-Objekt sehen. Ich habe Tausende von File-Updates getestet, keine verloren.

Ich empfehle einen Multi-Threaded-Ansatz - Der Auslöser des Datei-Watcher ist. Es kann einen Thread für jede Datei-Änderung starten erkannt. Der Beobachter kann viel schneller verarbeiten mit weniger Wahrscheinlichkeit des Überlaufes. (Verwendung Async Gewinde)

Nach System.IO.FileSystemWatcher Verwendung für einige Zeit. Es ist nicht stabil genug, um Ereignisse zu behandeln, die zu schnell kommen. Um sicherzustellen, dass 100% der Dateien zu lesen. Ich verwende einfache Verzeichnis Methoden durch die Dateien zu suchen. Nach der Lektüre kopiert sofort die Dateien in einem anderen Ordner. Zur Isolierung aus neuen Dateien hinzugefügt, während Sie die Dateien lesen.

Timer wird verwendet, um regelmäßig den Ordner zu lesen. Durch das Kopieren der bereits gelesenen Datei Archivordner, diese stellen Sie sicher, es wird nicht wieder gelesen werden. Die nachfolgende Lese immer neue Dateien sein. 

var fileNames = Directory.GetFiles(srcFolder);
foreach (string fileName in fileNames)
{
   string[] lines = File.ReadAllLines(fileName);
}

Ich würde nicht denke, dass es irgendeine Art von aktivem Zustand oder der Kommunikation zwischen dem Computer mit dem FSW und dem Computer, deren Position überwacht wird. Mit anderen Worten wird die FSW nicht Pingen die vernetzten OS auf der Datei zu überprüfen.

Man sollte meinen, dass eine Nachricht oder ein Ereignis ist nur angehoben / zum vernetzten FSW gesendet, wenn eine Änderung auftritt.

Aber das ist alles nur Spekulation. :)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top