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

Question

我正在运行一个针对SQL 2008的相当大的SSIS包 - 我在开发环境(Win7-x64 + SQL-x64-Developer)和生产环境(Server 2008 x64 + SQL Std 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专家必须预先分配(即保证)CPU用于SSIS来宾VM真正开始飞行之前.如果没有这个,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转换/目标很慢,这是它的配置方式,这是我的数据量和硬件,我有什么选择？" 至少,你会确切地知道你的问题在哪里,这会阻止很多疯狂的追逐.