服务器system文件损坏,用于监视网络服务器文件夹的System.IO.FileSystemWatcher - 性能注意事项...

从服务器负载的角度来看，在您描述的场景中使用IO.FileSystemWatcher进行远程更改通知可能是最有效的方法。它在内部使用FindFirstChangeNotification和ReadDirectoryChangesW Win32 API函数，然后以优化的方式与网络重定向器通信(假设使用标准的Windows网络：如果使用第三方重定向器，并且它不支持所需的功能，则赢得了什么都不行。 .NET包装器还使用异步I / O和所有内容，进一步确保了最高效率。

这个解决方案唯一的问题是它不是很可靠。除了必须暂时处理暂时离开的网络连接(这不是太大的问题，因为IO.FileSystemWatcher将在这种情况下触发您可以处理的错误事件)，底层机制具有某些基本限制。从Win32 API函数的MSDN文档：

当缓冲区长度大于64 KB并且应用程序正在通过网络监视目录时，ReadDirectoryChangesW失败并返回ERROR_INVALID_PARAMETER。这是由于基础文件共享协议的数据包大小限制

为远程文件系统调用FindFirstChangeNotification时，可能不会返回通知

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

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

如果您要查找的文件具有序列号，请存储您收到通知的最后序列号，这样您就可以在将来的通知中查找“间隙”并处理您未收到通知的文件;

收到通知后，请始终执行完整目录扫描。这可能听起来很糟糕，但由于扫描是事件驱动的，它仍然比哑巴轮询更有效。此外，只要保留单个目录中的文件总数以及要扫描的目录数量(大约一千个左右)，无论如何，此操作对性能的影响应该非常小。

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

无论如何，如果你绝对必须使用文件系统观察者，只要你知道这些限制就可以正常工作，并且不希望每个修改/创建的文件都有1：1的通知。

所以，如果你有其他选择(基本上，编写文件的过程会以非文件系统的方式通知你：任何常规的RPC方法都会有所改进......)，那些从可靠性点来看绝对是值得研究的观点。