我们最近将一个在2008 hyper-v上运行的文件共享机器从我们的本地networking移到了我们的数据中心，而且现在它定期非常缓慢。
networking通过广泛的以太网连接。 ping服务器返回的时间less于1ms，tracert在1ms以内只显示1次。 从该位置提供的其他服务似乎不受影响（DC，Active Directory，Intranet等）
1 1 ms <1 ms <1 ms 192.168.XX.XX
除了位置以外，服务器没有任何其他变化，包括IP地址。
一个简单的Excel表格最多可能需要2分钟才能下载。 浏览共享也可能很慢。
有任何想法吗？
比简单的TCP延迟更多的东西可能会降低Windows服务器的性能。 如果你愿意，可以在一个客户端上使用Wireshark这样的嗅探器，这个客户端会遇到缓慢的Excel表单加载，并且看到它在线上的样子。 也许你会看到数据包之间的可疑超时，如数据包之间200毫秒的间隔。 然后比较类似的stream量和未受影响的非VMed机器，看看它应该是什么样子。
networking驱动程序设置 当你转移到HyperV，你不可避免地改变你的网卡驱动程序。 这里的设置可能会影响通信的方式，ping无法诊断或暴露。 像这样的东西最好暴露你正在做什么：从系统复制文件，创build连接，浏览共享。 即使从HyperV的一个点转移到另一个，驱动程序版本可能会稍有不同。
但是，数据包stream量应该更清楚地解决问题。
一些事情要检查：
确定MTU是否小于我们对普通以太网的预期。 从客户端工作站：
ping -f -l 1472
如果它返回“数据包需要分片但是DF设置”（或者“请求超时”），则从1472开始减less，直到确定最大有效载荷是什么。 MTU是最大有效载荷加28字节（ICMP报头8字节+ IP报头20字节，正常以太网MTU 1500）。
接下来，在Wireshark和MSnetworking监视器3.3中，可以添加“帧长度”列。 这将使您能够看到服务器是否正在发送超大的以太网帧。 为大于1514字节的数据包创build一个显示或捕获filter，但服务器确实不应发送大于MTU的数据包。
如果超大帧，则由客户机中的networking适配器属性“Large Send Offload”和“Jumbo Packets”确定。
已经有很好的build议值得研究。 我遇到的另一个常见问题是TCP烟囱卸载，尤其是使用Broadcom NIC。 尝试禁用它，并testing，看看是否会发挥作用。 http://support.microsoft.com/kb/951037