服务器可以处理的文件系统观察器实例数的实际限制是什么?

本文关键字：是什么 处理 文件系统 服务器 观察 实例 | 更新日期: 2023-09-27 18:31:20

我有一个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 中。

这是要考虑的两个操作系统资源，一个是通过调用 CreateFile by FileSystemWatcher 创建的句柄，以及内核中每个 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

相关文章：