sql-server - Azure SQL Server 读取横向扩展性能

Question

作为一项测试，我们最近开始向 Azure 中的读取横向扩展 SQL Server 发送一些查询。我们的主数据库是 40 核 BC。我们注意到一些性能相当差，查询的执行时间比我们的主数据库要多 10 倍或更长。

我想我对此无能为力？没有查询存储，看起来没有任何方法可以调整数据库？

Answer 1

我们在读取横向扩展副本时遇到了类似的问题。我们使用 Azure SQL vCore 40 Business Critical 进行 OLTP。经过无数个小时的调试和监控，我们确定读取横向扩展副本受到主写入数量的严重影响。

在我们的案例中，我们观察到读取横向扩展副本中的读取查询有大量 SOS_SCHEDULER_YIELD 等待类型，并且 CPU 使用率高达 100%。如果我们将相同的读取查询切换到主数据库，CPU 永远不会超过 30%，并且 SOS_SCHEDULER_YIELD 不是普遍的等待类型。

以下查询显示 SOS_SCHEDULER_YIELD 是读取横向扩展中的主要信号等待时间，但不是主要信号等待时间。

select * from sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

我们使用生产数据库的副本、仅 3 个读取查询、1 个大量写入查询和并行运行读取查询的 .NET 应用程序，将问题简化为小型测试用例。我们使用了 12 个 vCore 关键业务数据库。

• 测试 1:在主数据库上执行读取查询。结果:约 1500 个读取查询/秒，主数据库 sys.dm_db_resource_stats 中的 CPU 使用率为 60%
• 测试 2:在读取扩展时执行读取查询。结果:约 1500 次读取查询/秒，读取横向扩展中 sys.dm_db_resource_stats 中的 CPU 使用率为 60%
• 测试 3:在主数据库上执行写入查询并在主数据库上执行读取查询。结果:约 1500 个读取查询/秒，主数据库 sys.dm_db_resource_stats 中的 CPU 使用率为 70%
• 测试 4:在主数据库上执行写入查询，在读取横向扩展上执行读取查询。结果:约 800 次读取查询/秒，读取扩展中 sys.dm_db_resource_stats 中的 CPU 使用率为 100%，主数据库中为 10%

Microsoft 支持和产品团队确认 Azure SQL 中当前复制模型中的自旋锁存在问题，并对我们的数据库进行了临时修复 - 将复制从并行切换到其他模型。这为我们解决了这个问题。我们不确定是否修复了所有数据库。