28

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

我正在考虑添加更多实例，所以我想知道这里是否有人有经验（使用生产系统）关于FileSystemWatcher生产系统可以可靠处理的实例数量的实际限制是什么？

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

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

4

1 回答 1

20

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

结果存储在内核缓冲区中，然后再复制到您自己的内存缓冲区中FileSystemWatcher。

这是要考虑的两个操作系统资源，调用CreateFileby创建的句柄FileSystemWatcher，以及内核中每个FileSystemWatcher对象的 8KB（默认）缓冲区大小，这些缓冲区从系统的内核分页和无分页池中带走。

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

  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您的大型实现中不可避免地最终不得不检测这些情况并自己列出目录，或者在轮询基础上进行。

笔记

如果您正在实施FileSystemWatchers 的负载，请注意；

  1. 缓冲区溢出
  2. 网络路径上的缓冲区大小大于 64KB。

更多关于此对象的良好编码实践，http://bytes.com/topic/visual-basic-net/answers/536125-filesystemwatcher-across-network#post2092018

于 2012-04-17T19:16:54.987 回答