代码之家 › 专栏 › 技术社区 › Mark

SSIS在几分钟后显著减慢的原因是什么?

ssis performance

Mark · 技术社区 · 15 年前

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

其症状是,最初的数据加载速度在每秒50k-500k条记录之间尖叫,但几分钟后,速度急剧下降,最终缓慢爬行,令人难堪。数据库处于简单恢复模型中,目标表为空,并且满足最低日志大容量插入的所有先决条件。数据流是从原始输入文件到模式匹配表的简单加载(即没有复杂的数据转换、没有排序、没有查找、没有scd等)。

该问题具有以下性质和弹性:

无论目标表是什么,问题仍然存在。
RAM使用率较低(45%)—有足够的备用RAM可供SSIS缓冲区或SQL Server使用。
perfmon显示缓冲区没有假脱机,磁盘响应时间正常,磁盘可用性高。
CPU使用率低(在sqlserver.exe和dtsdebughost.exe之间的共享率徘徊在25%左右)
磁盘活动主要在tempdb.mdf上,但I/O非常低(<600 KB/s)
ole db destination和sql server destination都显示了这个问题。

总而言之,我希望磁盘、cpu或ram在包变慢之前耗尽,而不是ssis包午睡。SQL Server仍然对其他查询作出响应,并且我找不到任何性能计数器或记录的事件,这些事件表明了问题的原因。

如有合理的回答/建议,我将不胜感激。

4 回复 | 直到 14 年前

Mark 14 年前

我们终于找到了解决办法…问题在于我的客户机使用的是vmware esx,尽管vm报告了大量的空闲cpu和ram,但vmware专家必须在ssis guest vm真正开始运行之前预先分配(即gaurantee)cpu。如果没有这一点,ssis将运行,但vmware将缩减资源,这是一个奇怪的怪癖,因为其他进程和软件使vm保持愉快的清醒状态。不知道ssis为什么不同,但正如我所说,vmware专家通过保留ram和cpu解决了这个问题。

我还有一些其他的反馈,作为在SSIS中取得优异性能的工作清单:

确保SQL登录具有大容量数据权限 ,否则数据加载将非常缓慢。还要检查目标数据库是否使用简单或大容量日志记录恢复模型。
避免对大数据上的组件进行排序和合并—一旦它们开始交换到磁盘上,性能就会下降。
来源 已排序的输入数据 (根据目标表的主键),以及 禁用非聚集索引 在目标表上,设置 最大用户提交大小为0 在目标组件上。这将完全绕过tempdb和log。
如果不能满足3的要求,只需将maximunisertcommitsize设置为与数据流的defaultmaxbufferrows属性相同的大小。

Todd McDermid 15 年前

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

步骤1-测量当前包的性能。你需要一个基线。第二步-备份你的包,然后编辑它。移除目标并用行计数(或流友好转换的另一端)替换它。再次运行包以测量性能。现在您知道了您的目的地所造成的性能损失。第3步-再次编辑包,删除数据流底部的下一个“向上”转换。跑步和测量。现在您知道了该转换的性能损失。步骤4…n-冲洗并重复。

你可能不必一路爬到你的流量上去,就能知道你的限制因素是什么。当您找到它时,您可以问一个更有针对性的性能问题,比如“数据流中的x转换/目标很慢,这是如何配置的,这是我的数据卷和硬件,我有哪些选项?”至少,你会知道你的问题在哪里,这会阻止很多雁行追逐。

DaveE 15 年前

你有什么承诺吗?当工作集变得太大(可以肯定的是,这是一个相对的度量)时,我看到这种事情会变慢。定期提交应该避免这种情况发生。

gbn 15 年前

第一个想法:

数据库文件是否在增长(没有针对mdfs的即时文件初始化)?
上传是否成批/交易?aka,这是一笔大交易吗?)