對服務器可以處理的FileSystemWatcher實例數量有何限制？

Question

我有一個windows服務，當前正在實例化大約12個FileSystemWatcher實例，以監視整個公司網絡上的共享文件夾以處理要處理的文件。

我正在尋找添加更多的實例，所以我想知道這裏的任何人是否有生產系統可以可靠處理的FileSystemWatcher實例數量的實際限制的經驗（使用生產系統）？

編輯：在我的情況下，InternalBufferSize屬性沒有修改，因此InternalBufferSize是默認的8 KB ...我認爲InternalBufferSize的增加會影響系統可以運行的FileSystemWatcher實例的數量，這也是一個一部分equasion ...

編輯：如果你認爲這只是一個資源問題，它只取決於系統的可用內存或其他硬件方面的數量，請分享您的經驗或文檔鏈接或者證實你的觀點的文章...我真的很想聽到一些人在生產中達到了極限，無論他們的硬件規格如何，所以請在投票結束前考慮在不到20分鐘時間內再考慮另外7人已經表示有興趣聽到來自推動限制的人...

Answer 1

FileSystemWatcher下蓋使用ReadDirectoryChangesWhttp://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx。這是一個相當便宜的操作，它只是從完成更改的目錄讀取的。

將結果複製到您自己的內存緩衝區FileSystemWatcher中之前，結果會存儲在內核緩衝區中。

這兩個操作系統的資源來考慮，在內核中通過調用CreateFile由FileSystemWatcher創建的句柄，和8KB（默認）的緩衝區大小爲每個FileSystemWatcher對象從系統內核分頁，並沒有帶走 - 包池。

您的FileSystemWatcher s基本上正在競爭這三個資源。

1. CPU時間來處理系統上的變化
2. 把手
3. 頁面池

你不可能打一個問題，（2）。 可能在運行x86的電源系統（CPU負載）上遇到（3）的問題。 否則（1）將是你的限制。

把手

句柄是枯竭的（特別是在x86），更在這這裏，http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx

但在1600萬個+手柄（甚至在x86），你用完之前，爲您intententions，我把它想象成一個無限的資源。在達到任何操作系統限制之前，您將耗盡CPU處理更改。

頁/非分頁池

頁/非分頁池可以在任務管理器中看到。在x86上它們都是很有有限。這裏更多，http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

CPU

你會看到的傳聞證據表明，當這個被耗盡，FileSystemWatcher排序停止工作負載。某些目錄更改會被報告，有些不會，並且不可避免地會在大型實現FileSystemWatcher時最終不得不檢測這些會話並執行自己的目錄列表，或者在輪詢基礎上執行。

注意

如果您正在實施的FileSystemWatcher s的負載注意;

1. 緩衝器超限運行
2. 緩衝區大小大於64KB上的網絡路徑。

更良好的編碼習慣在這裏這個對象，http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018