我有一个Windows服务，当前正在实例化大约十二个FileSystemWatcher实例，以监视整个公司网络上的共享文件夹中要处理的文件。
我正在考虑添加更多实例，所以我想知道这里是否有人(生产系统)有经验，生产系统可以可靠处理的FileSystemWatcher实例数量有哪些实际限制？
编辑:在我的情况下，InternalBufferSize属性未修改，因此InternalBufferSize是默认的8 KB ...我假设增加InternalBufferSize会影响系统可以同时运行的FileSystemWatcher实例的数量，因此这也是equasion的一部分...
编辑:如果您认为这仅是资源问题，并且仅取决于系统的可用内存量或其他硬件方面，请分享您的经验或指向证实您观点的文档或文章的链接...我会我真的很想听听那些达到生产极限的人，而不管他们的硬件规格如何，所以请在投票关闭之前，请考虑在不到20分钟的时间内有其他7个人对听到对此有极限要求的人表示兴趣...
最佳答案
封面下的FileSystemWatcher使用ReadDirectoryChangesW http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx。这是一个相当便宜的操作，只是从更改中完成的目录中读取。
结果存储在内核缓冲区中，然后再复制到您自己的FileSystemWatcher内存缓冲区中。
这是要考虑的两个OS资源，即由CreateFile调用FileSystemWatcher创建的Handle以及每个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
关于c# - 服务器可以处理的FileSystemWatcher实例数量有哪些实际限制？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/10195317/