首先，我想确切地确定有问题的延迟是如何被识别的。它是运行缓慢的特定应用程序还是可以通过较长的传输时间或丢失而特别观察到的各种流量？

如果它特定于一种类型的应用程序流量并且它不是实际的应用程序（不幸的是一个非常常见的主题）那么我想了解缓慢的流量的性质并尝试看看我是否可以隔离它。是高带宽/大数据包导致了问题吗？很多小包？

最后，一些基本的隔离可能会有所启发 - 您能否在同一 vSwitch（即排除物理交换机）上的两台主机之间发送经历高延迟的相同类型的流量？在同一刀片交换机上的两个不同管理程序上的主机之间（不包括 Nexus 及其连接）？

还应排除其他常见原因 - 在任何物理接口上出现错误（在任一方向）、奇怪的 STP/L2 配置问题（不幸的是，在刀片交换机配置中非常常见）、告示错误消息、丢包计数器任何在线等。

延迟问题可能不够具体。您当然可以使用基本的ICMP 工具（如 ping 和 traceroute ）获得往返（毫秒）响应时间。但是，较差的应用程序性能/响应时间可能源于更高层的问题。如果网络通过 ICMP 看起来不错，请尝试查看您的应用程序日志和/或调试工具以寻找线索。

9k 的数据包捕获应该可以解决问题。您可以看到每个数据包何时进入和离开，这将告诉您延迟。我建议在“Virtual Server 1”进入的接口上使用一个，在“Virtual Server 2”进入的接口上推荐一个。这会让您很好地了解数据包在交换机中花费的时间。答案很可能是“基本上零时间”。

每个 IBM BladeCenter 交换机上的捕获也很好，连接到您的 VMWare 集群的接口。同样的想法，比较一个。它至少应该告诉你延迟在哪里。即，如果左侧交换机上的所有数据包进入和离开的时间间隔在 2-3 毫秒内，则该服务器不是问题。

最后，这就是我要开始的地方，在每个服务器上捕获可能是您最好和最简单的选择（其他人会不同意，但我发现从 Cisco 交换机捕获是费力的）。如果您的服务器收到一个数据包并且几秒钟没有响应，你猜怎么着？你已经找到你的问题了！