Was sind praktische Grenzen für die Anzahl der FileSystemWatcher-Instanzen von einem server umgehen kann?

Ich habe einen windows-Dienst, der derzeit die Instanziierung über ein Dutzend FileSystemWatcher Instanzen überwachen freigegebener Ordner über das corporate Netzwerk für Dateien verarbeitet werden.

Ich bin auf der Suche in hinzufügen von mehr Instanzen, so Frage ich mich, ob jemand hier Erfahrungen (mit Produktion Systeme) was sind die praktischen Grenzen auf der Anzahl der FileSystemWatcher Instanzen einer Produktions-system sicher behandeln können?

Edit: In meinem Fall, die InternalBufferSize-Eigenschaft festlegen, ist nicht so modifiziert, dass die InternalBufferSize ist die Standard-8 KB... ich nehme an die Zunahme der InternalBufferSize würde auch auf die Anzahl der FileSystemWatcher Instanzen, die ein system ausführen kann, simultanesouly so, dass ist auch ein Teil des equasion...

Edit: Wenn Sie denken, dass dies ausschließlich ein Ressourcen-Problem und es hängt nur von der Menge der verfügbaren Speicher oder andere hardware-Aspekt des Systems, teilen Sie bitte Ihre Erfahrungen oder links zu Dokumentationen oder Artikel, die bestätigen deine Meinung... ich würde wirklich gerne hören von jemandem, der die Grenze erreicht, in der Produktion, unabhängig von Ihrer hardware-Spezifikationen also bitte vor der Abstimmung zu schließen bedenkt, dass 7 andere Leute in weniger als 20 Minuten haben gezeigt, Interesse zu hören, von jemandem, der stieß an die Grenzen dieser...

  • Warum nicht verwenden Sie eine oder wenige und nur filter aus innen - wie vorgeschlagen in der Dokumentation To avoid a buffer overflow, use the NotifyFilter and IncludeSubdirectories properties so you can filter out unwanted change notifications - würde das funktionieren?
  • der überwachte Ordner auf verschiedenen Servern über das corporate network...
  • Sie sollte hinzufügen, dass ich denke - könnte helfen, Ihre Frage (nicht sicher, warum mich, schaut ok, zu mich) ist es ein eher individuelles problem. So haben Sie z.B. 'one pro remote-Maschine'?
  • es ist ein oder mehr pro remote-Maschine, die je auf den freigegebenen Ordner-Struktur... Frage geändert.
  • nach Ihrer Logik können wir schließen, dass alle 7 upvotes in weniger als 20 Minuten kommen von Menschen, die besitzen die exakt gleiche hardware, die ich tun? Sind Sie sicher, dass die Frage irrelevant für Leute, die haben 32 oder 16 GB RAM auf Ihrem Server oder unter Windows Server 2008 Enterprise, oder haben Ihre CPUs laufen auf 2,00 GHz statt 2.27@GHz?
  • sagen Sie, dass die Anzahl der FileSystemWatcher-Instanzen, die ein server verarbeiten kann, ist begrenzt nur durch den verfügbaren Ressourcen? Wenn ja, welche Erfahrung oder Dokumentation sind Sie auf sich auf, bitte?
  • Ich denke, dies ist der link, der am besten beschreibt, was Sie nach und kommt von MS, dass die Menschen direkt FileSystemWatcher über das Netzwerk von Walter Wang MSFT. Und dieses FileSystemWatcher und windows 7. Das ist vor allem über den Pufferüberlauf aber es ist ähnlich, es weist auf Beschränkung der Puffer im system-Adressraum und erstellt pro + Netzwerk-Besonderheiten + medium/heavy Vorschläge. Immer noch nicht das posting als Antwort nicht klar, vollständig.
  • danke für den link, aber die InternalBufferSize ist eine Eigenschaft eines einzelnen FileSystemWatcher Instanz, die hilfreich sein können in Situationen, in denen ein FileSystemWatcher behandeln müssen ein hohes Volumen von fast gleichzeitige file-system schreibt. Es muss nicht direkt beziehen sich auf die Frage, wie viele simultensous Instanzen von FileSystemWatcher ein system verarbeiten kann...
  • Es spielt eigentlich (wie ich verstanden habe und warum ich es gepostet), die Puffer (für jede) stammen aus dem kernel-Speicher-pools - und es ist ein Puffer auf der API-Aufruf-Seite als auch mit dem Datei-system. Also, die Menge an Speicherplatz nehmen Sie ansammelt.

InformationsquelleAutor Dean Kuga | 2012-04-17
  1. 17

    FileSystemWatcher unter der Abdeckung verwendet ReadDirectoryChangesW http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs. 85).aspx. Dies ist eine Recht preiswerte operation, die nur aus dem Verzeichnis Lesen, dass schließt auf eine änderung.

    Werden die Ergebnisse gespeichert und zu einem kernel-Puffer, bevor Sie kopiert werden, in Ihrem eigenen Speicher-Puffer FileSystemWatcher.

    Dass die zwei OS-Ressourcen zu berücksichtigen, wird der Handle erstellt durch den Aufruf CreateFile durch FileSystemWatcher, und die 8KB (Standard) Puffergröße in der Kernel für jeden FileSystemWatcher Objekt, das führt Weg von Ihrem system-Kernel Ausgelagerten und nicht Ausgelagerten Pools.

    Ihre FileSystemWatchers sind im wesentlichen im Wettbewerb um diese drei Ressourcen.

    1. CPU Zeit, um die änderungen zu verarbeiten
    2. Griffe auf das system
    3. Seite Pool

    Es ist unwahrscheinlich, dass ein problem mit (2).
    Wahrscheinlich ein problem mit (3) auf einem power system (Lasten der CPU) ausgeführt x86.
    Sonst (1) Ihre Grenze.

    Griffe

    Griffe sind erschöpfbare (speziell auf x86), mehr dazu hier, http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx

    Aber bei 16million+ Griffe (auch auf x86), bevor Sie laufen, für Ihre intententions, würde ich denken, es als eine unendliche Ressource. Sie erschöpfen die CPU-Verarbeitung ändert sich nun, bevor Sie auf irgendwelche OS-Grenze.

    Seite/Nicht Ausgelagerten Pools

    Seite/Nicht Ausgelagerten Pools gesehen werden kann, die im task-manager. Auf x86-Sie sind sehr endlich. Mehr hier, http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs. 85).aspx#memory_limits

    CPU

    Sehen Sie Ladungen von anekdotischen Beweise, dass, wenn diese erschöpft ist, wird FileSystemWatcher irgendwie nicht mehr funktioniert. Einige directory-änderungen gemeldet bekommen, einige nicht, und unvermeidlich auf die große Implementierungen von FileSystemWatcher Sie am Ende mit, um erkennen Sie diese Gelegenheiten und tun, ein Verzeichnis-Auflistung sich selbst, oder haben es auf ein polling-Basen.

    Hinweise

    Wenn Sie die Umsetzung einer Last von FileSystemWatchers aufpassen;

    1. Puffer überläuft
    2. Puffer-Größe größer als 64 KB auf Netzwerk-Pfade.

    Mehr auf gute Codierung der Praxis für dieses Objekt hier, http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018

    InformationsquelleAutor
Schreibe einen Kommentar