c# - 服务器可以处理的 FileSystemWatcher 实例数量的实际限制是什么？

Question

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

我正在研究添加更多实例，所以我想知道这里是否有人有经验(使用生产系统)关于生产系统可以可靠处理的 FileSystemWatcher 实例数量的实际限制是多少？

编辑:在我的例子中，InternalBufferSize 属性未被修改，因此 InternalBufferSize 是默认的 8 KB...我假设 InternalBufferSize 的增加会影响系统可以运行的 FileSystemWatcher 实例的数量同时这也是等式的一部分...

编辑:如果您认为这完全是一个资源问题并且仅取决于可用内存量或系统的某些其他硬件方面，请分享您的经验或文档或文章的链接以证实您的观点。 . 我真的很想听听那些无论硬件规范如何都达到了生产极限的人的意见，所以请在投票结束之前考虑一下，在不到 20 分钟的时间内，有 7 个人表示有兴趣听取那些突破这一限制的人的意见。 ..

Answer 1

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

在将结果复制到您自己的 FileSystemWatcher 内存缓冲区之前，结果存储在内核缓冲区中。

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

您的 FileSystemWatcher 本质上是在争夺这三种资源。

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

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

handle

句柄是用尽的(特别是在 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