如何跟踪 SSIS 内存和 CPU 性能？

Question

我可能在这个谜题中遗漏了一些部分，但这是我所拥有的：

所有这些都是由一家外部公司为我们编写的。

有一个 .Net 应用程序作为服务器 A 上的服务运行。

在该应用程序中，正在调用 SSIS 包。DTEXEC?

这些包（总共 37 个）到达两个不同的 SQL Server (B&C)，提取一些数据，对其执行计算，然后将结果插入到服务器 C 上的数据库中。

在这 37 个包中，只有少数是我的问题所在。我已经看到了细节，其中有很多很多任务。

.Net 应用程序所在的服务器 A 上没有 SQL Server 组件（数据库引擎或 SSIS），因此这一切都在应用程序内部进行。.Net 使用 1 个 NUMA 节点的 20 个内核，盒子上有 1TB RAM。

此应用程序为 3.0 版本，增加了新功能。2.4（以前的版本）在相同的硬件上运行良好。

要问这个的所有背景：

有什么方法可以在 .Net 应用程序中的 SSIS 包中找到性能不佳的 T-SQL？还是我在等式中遗漏了一些非常明显的东西？
它归结为：“计算/T-SQL 实际运行在哪里”（A 与 B/C）以及如何在 .Net 空间内跟踪/调整它们？

Profilersp_whoisactive等都指向 SQL 实例。这一切都只发生在 .Net 应用程序中，除了从 B 中选择数据并在计算后插入到 C 中的小例外。所有网络、磁盘等都运行良好。我正在寻找一种可以访问 .Net SSIS 的调优工具（如果存在这样的东西）。

这绝对是一个调整问题，但 Profilersp_whoisactive等显示的时间可能不超过 3 秒，最远低于 1/2 秒或更短。我对 .Net 不太了解，不知道这些 T-SQL 任务是否真的像我认为的那样在该内存空间内的服务器 A 上运行，或者它们是否太多以至于它们都聚合成“太长了”。

我希望我被允许在 SSIS 中启用大量日志记录，但这是我不允许接触的供应商代码的一部分，即使是日志记录:(

Answer 1

这个问题所针对的环境早已被拆除并多次改变用途。

在当前的 UAT 迭代中，问题再次出现……我们发现有人将应用程序的一部分指向 Program Files(x86) 中的 dtexec.exe 的 32 位版本，而不是正确的 64 位版本。

哎呀。大量的研究和这篇 DBA.SE帖子让我到达了那里。

我的日志中第一次没有的消息：

Not enough Storage is available to complete this operation
A buffer failed while allocating x bytes
The attempt to add a row to the Data Flow task buffer failed

还有一些 SSIS 特定的 perfmon 计数器可以提供帮助：

我在这里详细说明了很多步骤： http://dallasdbas.com/ssis-memory-errors/

希望这对其他人有帮助！