私たちは、独自の Xml 言語仕様で実行できるアクションを備えた内部会計パッケージ システム用のツールのようなテキスト エディターを作成しています。これらのマクロ コマンドは Xml ファイルで指定されており、開いているファイルが外部で変更されているかどうかを監視する機能が必要です。
唯一の問題は、パスが異なる 20 ～ 30 個のファイルが同時に開かれていることです。このシナリオで複数の FileSystemWatcher を使用するとよいでしょうか? または、ルート ドライブを監視し、エディターで開いているファイルに一致する特定のイベントをキャッチする方がよいでしょうか (ただし、多くのイベントが発生する可能性があります)。
一部はローカル ドライブ (C、D、E) で、その他はネットワーク ドライブ (U、X、G、H) です。ファイルは非常に分厚く、約 300 ～ 400Kb です。
最初にいくつかの事実
1- FileSystemWatcher は ReadDirectoryChanges のラッパーです
2- ReadDirectoryChanges は、ReadDirectoryChanges への呼び出しごとに、非ページ プール メモリからイベントをキャッシュするためのカーネル バッファーを作成します。
上記のポイント 2 の意味は、FileSystemWatcher の各インスタンスが非ページ プールからメモリを割り当てることです。これはカーネル モード ドライバなどに使用されるメモリであり、動的に拡張できますが、システムのリソース (マシンに搭載されているメモリの量) に基づいて起動時に計算される最大サイズに「ハード」に制限されることに注意してください。 ）。
以上のことから、次のように考えてみます。
あなたが期待する変化の量なら。これが低い場合は、回避できる最小のバッファー サイズを持つ複数のウォッチャーを使用します。
また、大きなバッファーを使用することにした場合、ネットワーク ドライブの監視では 64K を超えるバッファー サイズはサポートされず、それを超えるとイベントが取得されないことにも注意してください。
ほぼ確実に複数のウォッチャーが必要になると思います。FileSystemWatchers バッファがオーバーフローする可能性があり、そうしないとイベントを見逃す可能性があります。バッファ サイズは ( を使用して) 変更できますが、最大InternalBufferSize64KB までしか変更できません。
ただし、ネットワークドライブのFileSystemWatcher使用FindFirstChangeNotificationは完全に信頼できるわけではないことに注意してください（特に負荷が高い場合、そうでない可能性もあります）。そのため、ネットワークからすべてのイベントを受信しないことを期待して計画する必要があります。私の理解は複数のウォッチャーがいる場合、信頼性はさらに悪化します。
要約すると、バッファを増やし、できるだけフィルタリングし、バッファをオーバーフローさせずにできるだけ少ないウォッチャーを使用する必要があると思います。おそらく、それを正しく行うには少し試行錯誤する必要があります.