情况：
>我们在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到2毫秒的时间. 另一种可能性是虚拟机的实际cpu容量在某种程度上有所下降,但我希望这表现为增加的“明显”负载. 我们还有其他调查途径吗？
1)消除疑虑：
从DB到App服务器进行2次大文件夹传输,反过来大约500 MB. 1文件夹应包含500 MB大小的单个二进制文件.第二个文件夹应包含数千/数百万个文件,所有文件都在1KB或更少的文件中,并查看每种情况的网络性能.第一个将向您显示低数据包计数高有效负载流的模拟,第二个(将模拟数据库事务)将向您显示高数据包计数低有效负载流的模拟.这将让您了解他们在那里可以使用的网络环境以及您的网络问题是否属实.请记住,切换容量不仅仅是端口速度.到达10个数据包的10 MB / s与交换机上的负载(交换机cpu利用率)不同,10 MB / s到达100,000个数据包……交换机必须传输每个数据包,无论有效负载如何,您都可以获得网络饱和如果你没有足够的交换容量(每秒数据包),很容易.现在可能(99.9％)在数据中心不会出现这种情况,但在测试之前你永远不会确定
2)第二点应用配置：
我希望这是你的应用程序,你正确配置它,如果没有,大多数JDBC驱动程序都有批处理事务,有时如果没有在持久性提供程序中明确定义,可能会导致类似于您的体验(等待一定数量的应用程序)在执行查询之前实际提交事务或等待多个读取之前的写入操作.即使这样,这些批处理操作的超时大约为秒或2,然后它们提交事务,无论批处理队列是否已满
3)第三点云合同精细打印：
现在,由于这是一个云提供商,请检查细则.您所指的交易类型将涉及主机总线上的大量交易.大多数提供商现在限制每个虚拟机的总线利用率,但他们没有准确地宣传它(你会发现gt / s的限制).因此,当数据到达时,将其从网络接口通过总线传输到VM的RAM会产生巨大影响(请记住,您的VM在资源上不匹配,因此它们没有获得相同的份额,因此这么简单网络工作量不同).您受限的一个很好的指标是拥有1G连接,尝试在本地无负载地传输大型二进制连续文件,并且永远不会达到50~60 MB / s(450-480 Mbps)
无论如何希望有所帮助
