我们试图从VM内部诊断虚拟机显然运行缓慢。
情况：
数据库报告等待asynchronousnetworkingIO的时间相当长， 等待应用程序使用数据。 应用程序虚拟机显然也是轻载：〜20％的CPU。 基础架构不属于我们，我们唯一的访问权限是通过RDP到虚拟机，SQL Management Studio到数据库集群。 我们没有足够的权限来运行探查器，尽pipe我们logging了数据库和虚拟机的性能计数器。
几个星期前，邮件处理速度突然下降了70-80％。 据我们所知，没有任何改变：应用程序没有被修改或重新configuration，并且性能计数器没有指示负载特性的任何改变。 基础设施的所有者已经表示，最终没有任何变化。
作为重新启动过程的一部分，应用程序已重新加载其消息队列。 这涉及到几十万行的一个简单SELECT，然后将其读入内存中的结构。 数据库在几秒内为SELECT提供服务，然后在读取结果集的应用程序上等待约10分钟。 这是一个涉及非常简单的反序列化的单线程操作，在这个硬件上不应该花费几分钟的时间。
我目前的理论是，networking延迟在某种程度上有所增加，但ping只报告“<1ms”，我们没有任何一个基准。 hrPing报告从应用程序服务器到数据库的时间在0.5到2ms之间。
另一种可能是虚拟机的实际CPU容量已经有所下降，但是我预计这会performance为“明显”负载的增加。
还有其他途径可以调查吗？
我不是什么专家，但这里是我的2美分：
1）消除疑虑：
从数据库到应用程序服务器进行2大文件夹传输，反过来大约500 MB。 1文件夹应包含500 MB大小的单个二进制文件。 第二个文件夹应该包含数千/数百万个文件，全部在1KB或更less，并查看每个案例的networking性能。 第一个将显示一个低数据包数高负载stream的模拟，第二个（它将模拟数据库事务）将向您显示高数据包数低负载stream的模拟。 这会给你一个什么样的networking环境，他们可以在那里，如果你的networking问题是真实的想法。 请记住，交换容量不仅是端口速度。 到达10个数据包的10 MB / s与10 MB / s到达10 000个数据包的开关（开关CPU利用率）不是相同的负载…交换机必须传输每个单独的数据包，而不考虑有效负载，并且可以获得networking饱和如果你没有足够的交换容量（每秒数据包），很容易。 现在可能（99.9％）在数据中心不会如此，但是在testing之前，您绝对不会知道
2）第二点应用configuration：
我希望这是您的应用程序，如果没有正确configuration，大多数JDBC驱动程序都具有批处理事务，有时候，如果您的持久性提供程序没有明确定义，可能会导致类似于您所遇到的行为（应用程序正在等待一定的数量在实际提交事务或在执行查询之前等待多次读取之前的写入）。 即使这样，这些批处理操作的超时时间是一秒或2秒，然后他们提交交易，无论批处理队列是否满
3）第三点云合同细印：
现在，因为这是一个云提供商，请检查细节。 您所指的交易种类将涉及主机总线上的大量交易。 大多数提供商现在限制了每个虚拟机的总线利用率，但是他们没有准确的宣传它（你会发现对gt / s的限制）。 因此，当数据到达时，将其从networking接口通过总线传输到虚拟机内存有巨大的影响（请记住，您的虚拟机在资源上不匹配，因此它们不能获得相同的份额，networking工作量变化）。 一个很好的指标是你有一个1G的连接，试图在空载的情况下本地传输一个大的二进制连续文件，从来没有达到50〜60MB / s（450-480Mbps）
无论如何希望有所帮助
感谢所有的build议！ 这个情况最终得到了解决，虽然我们还没有被告知是虚拟主机还是networking的行为不端，也不知道是怎么解决的。
在排除故障的过程中，我们编写了一个简单的应用程序来分析某些数据库操作，并试图找出平台不正常的确切方式：
https://github.com/BluewireTechnologies/db-latency
基本上，数据库的statistics time声称已经过去了0ms，偶尔SQL客户端确信它花了几百毫秒等待ExecuteReader（）返回，指向一个networking问题，或者可能是一个缺乏时间片的虚拟机。 这些高峰会折磨大约5％的数据库往返，并给予通常即时操作很可能需要几秒钟才能完成。
客户的技术人员之一自己编译和使用该工具。 他证实了我们的发现并将其转发给了相应的团队，几个小时后问题解决了。
事实上，正如大家所怀疑的那样，这似乎确实是一个networking问题！