【问题标题】:Difference in performance between two Azure SQL databases两个 Azure SQL 数据库之间的性能差异
【发布时间】:2018-02-19 08:17:07
【问题描述】:

我的 .Net Core 2 应用程序在两个 Azure 安装之间的性能存在差异,但配置了相同的定价层。

TST“环境”托管在我们的 Azure 订阅中。 ACC“环境”托管在客户端的订阅中。

在这两种环境下,方案配置如下:

  • 具有定价层的服务应用程序:S1
  • 数据库以 S2 标准 (50DTU) 运行。
  • 均位于西欧地区。

我们检查的内容:

  • 数据库(和 Web 应用程序)的使用统计信息永远不会超过 10%。 (大部分时间为零。)
  • 使用构建服务器自动部署解决方案。所以应用程序版本是 100% 相同的
  • 数据库架构和索引相同。使用 EF Core 和迁移来部署数据库更新。
  • 使用工具 Redgate 比较两个数据库。 (没有区别)
  • TST 数据库大小为 360MB。 ACC 为 180MB。

另一个奇怪的地方是在 ACC 数据库上使用“Microsoft SQL Server Management Studio”非常慢。最多 30 秒在表等上显示上下文菜单(鼠标右键单击)。我们的 TST 数据库中没有此功能。

任何想法是我错过了什么或我可以检查的东西?

【问题讨论】:

  • 我认为 Azure SQL 托管会自动为您重建索引,但无论如何可能值得检查碎片。
  • 您是否集成了'Application Insights' 以进一步了解可能导致performance issues 的原因?
  • 请在两个数据库上运行以下查询。什么等待出现在性能不佳的数据库上,或者在缓慢的数据库上有更长的等待时间? SELECT * FROM sys.dm_db_wait_stats ORDER BY wait_time_ms desc
  • @AlbertoMorillo 。在缓慢的数据库上,大多数 max_wait_time_ms 高出 20% 到 50%。一种 wait_type 显着更高。 “IO_COMPLETION”在缓慢的数据库中的值为 2059。它的值:6 在另一个更快的数据库上。

标签: c# azure ef-code-first azure-sql-database azure-web-app-service


【解决方案1】:

我的建议是在缓慢的数据库上重建索引和统计信息,因为 Azure SQL 数据库目前不会自动执行此操作。请尝试this文章提供的解决方案。

如果上述方法没有帮助,请启用Query Store 并专注于那些显示高 I/O 消耗的查询的查询计划。两种环境下的这些计划有什么不同。

【讨论】:

    猜你喜欢
    • 2011-02-09
    • 1970-01-01
    • 2023-02-07
    • 1970-01-01
    • 2021-04-29
    • 1970-01-01
    • 2015-06-21
    • 2011-03-30
    • 1970-01-01
    相关资源
    最近更新 更多