VM中的SQL脚本需要很长时间才能执行答案

【问题标题】：SQL Script in VM taking long time for executionVM中的SQL脚本需要很长时间才能执行
【发布时间】：2012-02-15 08:50:53
【问题描述】：

我有一个执行 SQL 脚本包，其中包含插入大约 15 万条记录的脚本。

这里的问题是当我在虚拟机中执行包时大约需要 25 分钟，而在物理机中执行相同的包需要 2 分钟

问题 1？为什么要花那么多时间在 VM 中加载相同的数据。问题2？如何解决这个性能问题。

物理机配置有 4GB Ram 和 250GB HD + Windows server 2008 R2 + SQL server 2008 R2 Standard Edition。虚拟机具有相同的配置

更新：问题出在 VM 中的 SQL Server。

问题 1？为什么要花这么多时间在 VM 中运行相同的脚本。

问题 2？如何解决这个性能问题。

物理机和虚拟机中的数据库架构是相同的。其他数据库也一样。两台机器上都没有为该表应用索引。数据类型相同。我所说的硬盘具有相同的配置。

两台机器上都没有做 RAID。

物理机具有 2.67GHz RAM 四核，而虚拟机具有 2.00GHz RAM 四核

SQL PM 版本：

我执行的脚本两者的执行计划是一样的，计划没有区别。

供应商是 HP ML350 机器。

在同一物理服务器上几乎有 20 台虚拟机，其中有 7 台服务器处于活动状态。

【问题讨论】：

这是唯一包所做的事情——一个执行sql任务吗？数据库结构是否相同？在两者之间运行模式比较。两者之间的数据量如何比较。楼主长啥样？两个系统上的磁盘 io 子系统是什么样的？大小无关紧要，iops 为王
另外，检查慢速系统上的统计信息、碎片等。也许它严重分散。关于 SSIS 在 VM 上执行缓慢还是 VM 访问磁盘的快速测试（假设程序包仅执行执行 SQL 任务）是在 SSMS/sqlcmd/SQL Agent/.NET 中运行该任务并查看是否时间是可比的。
我在 SQL Server 中执行了相同的 SQL 脚本，花费了相同的时间。现在的问题是 SQL 脚本在 VM 中需要时间。可能是什么原因。
就像 billinkc 说的，物理机器上的数据库和虚拟机是一样的吗？它们是否具有相同的结构、相同的数据类型和相同的索引？两台机器的硬盘是一样的吗？一个或另一个是否有 RAID 或 SSD？
物理服务器上正在运行多少其他虚拟机？可能有太多虚拟机在争夺 CPU 周期或网络带宽。

标签： sql sql-server performance sql-server-2008 ssis

【解决方案1】：

这里有一篇关于为 VM 实现正确设置 SQL 配置的文章：Best Practices for SQL Server。下面是一段摘录，尽管文章包括其他技巧和良好的性能测试计划：

存储配置问题是 SQL 性能问题的第一大原因。通常出现这些问题是因为 DBA 请求 VI 管理员的虚拟磁盘，VI 管理员将 VMDK 放置在可能满足或不满足 DBA 性能需求的 LUN 上。例如：

VM 的 VMDK 文件放置在没有足够主轴的 VMFS 卷上。

许多 VMDK 文件放置在单个 VMFS 卷上，可以使用更多的心轴。

数据库和日志文件放在同一个 LUN 上，您猜对了，它可以使用更多的心轴。

这对某些人来说可能很明显，但这个问题会一次又一次地发生。 VI 管理员应该了解一些有助于理解和避免此问题的技术项目：

根据DB文件的IO需求，有一定数量的主轴应保证此文件。这意味着它的 VMDK 必须放置在 VMFS 卷上以适应 SQL Server 的要求以及该卷上的所有其他要求。

混合顺序活动（如日志文件更新）和随机活动（例如数据库访问）会导致随机行为。这表示预虚拟物理环境中的 LUN 配置对于合并的环境可能还不够。这是在存储性能：VMFS 和协议中讨论了一些内容。

当存储不能满足 SQL Server 的需求时，设备延迟或内核延迟（排队时间）会增加。阅读这些存储性能分析和监控中的计数器。

【讨论】：

看起来很复杂。你能告诉我关于存储配置的具体操作吗？解决此问题的步骤。
虚拟机上 sql 的主要问题之一是 i/o：如果有 10 个虚拟机需要读取/写入同一个磁盘，您的 i/o 速度将降低 10 倍 - 100 倍因为每个人都在争夺驱动头的注意力。如果您可以将整个磁盘驱动器专用于您的 sql vm，您会看到显着的性能提升。此外，不要允许所有 vm 访问所有内核：这也会因资源争用而减慢速度。相反，将虚拟核心专用于每个虚拟机。与内存相同 - 一个虚拟机可以从另一个虚拟机窃取它。

【解决方案2】：

此问题的最常见原因是缺少 RAM。在小型 4GB RAM 机器上进行所有设置是您的问题。

当您尝试将这 150k 行加载到内存中时（请记住，SSIS 中发生的所有事情都在内存中），其中很多行正在由您的页面文件处理。

VM 上的页面文件比物理机上的要慢很多。

要解决此问题，请增加虚拟机上的 RAM 量。

【讨论】：

我已将 VM 大小增加到 8GB。当我运行这个任务时，我检查了任务管理器的资源管理器。那里仍然有大约 2+GB 的免费空间可供任何使用。我认为这不是解决方案。
另一个原因可能是 VM 主机（底层机器）正忙。它并不总是反映在虚拟机中...
我注意到物理机具有 2.67 GHz RAM，而虚拟机具有 2.00 GHz RAM。这可能是原因，但我不确定。我重新启动了机器，以便重新启动所有服务并重新启动内存。那台机器上没有其他任务正在运行。
无论您如何配置，VM 都将始终是您物理机的子集，无法超越它。我需要更多关于你的信息来帮助你。首先为我们提供 SQL 脚本。谢谢！

【解决方案3】：

我也有类似的问题。

两台客户端机器（一台物理机，一台虚拟机）使用 SQLCMD 执行批处理。此批处理调用物理服务器上的存储过程（因此它不是内存问题，因为详细说明仅在服务器端）。

从物理机执行的批处理需要 20 分钟。从虚拟机执行批处理需要 1 小时 20 分钟。

使用 SQL 分析器，我注意到在执行缓慢的情况下，存在等待类型 ASYNC_NETWORK_IO。

可能是虚拟化网络层没有优化。

您能否运行 SQL 分析器并检查您是否看到等待类型 ASYNC_NETWORK_IO？

【讨论】：

我用 SQL Profiler 查过了，但是没有 ASYNC_NETWORK_IO 等。即使 ASYNC_NETWORK_IO 是问题所在。解决方案是什么。