Azure Sql 数据库中的 CXSYNC_PORT 等待类型

Question

我现在间歇性地面临这个问题，其中查询（从存储过程调用）采用 CXSYNC_PORT 等待类型，并继续保持较长时间（有时延长 8 小时）。我必须终止该进程，然后重新运行该过程。 ADF 管道每 2 小时调用一次此过程。

此行为的原因是什么以及如何解决该问题？

Answer 1

查了很多，没有微软文档讲等待类型：CXSYNC_PORT。其他人也问过同样的问题，但仍然没有更多细节。

大多数建议是在更多论坛中提出相同的问题。或者请专业工程师帮助，他们会单独保密地处理您的问题。

向 Azure 支持人员询问详细帮助：https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

这是同样的问题，微软工程师提供了有关该问题的更多详细信息：

• 作为修复的一部分，CXPACKET 等待被进一步细分为 CXSYNC_CONSUMER 和 CXSYNC_PORT（并且数据传输仍然等待 报告为 CXPACKET）以区分不同的等待时间 以便正确诊断问题。
• 基本上，CXPACKET分为3种：CXPACKET、CXSYNC_PORT、 CXSYNC_CONSUMER。 CXPACKET用于数据传输同步，而 CXSYNC_* 用于其他同步。 CXSYNC_PORT 用于 同步消费之间交换端口的打开/关闭 线程和生产线程。 此处长时间等待可能表明服务器负载过重 并且缺乏可用的线程。 包含排序的计划可能会有所贡献 这种等待类型是因为在端口被分配之前可能会发生完整的排序 已同步。

请参考此链接是什么导致等待类型CXSYNC_PORT以及如何处理它？以获取更多有用的消息。但目前还没有确切的解决方案。

Answer 2

使用查询提示 OPTION(MAXDOP 1) 这将在单个线程中运行长时间运行的查询，并且您不会得到 CX 类型等待。根据我的经验，这可以使执行时间大幅减少 10-20 倍，并且可以释放 CPU 用于其他任务，因为不会有上下文切换和线程协调活动。

Answer 3

如果您通过使用单线程查询 (MAXDOP1) 来减少 CX 等待，您还可能会增加查询的响应时间，从而可能会锁定其他查询更长时间。 您可以在查询级别尝试选项（maxdop 1），测试并不昂贵，但您也可以:

• 将并行度（实例级别）的成本阈值从 5 提高到 25 甚至 50
• 将实例或数据库 MAXDOP 从 CPU 的 0 减少到 1/4
• 尝试重写查询
• 尝试看看新索引是否有帮助
• 更新查询相关表的统计信息