SSIS在几分钟后显着减速是否有原因？

Question

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

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

问题具有以下品质和弹性：

1. 无论目标表是什么，问题都会持续存在。
2. RAM使用率低（45％） - 有足够的备用RAM供SSIS缓冲区或SQL Server使用。
3. Perfmon显示缓冲区没有假脱机，磁盘响应时间正常，磁盘可用性很高。
4. CPU使用率低（在sqlserver.exe和DtsDebugHost.exe之间共享徘徊约25％）
5. 磁盘活动主要在TempDB.mdf上，但I / O非常低（<600 Kb / s）
6. OLE DB目标和SQL Server目标都出现此问题。

总而言之，我希望在软件包减速之前，磁盘，CPU或RAM都会耗尽，而不是像SSIS软件包正在午睡。 SQL服务器仍然响应其他查询，我找不到任何背叛问题原因的性能计数器或记录事件。

我会非常感激地回答任何合理的答案/建议。

Answer 1

我们终于找到了一个解决方案......问题在于我的客户端正在使用VMWare ESX，尽管VM报告了大量的免费CPU和RAM，但VMWare大师必须预先分配（即gaurantee） SSIS来宾虚拟机真正开始飞行之前的CPU。如果没有这个，SSIS将会运行，但VMWare会缩减资源 - 这是一个奇怪的怪癖，因为其他进程和软件使VM保持清醒状态。不确定为什么SSIS不同，但正如我所说，VMWare大师通过保留RAM和CPU来解决这个问题。

我还有一些其他的反馈意见，通过一份清单来确定SSIS中的出色表现：

1. 确保SQL登录具有BULK DATA权限，否则数据加载将非常慢。还要检查目标数据库是使用Simple或Bulk Logged恢复模型。
2. 避免对大数据上的组件进行排序和合并 - 一旦他们开始将性能排水沟交换到磁盘上。
3. 源已排序的输入数据（根据目标表的主键）和禁用目标表上的非聚集索引，将 MaximumInsertCommitSize设置为0 在目标组件上。这会绕过TempDB并完全记录日志。
4. 如果您无法满足3的要求，则只需将MaximumInsertCommitSize设置为与数据流的DefaultMaxBufferRows属性相同的大小。

Answer 2

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

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

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

Answer 3

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

Answer 4

初步想法：

• 数据库文件是否在增长（没有MDF的即时文件初始化）？
• 上传批量/转播？ AKA，这是一笔大交易吗？）