标签: parallelism

我有一个应用程序必须从表中删除和插入注册表，该表存储访问控制的历史注册表，并与系统中的检查日期时间一起存储。

现在就是这个问题。我有一个线程池，其中每个线程在一段时间内（通常是一个月）工作超过一天。当这个过程开始时，它给了我一些死锁。我做了一个锁跟踪，在死锁图中只说一个进程被阻塞，但没有说哪个句子或事务发生了，在死锁日志中它说Parallel query worker thread was involved in a deadlock. 如何进行更详细的跟踪或查询以了解是什么导致了我的应用程序和数据库阻塞？

谢谢

编辑

这是我在过去几天中所做的跟踪的 XML：

<deadlock victim="process45f9fb048">
  <process-list>
   <process id="process45f9fb048" taskpriority="0" logused="0" waitresource="PAGE: 4:1:98644" waittime="5369" ownerId="1282041063" transactionname="DELETE" lasttranstarted="2014-06-27T03:15:01.157" XDES="0xbeb91620" lockMode="U" schedulerid="7" kpid="1984" status="suspended" spid="204" sbid="0" ecid="4" priority="0" trancount="0" lastbatchstarted="2014-06-27T03:15:00.620" lastbatchcompleted="2014-06-27T03:15:00.620" clientapp="SQLAgent - TSQL JobStep (Job 0xF408BE64B781AB40B05180C1B2EB9DC8 : Step 1)" hostname="REPORTESCRYSTAL" hostpid="28848" isolationlevel="read committed (2)" xactid="1282041063" currentdb="4" lockTimeout="4294967295" clientoption1="673185824" clientoption2="128056">
    <executionStack>
     <frame procname="msdb.dbo.sp_syscollector_purge_collection_logs" line="31" stmtstart="2152" stmtend="2720" sqlhandle="0x03000400af551732fc7ab30044a000000100000000000000">
DELETE FROM dbo.sysssislog
        FROM dbo.sysssislog AS s
        INNER JOIN dbo.syscollector_execution_log_internal AS l …

我正在运行一个 ETL 过程，该过程将大约 200 万行写入 SQL Server 数据库。

我正在尝试优化纯插入所需的时间（我猜更新是另一回事）。

我想知道将基本插入到 SQL 数据库的最大瓶颈是什么，或者是减少时间的最佳方法。

我的意思是，第一件事可能是数据的大小，对吗？行数、列数和每列中的数据大小。其中一些可能无法最小化，每行的 KB/ 占用空间是可以潜在优化的一件事，对吧？

还有什么可以优化或者是最大的因素？它是传输介质吗？我的意思是，写入同一台计算机上的数据库与通过 Web 连接写入（即强大、快速且 ping 为 1 毫秒？）之间有多大差异。

最后 --- 为什么与数据库的多个并行连接似乎将进程加速到某个点？我的意思是，当我有 20 个连接进行循环插入时，它比一个连接写入所有数据快 6-7 倍。我很好奇这是为什么。

现在我有 220 万行，总计 2.7 GB。这是每行 1.23 kb。

现在使用 14 个连接一次插入 1000 行 (1.23 MB) 需要 6.7 秒。这是蜗牛般的每秒 10.66 行。即使假设 1 个连接也一样快（它不是），最多为 150 行/秒，这也不是完全“快”。我正在写一个超快速、强大的网络连接 b/c，我们不能在与数据仓库相同的空间上进行 ETL 过程。

那么..如何优化这里的速度？

一次 1000 行的原因是因为数据来自 1000 页 - 但优化解析现在是一个单独的问题。

我相信我确实有一个主要索引，但没有什么写起来太昂贵。现在我只是在做蒙特卡罗之类的测试（尝试一下，看看什么是有效的），但我需要更专注的东西。

第一个查询（插入表变量）的时间是第二个查询的两倍。它在执行计划中不使用并行性。

第二个查询（插入临时表）在其执行计划中使用并行性，并且能够在几乎一半的时间内实现结果。

我试图从表函数运行它，因此需要表变量而不是临时表。

执行计划非常复杂，我宁愿不朝那个方向深入（目前）。我想知道是否有人解释或假设为什么第一个 SQL 不使用并行性，而第二个是。

第一的：

DECLARE @TableVar as TABLE (
    [Date] [date] NULL,
    [B] [int] NULL,
    [C] [decimal](5, 3) NULL)

INSERT INTO 
    @TableVar
SELECT 
    [Date]        = CAST(LO.Dt as Date)
  , [B]           = DMC.[B]
  , [C]           = DMC.[C]
FROM                  
                 dbo.fnTblFunc1(@DateStart, @DateEnd) AS DMC 
    INNER JOIN   dbo.fnTblFunc2(@DateStart, @DateEnd) AS LO ON DMC.Date = LO.Dt
OPTION (FORCE ORDER  )

第二：

CREATE TABLE #TempTbl(
    [Date] [date] NULL,
    [B] [int] NULL,
    [C] [decimal](5, 3) NULL)

INSERT INTO 
    #TempTbl
SELECT 
    [Date]        = CAST(LO.Dt …

我们有一个主分析 SP，它调用 100 个其他子 SP，所有这些都对同一组数据（声明）进行操作，检查其是否存在某些业务规则和输出差异。

SP 不需要全部按顺序运行，它们可以分成多个部分，这些部分依赖于前面的部分（顺序），但在该部分内独立（并行）。

在查看了许多选项（例如 Service Broker、Agent Jobs、Batch Files、SSIS 等）后，我使用此CLR 代码来并行化各个部分，并极大地提高了性能。

但是，当我同时运行多个 (5, 10, 15) 个主 SP（每个 SP 分析不同的声明）时，性能会随着并发性的增加而逐渐下降。我猜这是因为通过 CLR 创建多个并行线程的开销。我还看到 sp_who2 中有很多 XTP_THREAD_POOL 会话空闲。

有没有人使用 CLR 在关键 OLTP 生产工作负载中并行化存储过程？
是否有任何性能优化 SQL CLR 的最佳实践？
在开销使事情变得更糟之前，是否有可以打开的并行线程数量的阈值？
如果我的系统有 20 个内核，是否意味着创建 > 20 个并行线程没有帮助？

CXCONSUMER当我运行时，我有一些等待时间的查询，sp_whoisactive如下面的屏幕截图所示。

当我检查状态时，它是suspended。这意味着它正在等待某个进程释放资源。据我所知CXPACKET，生产者CXCONSUMER是消费者，而 CXPACKET 是罪魁祸首，应该对此采取行动。但我不”没有看到任何CXPACKET。由于这是一个并行执行，我不确定应该从哪里开始修复。

任何人都可以建议我如何找出我的查询正在等待的过程（因为我将挂起视为状态）？

附加信息

当我查询时sys.dm_os_wait_stats，前两个条目是 CONSUMER 和 CXPACKETS。

• SQL Server 2016
• 128 GB 内存
• 最大 DOP : 8
• 门槛成本：20

我有一个查询，它与 8 的 MAXDOP 并行运行。当我查看时，sp_who2我看到相同的会话 ID 使用不同的连接 ID 重复多次（> 8）。

我使用了下面的查询，看到等待类型仍然是 CXCONSUMER 等待类型。但我看到 130 个不同的 exec_context id。

SELECT 
    dot.session_id,
    dot.exec_context_id,
    dot.task_state,
    dowt.wait_type,
    dowt.wait_duration_ms,
    dowt.blocking_session_id,
    dowt.resource_description
FROM sys.dm_os_tasks dot
    LEFT JOIN sys.dm_os_waiting_tasks dowt
        ON  dowt.exec_context_id = dot.exec_context_id
            AND dowt.session_id = dot.session_id
WHERE dot.session_id = 96
ORDER BY exec_context_id;

如果查询并行运行，当我将负载分配到不同的工作线程时，它是否具有不同的 spid。？

看了肯德拉·利特尔 (Kendra Little) 的文章。非常有帮助的一个。

我使用查询来查看并行处理查询中使用的不同调度程序。

我看到多次使用相同的shcheduler_id/worker地址。这正常吗？

我的 MAXDOP 也是 4，但我看到 5 个不同的 scheduler_ids，这很奇怪。

我在测试 SQL Server 2014 上安装了 AdventureWorks2014 数据库。我计划执行以下查询：

SELECT *
FROM Sales.SalesOrderDetail sod
INNER JOIN Production.Product p ON sod.ProductID = p.ProductID
ORDER BY Style

在实际执行之前，我有我的工作线程的以下图片：

在查询执行时，我再次检查了工作线程的状态：

如您所见，第二张图片中的 active_workers_count 总数高于第一张屏幕截图中的总数。从第二个屏幕截图中，我可以假设查询执行所需的总工作线程为 1+2+1+2=6。但是，当我查看执行计划中索引扫描运算符的属性时，我看到：

似乎我的并行度为 4，这意味着 4 个线程正在并行处理行。

我很困惑，无法确定在查询执行期间运行了多少线程。有人可以向我解释为什么 active_workers_count 与 DOP 不同吗？

我使用 SQL Server 2008R2 标准版实例（最近迁移到 Azure VM）的数百个数据库的 SharePoint 数据存储定期遇到 THREADPOOL 等待问题。它一次在许多（可能是所有）这些数据库中运行一个名为 proc_DefragmentIndices 的存储过程。

存储过程无条件地重建数据库中的每个索引。当然，它们是头部阻塞器（因为它是标准版，每个 ALTER INDEX 命令都以 ONLINE=OFF 运行）。因为一次运行的程序太多（每个都在不同的数据库中），并且它们并行运行（这会占用更多的工作人员），所以一切都堆积如山。只是为了增加噪音，Azure Backup 正在备份许多数据库，而这一切都在进行，消耗了更多的工作人员。活动监视器显示 106 个等待任务，以及许多 ALTER INDEX 命令的同一会话 ID 的多个实例（这就是我说它们并行的原因）。

我觉得令人困惑的是，即使实例中的 MAXDOP 设置为 1，这些 ALTER INDEX 语句也会并行运行，这是对 SharePoint 数据库的建议，并且由存储过程执行的 ALTER INDEX 语句没有使用 MAXDOP 选项来覆盖它.

Q1：当 MAXDOP 设置为 1 时，INDEX 重建如何并行？

Q2：活动监视器显示 ALTER INDEX 命令，但 sp_WhoIsActive 没有。有谁知道为什么？

这是一个非常笼统的问题，所以我不提供太多具体信息。我对并行性及其可能的缺点更感兴趣。一般来说，我完全支持并行性，因为它是有用和积极的。

我似乎遇到越来越多的系统，这些系统拥有一个或多个存储过程，但这些存储过程存在过多的并行性问题。有没有什么好方法可以确定这是否真的是问题所在，或者是否还有其他潜在问题？

通常 sql 有点复杂，可能有 5 个或更多连接，还有一些 udf 甚至更复杂。到目前为止，我通过检查所有常见的性能问题以及更极端的情况（如“无法创建线程...”）以及同一存储过程的多个同时副本导致的死锁，发现了这些问题。

我真的很好奇你们是如何找到这些问题的，以及如何解决这些问题。重新编码？玩MAXDOP（最大并行度）？等等...

我有一个较早执行缓慢的查询。后来我发现它没有并行运行，这使得查询执行速度变慢。

查询涉及一个 big view，然后使用大量temp tablesand查询视图sub query。

我UDF从视图中删除了一个并使用inline functions并使用了一个标量TVF，然后它开始在parallel execution.

这几天一切顺利，有一天我注意到查询运行缓慢。于是查了一下执行计划，发现查询是在串行模式下执行的。我检查了查询的计划缓存，我看到了很多涉及该视图的缓存计划。我删除了不并行的计划，然后查询运行得很快。

现在我每天早上都这样做以强制查询并行运行。

额外细节：

1. SQL Server 2016 标准版
2. 查询通过 LINQ-SQL 从 dot net 应用程序生成。所以临时查询。

如何强制查询永远并行运行？