服务器可以处理的FileSystemWatcher实例数量有哪些实际限制?

我有一个Windows服务,目前正在实例化大约十几个FileSystemWatcher实例,以监控整个公司网络中的共享文件夹,以便处理文件。

我正在考虑添加更多实例,所以我想知道这里是否有人(生产系统)有关生产系统可以可靠处理的FileSystemWatcher实例数量的实际限制是什么?

编辑:在我的情况下,不修改InternalBufferSize属性,因此InternalBufferSize是默认的8 KB …我假设InternalBufferSize的增加会影响系统可以同时运行的FileSystemWatcher实例的数量,因此这也是方程的一部分…

编辑:如果您认为这仅仅是一个资源问题,它只取决于可用内存的数量或系统的其他硬件方面,请分享您的经验或指向证实您的意见的文档或文章的链接……我会真的很想听听那些在生产中达到极限的人,无论他们的硬件规格如何,所以请在投票前仔细考虑其他7个人在不到20分钟的时间内表示有兴趣听到那些推动限制的人…

封面下的FileSystemWatcher使用ReadDirectoryChangesW http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx 。 这是一个相当便宜的操作,只是从完成更改的目录中读取。

结果存储在内核缓冲区中,然后将它们复制到FileSystemWatcher的内存缓冲区中。

这是要考虑的两个OS资源,由FileSystemWatcher调用CreateFile创建的句柄,以及每个FileSystemWatcher对象的内核中8KB(默认)缓冲区大小,它取消了系统的内核页面和无页面池。

您的FileSystemWatcher基本上在竞争这三种资源。

  1. CPU处理更改的时间
  2. 处理系统
  3. 页面池

你不太可能遇到问题(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

中央处理器

你会看到很多轶事证据表明,当这个用完时, FileSystemWatcher会停止工作。 一些目录更改被报告,有些则没有,并且在FileSystemWatcher大型实现上不可避免地你最终必须检测这些场景并自己进行目录列表,或者在轮询基础上进行。

笔记

如果您正在实施FileSystemWatcher注意;

  1. 缓冲结束运行
  2. 网络路径上的缓冲区大小超过64KB。

有关此对象的良好编码实践的更多信息,请访问http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018