System.IO.FileSystemWatcher 监视网络服务器文件夹 - 性能注意事项

Question

我想查看网络服务器上的文件夹树的更改。 这些文件都有特定的扩展名。 树中大约有 200 个文件夹和大约 1200 个带有我正在查看的扩展名的文件。

我无法编写在服务器上运行的服务（禁止！），因此解决方案必须位于客户端本地。 及时性并不是特别重要。 我可以忍受通知延迟一分钟或更长时间。 我正在监视创建、删除、重命名和更改。

使用 .NET System.IO.fileSystemWatcher 会给服务器带来很大的负载吗？

10 个独立的观察者来减少正在观察的文件夹/文件的数量怎么样？ （从 700 个文件夹减少到 200 个，总共从 5500 个文件减少到 1200 个）网络流量增加而不是减少？ 我的想法是对服务器进行重新洗牌，将观看的文件放在一棵树下。 我可能并不总是有这个选择，因此有观察者团队。

我想另一个解决方案是定期检查 FSW 是否在服务器上创建了过度的负载，或者是否由于一大堆 SysAdmin 类型的原因而无法工作。

有一个更好的方法吗？

Answer 1

从服务器负载的角度来看，使用 IO.FileSystemWatcher 对于您描述的场景中的远程更改通知可能是最有效的方法。 它使用 FindFirstChangeNotification 和 ReadDirectoryChangesW Win32 API 内部函数，反过来以优化的方式与网络重定向器通信（假设标准 Windows 网络：如果使用了第三方重定向器，并且它不支持所需的功能，根本无法工作）。 .NET 包装器还使用异步 I/O 等，进一步确保最高效率。

该解决方案的唯一问题是它不太可靠。 除了必须处理暂时消失的网络连接（这并不是什么大问题，因为在这种情况下 IO.FileSystemWatcher 会触发一个您可以处理的错误事件），底层机制具有某些基本限制。 来自 Win32 API 函数的 MSDN 文档：

• ReadDirectoryChangesW 将失败并显示 ERROR_INVALID_PARAMETER。 这是由于底层文件共享协议的数据包大小限制所致

• 调用FindFirstChangeNotification 用于远程文件系统

换句话说：在高负载下（当您需要大缓冲区时）或，更糟糕的是，在随机的未指定情况下，您可能无法收到您期望的通知。 这甚至是本地文件系统观察程序的问题，但更多的是网络上的问题。 关于 SO 的另一个问题更详细地详细介绍了 API 固有的可靠性问题。

使用文件系统观察程序时，您的应用程序应该能够处理这些限制。 例如：

• 如果您要查找的文件有序列号，请存储您收到通知的最后一个序列号，以便您可以在未来的通知中查找“间隙”并处理您未收到的文件通知；

• 收到通知后，请始终进行完整目录扫描。 这听起来可能很糟糕，但由于扫描是事件驱动的，它仍然比哑轮询高效得多。 此外，只要将单个目录中的文件总数以及要扫描的目录数保持在一千左右，无论如何，此操作对性能的影响应该很小。

设置多个侦听器是您应该尽可能避免的事情：如果有的话，这将使事情变得不太可靠......

无论如何，如果您绝对必须使用文件系统观察者，只要您意识到这些限制，一切就可以正常工作，并且不要期望每个修改/创建的文件都会收到 1:1 通知。

因此，如果您有其他选择（本质上，让写入文件的进程以基于非文件系统的方式通知您：任何常规 RPC 方法都将是一种改进......），从可靠性角度来看，这些绝对值得研究看法。

Answer 2

我不认为带有 FSW 的计算机和其位置被监视的计算机之间存在任何类型的活动状态或通信。 换句话说，FSW 不会对联网操作系统执行 ping 操作来检查文件。

人们可以想象，当发生变化时，消息或事件仅被引发/发送到联网的FSW。

但这一切都只是猜测。 :)

Answer 3

使用 System.IO.FileSystemWatcher 一段时间后。 它不够稳定，无法处理传入太快的事件。 确保文件100%读取。 我使用简单的目录方法来搜索文件。 阅读完毕后，立即将文件复制到另一个文件夹中。 在您读取文件时将其与添加的新文件隔离。

定时器用于定期读取文件夹。 通过将已读取的文件复制到存档文件夹，这可以确保它不会被再次读取。 后续读取的将始终是新文件。

var fileNames = Directory.GetFiles(srcFolder);
foreach (string fileName in fileNames)
{
   string[] lines = File.ReadAllLines(fileName);
}

Answer 4

我曾多次使用 C# 中的文件系统监视器。 我第一次使用它们时，我遇到了它们停止工作的问题，主要是因为我正在处理报告更改的线程中的更改。

然而现在，我只是将更改推送到队列中并在另一个线程上处理该队列。 这似乎解决了我最初遇到的问题。 对于您的问题，您可以让多个观察者推送到同一个队列。

但是，我还没有将其用于解决您的问题规模。

Answer 5

根据我的经验，FSW 不会产生高网络流量。 但是，如果存在性能问题，那么使用多个观察程序并将其分解为更少的监视文件夹的方法听起来很合理。

不过，我在网络驱动器上使用 FSW 时遇到了一些大问题：删除文件总是会抛出错误事件，而不会抛出删除事件。 我没有找到解决方案，所以如果有办法解决的话，我现在避免使用 FSW...

Answer 6

MSDN 文档指出您可以使用 FileSystemWatcher 组件来监视网络驱动器上的文件系统更改。

它还表明观察器组件侦听文件系统更改通知，而不是定期询问目标驱动器是否有更改。

基于此，网络流量完全取决于您期望该网络驱动器的内容发生变化的程度。 FSW 组件不会增加网络流量。

Answer 7

观察者看起来 100% 可靠 - 只需观察观察者对象上的缓冲区大小即可。
我测试了数千次文件更新，没有丢失。

我建议使用多线程方法 - 触发器是文件观察器。
它可以为检测到的每个文件更改启动一个线程。 观察者可以更快地处理
溢出的可能性较小。 （使用异步线程）