28

I have a windows service that is currently instantiating about a dozen FileSystemWatcher instances to monitor shared folders across the corporate network for files to be processed.

I am looking into adding more instances so I'm wondering if anyone here has experience (with production systems) as to what are practical limits on number of FileSystemWatcher instances a production system can reliably handle?

Edit: In my case, the InternalBufferSize property is not modified so the InternalBufferSize is the default 8 KB... I assume the increase in InternalBufferSize would affect the number of FileSystemWatcher instances a system can run simultanesouly so that is also a part of the equasion...

Edit: If you think that this is exclusively a resource issue and it only depends on the amount of available memory or some other hardware aspect of the system, please share your experience or links to documentation or articles that corroborate your opinion... I would really like to hear from someone who reached the limit in production regardless of their hardware specs so please before voting to close consider that 7 other people in less than 20 minutes have shown interest in hearing from someone who pushed the limits on this...

4

1 に答える 1

20

FileSystemWatcherカバーの下ではReadDirectoryChangesW http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspxを使用します。これは、変更時に完了するディレクトリからの読み取りにすぎない、かなり安価な操作です。

結果は、独自のメモリ バッファにコピーされる前に、カーネル バッファに格納されますFileSystemWatcher。

これは、考慮すべき 2 つの OS リソース、 by の呼び出しによって作成されたハンドルCreateFile、およびシステムのカーネル ページ プールと非ページ プールから取り去るFileSystemWatcher各オブジェクトのカーネル内の 8KB (デフォルト) バッファ サイズです。FileSystemWatcher

あなたFileSystemWatcherの は基本的にこれら 3 つのリソースをめぐって競合しています。

  1. 変更を処理するためのCPU時間
  2. システム上のハンドル
  3. ページプール

(2) で問題が発生する可能性はほとんどありません。x86 を実行している電源システム (CPU の負荷) で (3) に問題が発生する可能性があります。それ以外の場合 (1) が制限になります。

ハンドル

ハンドルは使い尽くされています (特に x86 の場合)。詳細については、http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspxを参照してください。

しかし、使い果たす前に 1600 万以上のハンドル (x86 でも) があれば、意図的には、それは無限のリソースと考えられます。OS の制限に達するかなり前に、CPU 処理の変更を使い果たします。

ページ/非ページ プール

ページ/非ページ プールは、タスク マネージャーで確認できます。x86 では非常に有限です。詳細はこちらhttp://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

CPU

これが使い果たされると、FileSystemWatcherある種の機能が停止するという逸話的な証拠がたくさんあります。一部のディレクトリ変更は報告され、一部は報告されず、大規模な実装では必然的に、FileSystemWatcherこれらの機会を検出してディレクトリのリストを自分で作成するか、ポーリングベースで行う必要があります。

ノート

大量の s を実装している場合は、次FileSystemWatcherの点に注意してください。

  1. バッファオーバーラン
  2. ネットワーク パスのバッファ サイズが 64KB を超えています。

このオブジェクトの優れたコーディング プラクティスについて詳しくは、 http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018をご覧ください。

于 2012-04-17T19:16:54.987 に答える