我们正在尝试从虚拟机内部诊断运行缓慢的虚拟机。
情况：
- 我们在 Windows Server 2008R2 上有一个 IIS 托管的应用程序，该应用程序运行在 6 核、12GB 的虚拟机上。
- 我们有一个在 SQL Server 2008R2 SP3 集群（16+ 核，>16GB RAM）上运行的数据库
- 应用程序正在处理针对此数据库的消息队列。处理主要包括查询/获取和更新，每条消息可能有十几次往返。为该工作负载分配了有限数量的线程 (3)，这些线程是同步的，因此线程会阻塞数据库响应。
- 数据库负载显然很轻：仅为最大 CPU 负载的百分之几。
- 据我们所知，数据库和 VM 主机都位于同一个数据中心。
数据库报告称，等待异步网络 IO（即等待应用程序使用数据）花费了相当长的时间。应用程序 VM 的负载也很轻：大约 20% 的 CPU。该基础设施不属于我们，我们只能通过 RDP 访问虚拟机，通过 SQL Management Studio 访问数据库集群。我们没有足够的权限来运行分析器，但我们确实记录了数据库和 VM 的性能计数器。
几周前，消息处理率突然下降了 70-80%。据我们所知，什么都没有改变：应用程序没有被修改或重新配置，性能计数器也没有显示负载特性有任何变化。基础设施的所有者表示，他们这边什么都没有改变。
作为重启过程的一部分，应用程序被要求重新加载其消息队列。这涉及一个简单的 SELECT，其中包含几十万行，然后将其读入内存结构。数据库在几秒钟内处理了 SELECT，但随后等待应用程序读取结果集约 10 分钟。这是一个涉及非常简单的反序列化的单线程操作，在此硬件上不应花费超过几分钟的时间。
我目前的理论是网络延迟在某种程度上增加了，但 ping 只报告“<1ms”，而且我们在任何情况下都没有基线。hrPing 报告从应用程序服务器到数据库的时间在 0.5 到 2ms 之间。
另一种可能性是虚拟机的实际 CPU 容量在某种程度上有所下降，但我预计这会表现为“明显”负载的增加。
我们还有其他调查途径吗？
答案1
我并不是专家，但以下是我的看法：
1）消除疑虑：
将 2 个大文件夹从数据库传输到应用服务器，反之亦然，大约 500 MB。1 个文件夹应包含一个 500 MB 大小的二进制文件。第二个文件夹应包含数千/数百万个文件，大小均为 1KB 或更小，并查看每种情况下的网络性能。第一个文件夹将显示低数据包数高有效负载流的模拟，第二个文件夹（将模拟数据库事务）将显示高数据包数低有效负载流的模拟。这将让您了解他们那边有什么样的网络环境，以及您的网络担忧是否属实。请记住，交换容量不仅仅是端口速度。10 MB/s 到达的 10 个数据包对交换机的负载（交换机 CPU 利用率）与 10 MB/s 到达的 100,000 个数据包对交换机的负载不同...交换机必须传输每一个数据包，而不管有效负载如何，如果交换容量（每秒数据包数）不足，网络很容易饱和。现在，这种情况在数据中心可能（99.9%）不会发生，但在测试之前你永远无法确定。
2）第二点应用程序配置：
我希望这是您的应用程序，并且您已正确配置它，如果不是，大多数 JDBC 驱动程序都有批处理事务，有时如果持久性提供程序中未明确定义，则会导致类似于您所经历的行为（应用程序在实际提交事务之前等待一定数量的写入，或在执行查询之前等待一定数量的读取）。即便如此，这些批处理操作也有超时时间，大约为 1 秒或 2 秒，然后它们会提交事务，无论批处理队列是否已满
3）第三点云合同细则：
现在，由于这是一家云提供商，请检查细则。您所指的交易类型将涉及主机总线上的大量交易。大多数提供商现在限制每个虚拟机的总线利用率，但他们并没有明确宣传这一点（您会发现 gt/s 的限制）。因此，当数据到达时，将其从网络接口通过总线传输到虚拟机 RAM 会产生巨大影响（请记住，您的虚拟机在资源上不匹配，因此它们不会获得相同的份额，因此简单的网络工作负载会有所不同）。一个很好的指标表明您受到限制，即拥有 1G 连接，尝试在本地无负载传输大型二进制连续文件，并且从未达到 50~60 MB/s（450-480 Mbps）
无论如何希望有所帮助
答案2
感谢大家的建议！问题最终得到了解决，尽管我们不知道是 VM 主机还是网络出现了问题，也不知道具体是怎么解决的。
在故障排除的过程中，我们编写了一个简单的应用程序来分析某些数据库操作，并尝试找出平台不正常的确切原因：
https://github.com/BluewireTechnologies/db-latency
基本上，数据库statistics time声称耗时 0 毫秒，而有时 SQL 客户端相当确定它花了几百毫秒等待 ExecuteReader() 返回，这表明存在网络问题，或者可能是 VM 缺少时间片。这些峰值会影响大约 5% 的数据库往返，并使通常即时的操作很可能需要数秒才能完成。
客户的一名技术人员亲自编译并使用了该工具。他确认了我们的发现并将其转发给相关团队，几个小时后问题就得到了解决。
正如大家所怀疑的那样，这确实很可能是网络问题！