当我执行繁重的磁盘操作时，如一次删除10k文件，networking共享变得无法响应，并且不会在短时间内提供文件。
这是我的configuration。 我有一个由两台Windows 2008 R2 Enterprise服务器组成的故障转移文件服务器群集。 每台服务器都是运行Windows Hyper-V的两台独立Dell Poweredge服务器上运行的虚拟机。 两台戴尔服务器都有专用的网卡连接Dell MD3000i SAN。 每个文件服务器VM都通过这个专用NIC路由其iSCSI连接，以连接到文件所在SAN上的卷。
如果我运行一个batch file，从远程机器上执行10k删除操作，该文件通过共享名称（即\\ fileserver \ sharename \ folder \ filename.jpg）引用该文件，则可以在共享发出之前执行1,000或8000次删除操作。 每次都是随机的。 具有讽刺意味的是，batch file将继续删除文件，但访问同一共享文件的其他服务器将被阻止。 我要删除的文件不会被其他服务器访问，所以locking这些特定的文件不是问题。
如果我在文件簇的主服务器上运行相同的batch file，并通过其本地path（即.x：\ folder \ filename.jpg）引用文件，则共享立即切断，其他服务器等待。 当我终止运行的batch file时，将继续访问该共享。
任何人都有一个想法，分享原因或我可以做什么来进一步诊断这个问题？ 任何build议，非常感谢。
更新注意：我已经隔离这个问题，只发生在主机框的边界内。 涉及VM复制这个问题的networkingstream量都没有到达主机箱连接到除SAN的iSCSI连接之外的物理交换机。 标准networkingstream量之外，iSCSI连接具有自己的专用交换机和专用子网到SAN。
这尖叫着某种资源的枯竭。 如果这是一个Linux主机，我会想，“这听起来像IO-Wait的船载。 检查操作系统级别的性能监视器，如mfinni指出。 您有两个方面可能会缩小瓶颈，这就是逻辑/物理磁盘性能以及iSCSInetworking连接上的networking性能。 PerfMon可以给你这个。 我根本不了解HyperV，但是如果它像VMWare一样，那么你在Hypervisor方面也有一些性能指标，你可以看看。 这样做。
作为一个理论 ，我的猜测是，您所做的元数据更新的高级别会导致iSCSI堆栈中某些固有的延迟扩大。 这反过来挤占其他I / O或元数据请求，这会导致您描述的症状，其他进程可能会在边缘方向得到一个字，因为MFT块正在被其他进程攻击。 iSCSI本身可能会导致这种情况，但VM层可能会增加自己的内部延迟。 如果确实存在这个问题，您可能需要考虑将iSCSI LUN呈现给pipe理程序，然后将生成的磁盘呈现给VM; 这样你就不依赖iSCSI的虚拟化networking适配器，而是依赖于物理networking适配器。
编辑：看来你可能在你手上有这种错误。 我要注意的PerfMon计数器是运行iSCSI连接的接口的“发送的字节数/秒”和“发送的数据包/秒”。 两者的组合应该给你你的平均数据包大小。 （或者，如果你有能力的话，把一个嗅探器扔进循环中，看看networking交换机上的数据包是什么样的，如果可以的话，这是更可靠的方法）如果数据包大小很小（比如说800字节），那么除了下面的TCP级别之外，您可以做的事情不多，看看您的群集节点和iSCSI目标之间可以进行哪种优化。 Server 2008对于TCP设置很挑剔，所以在这里可能会有收获。
好主。 事件查看器中是否有任何内容表明操作系统正在看到某种资源耗尽？ 你可以用perfmon检查吗？