SQL Azure 数据库 DTU 在扩容后增加,没有其他更改

发布于 2025-01-20 23:27:40 字数 354 浏览 0 评论 0原文

当一个单个Azure SQL数据库被升级为(S1-> S3,S7-> S9,P2-> P4等),没有其他更改(无代码部署,负载中没有更改)DTU百分比降低,这一点降低了,这一点是预期。什么可以解释DTU百分比在移动到较高层时增加,然后在降级到较小的层时减少?

换句话说,通常人们可以期望p2 @ 〜80%成为p4 @ 〜40%。什么可以解释p2 @〜80%成为p4 @ 〜90%在稳定的负载下,没有代码更改,并且没有增加的增加,也没有增加数据库(读取数据库,重重编写数据库 更新,插入不多)。

例如,

( /em>

When a single Azure SQL database is upsized to (S1->S3, S7->S9, P2->P4 etc.) with no other changes (no code deployment, no changes in load) the DTU percentage decreases, which is expected. What could explain the DTU percentage increasing upon moving to the higher tier and then decreasing back when downgraded to the smaller tier?

In other words, normally one could expect P2 @ ~80% becoming P4 @ ~40%. What could explain P2 @ ~80% becoming P4 @ ~90% at stable load, no code changes, and no increase is db size (the database is read and write heavy (updates, not many inserts).

For example, could Query Store become busier when more DTUs are available?

Please note this is not after optimizing this database (this work is being done but this is not part of this question)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

娇俏 2025-01-27 23:27:40

当您增加 DTU 时,事务日志吞吐率也会增加。

由于您的数据库具有繁重的更新负载,因此很可能在较低层您的写入受到严重限制,并且您的 CPU 和内存开销接近 MAX> 。

增加 DTU 可以为您提供更多的 CPU 和内存空间,但您的吞吐量可能仍会因大量更新而受到限制。

avg_dtu_percent 使用的公式为 avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent) 因此,您可以看到,如果只有一种资源类型被大量使用,您的 DTU 仍然会显得很高。

要跟踪更详细的使用信息,sys.dm_db_resource_stats 动态管理视图 (DMV) 允许您查看过去一小时的资源消耗情况。 sys.resource_stats 目录视图显示过去 14 天的资源消耗情况,但保真度较低,为五分钟平均值。

When you increase the DTUs you also get an increase in the transaction log throughput rate.

As your database has a heavy UPDATE load, it is likely the case that at the lower tier your writes are being heavily throttled as well as your CPU and Memory overhead being close to the MAX>

Increasing your DTUs allows you more CPU and Memory headroom, but potentially your throughput rate is still being throttled with the high number of UPDATES.

The formula used for avg_dtu_percent is avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent) therefore you can see that your DTU can still appear high if only one of the resource types is being heavily used.

To track more detailed usage information, sys.dm_db_resource_stats dynamic management view (DMV) lets you view resource consumption for the last hour. The sys.resource_stats catalog view displays resource consumption for the last 14 days, but at a lower fidelity of five-minute averages.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文