我有一个Windows服务，目前正在实例化大约十几个FileSystemWatcher实例，以监控整个公司网络中的共享文件夹，以便处理文件。
我正在考虑添加更多实例，所以我想知道这里是否有人（生产系统）有关生产系统可以可靠处理的FileSystemWatcher实例数量的实际限制是什么？
编辑：在我的情况下，不修改InternalBufferSize属性，因此InternalBufferSize是默认的8 KB ...我假设InternalBufferSize的增加会影响系统可以同时运行的FileSystemWatcher个实例的数量，以便也是方程式的一部分...
编辑：如果您认为这只是一个资源问题，而且只取决于系统的可用内存量或其他硬件方面，请分享您的经验或链接到证实您的意见的文档或文章。 。我真的很想听听那些在生产中达到极限的人，无论他们的硬件规格如何，所以请在投票之前结束考虑，其他7个人在不到20分钟的时间里就已经表示有兴趣听取那些推动限制的人。 ..
答案 0 :(得分：17)
FileSystemWatcher使用ReadDirectoryChangesW http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx。这是一个相当便宜的操作，只是从更改完成的目录中读取。
结果存储在内核缓冲区中，然后将它们复制到FileSystemWatcher的内存缓冲区中。
这是要考虑的两个OS资源，由CreateFile调用FileSystemWatcher创建的句柄，以及每个FileSystemWatcher内核中的8KB（默认）缓冲区大小从您的系统的内核分页和无分页池中删除的对象。
您的FileSystemWatcher基本上正在竞争这三种资源。
你不太可能遇到问题（2）。 可能会在运行x86的电源系统（CPU负载）上遇到（3）问题。 否则（1）将是你的限制。
<强>把手
句柄是耗尽的（特别是在x86上），更多关于这一点，http://blogs.technet.com/b/markrussinovich/archive/2009/09/29/3283844.aspx
但是在你用完之前，在1600万+处理（甚至在x86上），为了你的意图，我认为它是一种无限的资源。在达到任何操作系统限制之前，您将耗尽CPU处理更改。
页面/非分页池
可以在任务管理器中看到页面/非分页池。在x86上，它们非常有限。更多信息，http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits
<强> CPU
你会看到大量轶事证据表明，当这种情况耗尽时，FileSystemWatcher会停止工作。有些目录更改会被报告，有些则不会，并且在FileSystemWatcher的大型实现中不可避免地你最终必须检测这些场景并自己进行目录列表，或者在轮询基础上进行。
备注
如果您正在实施FileSystemWatcher的注意;
此处有关此对象的良好编码习惯的更多信息，http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018