を使用しFileSystemWatcherてフォルダー内の変更を監視していますが、短時間で数百を超える変更を行うとすぐに、内部バッファーがオーバーフローするため、それらの一部を見逃します。だから私は増やしたいですInternalBufferSize（私はそれが実際には問題を解決しないことを知っていますが、それはそれが起こる可能性を低くします）、しかし私はドキュメントでこの警告を見ます：
ただし、バッファサイズを増やすと、ディスクにスワップアウトできない非ページメモリから発生するため、コストがかかります。そのため、バッファをできるだけ小さくしてください。
だから私の質問は：それは本当に重要ですか？今日のほとんどのコンピューターには少なくとも1GBのRAMがあるので、バッファーサイズを（デフォルトの8KBではなく）1MBに設定した場合、1MBをディスクにスワップアウトできないかどうかは問題ではないようです。それとも私は何かが足りないのですか？ページング/非ページングメモリなどの低レベルのものについてはよくわからないので、どのような影響があるかわかりません...
バッファが割り当てられるメモリは確かに貴重なリソースです。Windowsはメモリプールの枯渇にうまく対処せず、ドライバーはランダムに失敗し始めます。プールのサイズは動的に設定され（ただし変更可能）、使用可能なRAMの量によって異なります。
FSWが要求するデフォルトのバッファサイズは8192バイトです。最近のマシンではあまりありません。基盤となるwinapi関数では、64KBを超える値を要求することはできません。エントリは、バッファが12バイトにファイルパスの長さを2倍したものです。したがって、最悪の場合は、バッファがなくなる前に8192 /（12 + 260 * 2）=15通知です。ドライブ全体を監視するか、監視しているディレクトリのディスクトラフィックが非常に多い場合を除いて、ほとんどの状況で問題なく機能するはずです。その場合、より大きなバッファーを要求するのは公平です。黄金の公式はありません。バッファに問題があることがわかるように、必ずFileSystemWatcher.Errorイベントを実装してください。
ほとんどの場合、FSWイベントに注意深く対処する必要があります。プロセスがまだファイルをロックしている間に発生します。そのため、ファイルを開いたりコピーしたりするのは面倒です。これに対処するには、通知をスレッドセーフキューに入れ、別のスレッドを使用して、必要に応じて繰り返しファイルのロックを取得しようとします。このようなキューは、バッファをすばやく空にするための非常に優れた方法でもあります。今のところ注意しなければならないのは、OOMでプログラムがクラッシュするような妥当な比率を超えてキューが爆発しないことだけです。
非ページメモリのサイズには制限があり（更新：Windowsの最新バージョンには以前のバージョンほど厳密な制限はなく、メモリの量はWindowsで使用可能なRAM全体に依存する柔軟な値になりました）、非常に重要ですカーネルモードの住民（デバイスドライバー、OS自体）に。厳しい制御なしでそれを消費すると、システムがすぐに不安定になる可能性があり、さらに悪いことに、この不安定の原因を見つけることができません。
また、コメントが示すように、重要なのはバッファサイズではなく、バッファからデータを削除する速度です。
ほとんどの場合、ファイルシステムフィルタードライバーはFileSystemWatcherよりも優れた仕事をします。利点は、必要なログバッファを使用できることです（必要なメモリに作成し、ページングされていないメモリに制限されないため）。また、イベントが発生した後ではなく、発生時に処理できます。また、FileSystemWatcherよりも細かい粒度でリクエストをフィルタリングできます。
FileSystemWatcherイベントで読み取るコンシューマープロデューサーの設計を検討してください。
処理する必要のないFileSystemWatcherイベントがある場合は、すぐにそれらを閉じます。
または、一部の人が他の人よりも速く処理できる場合は、合計カウントダウンを維持するために別のコレクションがあります。