Ale*_*son 4 windows-server-2008 performance sql-server vmware-esxi
我们正在尝试从 VM 内部诊断显然运行缓慢的 VM。
情况:
数据库报告在等待异步网络 IO 上花费了大量时间,即。等待应用程序消费数据。应用程序 VM 显然也是轻载的:~20% CPU。基础设施不归我们所有,我们唯一的访问权限是通过 RDP 访问虚拟机,以及通过 SQL Management Studio 访问数据库集群。我们没有足够的权限来运行分析器,但我们确实记录了数据库和 VM 的性能计数器。
几周前,消息处理率突然下降了 70-80%。据我们所知,没有任何变化:应用程序没有被修改或重新配置,性能计数器没有指示负载特性的任何变化。基础设施的所有者表示,他们最终没有任何改变。
作为重新启动过程的一部分,应用程序必须重新加载其消息队列。这涉及对几十万行的简单选择,然后将这些行读入内存结构。数据库在几秒钟内为 SELECT 提供服务,但随后在读取结果集的应用程序上等待了大约 10 分钟。这是一个单线程操作,涉及非常简单的反序列化,在此硬件上花费的时间不应超过几分钟。
我目前的理论是网络延迟在某种程度上增加了,但 ping 只报告“<1ms”,而且我们在任何情况下都没有基线。hrPing 报告从应用程序服务器到数据库的时间在 0.5 到 2 毫秒之间。
另一种可能性是 VM 的实际 CPU 容量以某种方式减少了,但我预计这会表现为“明显”负载的增加。
我们还有其他调查途径吗?
我不是专家,但这是我的 2 美分:
1)消除疑虑:
将 2 个大文件夹从数据库传输到应用服务器,反之则传输大约 500 MB。1 文件夹应包含一个大小为 500 MB 的二进制文件。第二个文件夹应该包含数千/数百万个文件,所有文件都在 1KB 或更少,并查看每种情况的网络性能。第一个将向您展示低数据包计数高负载流的模拟,第二个(将模拟 DB 事务)将向您展示高数据包计数低负载流的模拟。这将使您了解他们在那里可用的网络环境类型以及您的网络问题是否属实。请记住,交换容量不仅仅是端口速度。10 个数据包中的 10 MB/s 与交换机上的负载(交换机 CPU 利用率)与 100,000 个数据包中的 10 MB/s 的负载不同...... 无论有效负载如何,交换机都必须传输每个数据包,如果您没有足够的交换容量(每秒数据包),您很容易达到网络饱和状态。现在这可能 (99.9%) 在数据中心不会是这种情况,但你永远不会知道,直到你测试
2) 第二点应用配置:
我希望这是您的应用程序并且您正确配置了它,如果不是,大多数 JDBC 驱动程序都有批处理事务,有时如果没有在您的持久性提供程序中明确定义,可能会导致类似于您所经历的行为(应用程序等待一定数量在实际提交事务之前写入的次数或在执行查询之前等待多次读取)。即便如此,这些批处理操作也有大约 1 秒或 2 秒的超时,然后无论批处理队列是否已满,它们都会提交事务
3) 第三点云合同细则:
现在,由于这是一个云提供商,请检查细则。您所指的事务类型将涉及主机总线上的大量事务。大多数提供商现在限制每个 VM 的总线利用率,但他们并没有完全公布它(您会发现 gt/s 的限制)。因此,当数据到达时,将其从网络接口通过总线传输到 VM RAM 会产生巨大影响(请记住,您的 VM 在资源上不匹配,因此它们不会获得相同的份额,因此非常简单)网络工作负载各不相同)。您受到限制的一个很好的指标是拥有 1G 连接,尝试在没有负载的情况下在本地传输大型二进制连续文件,并且从未达到 50~60 MB/s (450-480 Mbps)
无论如何希望有帮助
| 归档时间: |
|
| 查看次数: |
962 次 |
| 最近记录: |