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

Question

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

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

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

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

Answer 1

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

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

这是要考虑的两个操作系统资源,调用CreateFileby 创建的句柄FileSystemWatcher,以及内核中每个FileSystemWatcher对象的8KB(默认)缓冲区大小,它从系统的内核分页和无分页池中取出.

你FileSystemWatcher的本质上是在争夺这三种资源.

你不太可能遇到问题(2).可能会在运行x86的电源系统(CPU负载)上遇到(3)问题.否则(1)将是你的限制.

手柄

但是在你耗尽之前,在1600万+处理(甚至在x86上),为了你的意图,我认为它是一种无限的资源.在达到任何操作系统限制之前,您将耗尽CPU处理更改.

页面/非分页池

可以在任务管理器中看到页面/非分页池.在x86上,它们非常有限.更多信息,请访问http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#memory_limits

中央处理器

你会看到大量轶事证据表明,当这种情况耗尽时,就会FileSystemWatcher停止工作.一些目录更改会被报告,有些则不会,并且在大型实现中不可避免地FileSystemWatcher最终必须检测这些场景并自行执行目录列表,或者在轮询基础上执行此操作.

笔记

如果你正在实施一系列FileSystemWatcher的注意;

我只是想补充一下这个问题，根据我一次创建超过 5000 个 FileSystemWatcher 对象的经验（结合轮询），我从未遇到过创建大量 FileSystemWatcher 对象的任何重大问题。 (3认同)