几分钟后SSIS显着变慢是否有原因？答案

【问题标题】：Is there a reason why SSIS significantly slows down after a few minutes?几分钟后SSIS显着变慢是否有原因？
【发布时间】：2010-04-20 19:45:08
【问题描述】：

我正在针对 SQL 2008 运行一个相当大的 SSIS 包 - 我在我的开发环境（Win7-x64 + SQL-x64-Developer）和生产环境（Server 2008 x64 + SQL）中都得到了相同的结果标准 x64）。

症状是初始数据加载速度在每秒 50K 到 500K 记录之间尖叫，但几分钟后速度急剧下降，最终缓慢爬行，令人尴尬。数据库处于简单恢复模式，目标表为空，并且满足最小日志批量插入的所有先决条件。数据流是从 RAW 输入文件到模式匹配表的简单加载（即没有复杂的数据转换、没有排序、没有查找、没有 SCD 等）

这个问题具有以下特点和弹性：

无论目标表是什么，问题仍然存在。
RAM 使用率很低 (45%) - 有大量空闲 RAM 可供 SSIS 缓冲区或 SQL Server 使用。
Perfmon 显示缓冲区没有假脱机，磁盘响应时间正常，磁盘可用性很高。
CPU 使用率低（徘徊在 sqlserver.exe 和 DtsDebugHost.exe 之间共享的 25% 左右）
磁盘活动主要在 TempDB.mdf 上，但 I/O 非常低 (
OLE DB 目标和 SQL Server 目标都存在此问题。

总而言之，我希望磁盘、CPU 或 RAM 在程序包变慢之前耗尽，但它就像 SSIS 程序包正在午睡一样。 SQL Server 仍然响应其他查询，我找不到任何性能计数器或记录的事件表明问题的原因。

我将不胜感激地奖励任何合理的答案/建议。

【问题讨论】：

对以下任何人的一些反馈...我尝试了 Todd 的建议，即消除单个组件以隔离原因，但无济于事...似乎经过长时间运行的内存密集型操作，包“睡着了”——最近是在 RAW 文件阅读器上——确实需要很少的 CPU 或 RAM。当此数据流停止时，没有其他任务正在执行。
进一步反馈：在 SQL 目标上设置较小的提交大小肯定会提高整体性能，就像在数据流之前禁用所有非聚集索引一样。虽然系统仍然表现出内存泄漏的行为特征 - Visual Studio 变得无响应，并且 SQL Server + DtsDebugHost 使用的 RAM 在包停止后超过 6GB。
关于为什么我的程序包变慢的答案：mssqltips.com/tip.asp?tip=1840 底线：在非常大的传输中，需要禁用索引并且需要减小 MaxInsertCommitSize，否则 SQL Server 将破坏 TempDB 和事务日志。

标签： performance ssis

【解决方案1】：

我们终于找到了解决方案...问题在于我的客户使用的是 VMWare ESX，尽管 VM 报告有大量空闲 CPU 和 RAM，但 VMWare 专家必须预先分配（即保证） SSIS 来宾 VM 真正开始运行之前的 CPU。没有这个，SSIS 会运行，但 VMWare 会缩减资源——这是一个奇怪的怪癖，因为其他进程和软件让 VM 保持清醒。不知道为什么 SSIS 会有所不同，但正如我所说，VMWare 专家通过保留 RAM 和 CPU 解决了这个问题。

我还有一些其他反馈，其中列出了为了在 SSIS 中获得出色性能而要做的事情：

确保 SQL 登录有 BULK DATA 权限，否则数据加载会很慢。还要检查目标数据库是否使用简单或批量日志恢复模式。
避免对大数据的组件进行排序和合并 - 一旦它们开始交换到磁盘，性能就会下降。
源排序的输入数据（根据目标表的主键），并在目标表上禁用非聚集索引，设置MaximumInsertCommitSize为0 在目标组件上。这完全绕过了 TempDB 和日志。
如果您不能满足 3 的要求，则只需将 MaximumInsertCommitSize 设置为与数据流的 DefaultMaxBufferRows 属性相同的大小。

【讨论】：

【解决方案2】：

诊断 SSIS 数据流性能问题的最佳方法是分解。

第 1 步 - 衡量您当前的包裹性能。你需要一个基线。第 2 步 - 备份您的包，然后对其进行编辑。删除 Destination 并将其替换为 Row Count（或其他对流结束友好的转换）。再次运行包以测量性能。现在您知道了 Destination 导致的性能损失。第 3 步 - 再次编辑包，从数据流的底部移除下一个“向上”转换。运行和测量。现在您知道了该转换的性能损失。第 4 步...n - 冲洗并重复。

您可能不必一路爬上您的流程来了解您的限制因素是什么。当你找到它时，你可以问一个更有针对性的性能问题，比如“我的数据流中的 X 转换/目标很慢，这是它的配置方式，这是我的数据量和硬件，我有什么选择？”至少，您会确切地知道您的问题出在哪里，这会阻止很多野鹅追逐。

【讨论】：

感谢 Todd 的反馈 - 似乎是诊断导致问题的组件的一种非常务实和合乎逻辑的方法 - 但在这种情况下，我知道肯定它是目的地.. . 删除 OLE DB 或 SQL Server 目标，突然间世界变得很棒。将它们添加回来，几分钟后，这个过程就会变慢。
顺便说一句 - Todd，感谢您创建了非常出色的 Kimball SCD 组件！
Todd - 我看到您参与了一个 MSDN 博客，其中 Greg 在非常高端的 x64 机器上遇到了性能问题。他的问题描述听起来和我的一模一样，而且我们都在运行 x64 运行时。据您所知，x64 OLE DB 源/目标组件是否存在任何问题？
不是 AFAIK。我也运行 x64 - 尽管我认为负载很小。 SQLCAT 站点是一个很好的大负载习惯的好资源...

【解决方案3】：

您是否发出任何 COMMIT？当工作集变得太大时，我已经看到这种事情变慢了（可以肯定的是，这是一个相对的衡量标准）。定期 COMMIT 应该可以防止这种情况发生。

【讨论】：

将在此处发布反馈，让您知道这是否解决了问题。

【解决方案4】：

第一想法：

数据库文件是否在增长（没有对 MDF 进行即时文件初始化）？
上传是批处理/事务处理的吗？ AKA，这是一笔大交易吗？）

【讨论】：

MDF 文件是预先分配的，但目标是在一大批中提交。我会尝试打破它。