Azure SQL 数据库和 Azure Synapse Analytics 服务器的资源限制

适用于: Azure SQL 数据库 Azure Synapse Analytics

本文概述了 Azure SQL 数据库和 Azure Synapse Analytics 所使用的逻辑服务器的资源限制。 还提供了有关当达到或超过这些资源限制时会发生的情况的信息,并描述了用于执行这些限制的资源治理机制。

备注

有关 Azure SQL 托管实例限制,请参阅托管实例的资源限制

最大资源限制

资源 限制
逻辑服务器的数据库 5000
某一区域中每个订阅的逻辑服务器默认数量 20
某一区域中每个订阅的逻辑服务器最大数量 200
每个逻辑服务器的 DTU/eDTU 配额 54,000
每个逻辑服务器的 vCore 配额 540
每个逻辑服务器的最大池数 受限于 DTU 或 vCore 数。 例如,如果每个池是 1000 个 DTU,则一个服务器可以支持 54 个池。

重要

当数据库的数量接近每个逻辑服务器的限制时,可能会出现以下情况:

  • 对主数据库运行查询的延迟增加。 这包括资源利用率统计信息的视图,如 sys.resource_stats
  • 管理操作和呈现门户视点(涉及枚举服务器中的数据库)的延迟增加。

备注

若要获取更高的 DTU/eDTU 配额、vCore 配额或超过默认数量的逻辑服务器,请在 Azure 门户中提交新的支持请求。

存储大小

对于单一数据库资源存储大小,请参阅基于 DTU 的资源限制基于 vCore 的资源限制,了解每个定价层(也称为服务目标)的存储大小限制。

如果达到数据库资源限制,会发生什么?

计算 CPU

当数据库计算 CPU 使用率变高时,查询延迟也会增加,查询甚至可能超时。在上述情况下,服务可能对查询排队,并在资源可用时向查询提供资源以用于执行。 计算使用率变高时,风险缓解选项包括:

存储

当使用的数据库空间到达数据大小上限时,将无法进行增加数据大小的数据库插入和更新操作,客户端会收到错误消息。 SELECT 和 DELETE 语句不受影响。

在“高级”和“业务关键”服务层级中,如果数据、事务日志和 tempdb 消耗的存储总量超过最大本地存储大小,则客户端也会收到错误消息。 有关详细信息,请参阅存储空间调控

空间使用率变高时,风险缓解选项包括:

  • 增大数据库或弹性池的最大数据大小,或者纵向扩展到数据大小上限更高的服务目标。 请参阅缩放单一数据库资源缩放弹性池资源
  • 如果数据库在弹性池内,可选择将数据库移出弹性池,从而避免与其他数据库共享存储空间。
  • 收缩数据库来回收未使用的空间。 在弹性池中,收缩数据库可为池中的其他数据库提供更多存储。 有关详细信息,请参阅管理 Azure SQL 数据库中的文件空间
  • 检查高空间利用率是否是由永久性版本存储 (PVS) 大小的峰值所造成的。 PVS 是每个数据库的一部分,用于实现加速数据库恢复。 若要确定当前的 PVS 大小,请参阅 PVS 故障排除。 PVS 大小较大的常见原因是事务长时间(数小时)开放,从而无法清理 PVS 中较旧的版本。
  • 对于“高级”和“业务关键”服务层级中的大型数据库,即使数据库中使用的空间低于其大小上限,你也可能会收到空间不足错误。 如果 tempdb 或事务日志消耗了大量存储,以致快要达到本地存储上限,则可能会发生这种情况。 故障转移数据库或弹性池以将 tempdb 重置为其初始的较小大小,或收缩事务日志以减少本地存储消耗量。

会话和辅助角色(请求)

会话和辅助角色的数目上限由服务层级和计算大小(DTU/eDTU 或 vCore)决定。 当到达会话或辅助角色上限时,新的请求将被拒绝,客户端将收到错误消息。 虽然应用程序可以轻松地控制可用的连接数,但并行辅助角色数通常更难以估计和控制。 在负荷高峰期,当数据库资源达到上限,辅助角色由于查询运行时间较长、阻塞链大或查询并行度过高而堆积时,这种情况尤其突出。

会话或辅助角色使用率变高时,风险缓解选项包括:

内存

与其他资源(CPU、辅助角色、存储)不同,达到内存限制不会对查询性能产生负面影响,也不会导致错误和失败。 正如内存管理体系结构指南中详细描述的那样,SQL Server 数据库引擎通常使用所有可用内存,这是设计使然。 内存主要用于缓存数据,以避免更昂贵的存储访问。 因此,较高的内存利用率通常会提高查询性能,因为从内存中读取的速度更快,而从存储中读取的速度更慢。

在数据库引擎启动之后,当工作负载开始从存储中读取数据时,数据库引擎会积极地在内存中缓存数据。 经过这一初始增长期之后,通常可看到 sys.dm_db_resource_stats 中的 avg_memory_usage_percentavg_instance_memory_percent 列接近或等于 100%,尤其是对于非空闲且不能完全装入内存的数据库。

除了数据缓存之外,内存还用于数据库引擎的其他组件。 当有内存需求且所有可用内存已被数据缓存占用时,数据库引擎将动态收缩数据缓存大小以使内存可供其他组件使用,并在其他组件释放内存时动态增加数据缓存。

在极少数情况下,要求十分高的工作负载可能会导致内存不足,从而导致内存不足错误。 这可能发生在内存使用率介于 0% 和 100% 之间的任何级别。 这更有可能发生在具有比例较小的内存限制的较小计算大小和/或使用更多内存进行查询处理的工作负载上,例如在密集的弹性池中。

遇到内存不足错误时,缓解选项包括:

解决方案 说明
减少内存授予的大小 有关内存授予的详细信息,请参阅了解 SQL Server 内存授予博客文章。 避免过大内存授予的一个常见解决方案是使统计信息保持最新状态。 这可使查询引擎更准确地估计内存消耗,从而避免内存授予过大。

在使用兼容级别 140 及更高级别的数据库中,数据库引擎可使用批处理模式内存授予反馈自动调整内存授予大小。 在使用兼容级别 150 及更高级别的数据库中,数据库引擎类似地使用行模式内存授予反馈,用于更常见的行模式查询。 此内置功能有助于避免由于内存授予过大而导致的内存不足错误。
减小查询计划缓存的大小 数据库引擎在内存中缓存查询计划,以避免为每次查询执行编译查询计划。 若要避免由于仅使用一次的缓存计划而导致的查询计划缓存膨胀,请启用 OPTIMIZE_FOR_AD_HOC_WORKLOADS 数据库范围内的配置
减小锁定内存的大小 数据库引擎将内存用于锁定。 如果可能,请避免可能获取大量锁定并导致高锁定内存消耗的大型事务。

用户工作负荷和内部进程的资源消耗量

将在 sys.dm_db_resource_statssys.resource_stats 视图的 avg_cpu_percentavg_memory_usage_percent 列中报告每个数据库中的用户工作负荷的 CPU 和内存消耗量。 对于弹性池,将在 sys.elastic_pool_resource_stats 视图中报告池级别的资源消耗量。 对于池级别的单一数据库弹性池,还会通过 Azure Monitor 指标 cpu_percent 报告用户工作负荷的 CPU 消耗量。

Azure SQL 数据库需要使用计算资源来实现核心服务功能,例如高可用性和灾难恢复、数据库备份和还原、监视、查询存储、自动优化,等等。对于这些内部进程,系统会使用资源治理机制从总体资源中为其留出有限的一部分特定资源,使剩余的资源可供用户工作负载使用。 当内部进程不使用计算资源时,系统会将其提供给用户工作负载使用。

将在 sys.dm_db_resource_statssys.resource_stats 视图的 avg_instance_cpu_percentavg_instance_memory_percent 列中报告用户工作负载和内部进程的总 CPU 和内存消耗量。 对于池级别的单一数据库弹性池,还会通过 Azure Monitor 指标 sqlserver_process_core_percentsqlserver_process_memory_percent 报告此数据。

sys.dm_resource_governor_resource_pools_history_exsys.dm_resource_governor_workload_groups_history_ex 视图报告了用户工作负载和内部流程最近资源消耗的更详细信息。 有关这些视图中提及的资源池和工作负载组的详细信息,请参阅资源治理。 这些视图报告了相关资源池和工作负载组中用户工作负载和特定内部流程的资源利用情况。

在性能监视和故障排除上下文中,必须考虑用户 CPU 消耗量(avg_cpu_percentcpu_percent),以及用户工作负载和内部进程的 CPU 总消耗量(avg_instance_cpu_percentsqlserver_process_core_percent) 。

用户 CPU 消耗量的计算值为每个服务目标中用户工作负荷限制的一个百分比。 用户 CPU 利用率为 100% 表示用户工作负荷达到了服务目标的限制。 但是,当 CPU 总消耗量达到 70-100% 范围时,即使报告的用户 CPU 消耗量明显低于 100%,也可能会看到用户工作负载吞吐量保持平稳,但查询延迟增大 。 对适度分配的计算资源但相对密集的用户工作负载(例如在密集弹性池中)使用较小的服务目标时,更有可能会发生这种情况。 当内部进程临时需要更多的资源时(例如,在创建数据库的新副本时),使用较小的服务目标也可能发生这种情况。

当 CPU 总消耗量较高时,缓解措施与前面所述相同,也包括增大服务目标和/或优化用户工作负载。

资源调控

为了强制实施资源限制,Azure SQL 数据库使用基于 SQL Server Resource Governor、经过修改和扩展的资源治理实现在 Azure SQL 数据库中运行。 在 SQL 数据库中,多个资源池工作负载组以及在池和组级别设置的资源限制提供了均衡的数据库即服务。 用户的工作负载和内部工作负载分为单独的资源池和工作负载组。 主副本和可读次要副本(包括地理副本)上的用户工作负载分为 SloSharedPool1 资源库和 UserPrimaryGroup.DBId[N] 工作负载组,其中 N 代表数据库 ID 值。 此外,还有多个资源库和各种内部工作负载的工作负载组。

除使用 Resource Governor 来管控 SQL 进程中的资源外,Azure SQL 数据库还使用 Windows 作业对象进行流程级资源治理,并使用 Windows 文件服务器资源管理器 (FSRM) 来存储配额管理。

Azure SQL 数据库资源治理本质上是分层的。 自上而下,使用操作系统资源治理机制和 Resource Governor 在 OS 级别和存储卷级别执行限制,然后使用 Resource Governor 在资源池级别执行限制,再使用 Resource Governor 在工作负载组级别执行限制。 sys.dm_user_db_resource_governance 视图中显示当前数据库或弹性池的资源治理限制。

数据 IO 治理

数据 IO 治理是 Azure SQL 数据库中的一个过程,用于限制对数据库数据文件的读取和写入物理 IO。 为每个服务级别设置 IOPS 限制,以最大限度地减少“邻近干扰”效果,在多租户服务中提供资源分配公平性,并保持在基础硬件和存储功能范围内。

对于单一数据库,工作负载组限制适用于针对数据库的所有存储 IO,而资源池限制适用于同一专用 SQL 池中的所有数据库,包括 tempdb 数据库。 对于弹性池,工作负载组限制适用于池中的每个数据库,而资源池限制适用于整个弹性池,包括池中所有数据库共享的 tempdb 数据库。 一般来说,由于工作负载组限制低于资源池限制,并且限制 IOPS/吞吐量的速度更快,因此无法通过针对数据库的工作负载(单一或公用)实现资源池限制。 但是,可通过对同一池中的多个数据库的组合工作负载来达到池限制。

例如,如果查询在没有任何 IO 资源治理的情况下生成 1000 IOPS,但工作负载组的最大 IOPS 限制设置为 900 IOPS,则该查询将无法生成超过 900 的 IOPS。 但是,如果资源池的最大 IOPS 限制设置为 1500 IOPS,并且与资源池关联的所有工作负载组的总 IO 超过 1500 IOPS,则同一查询的 IO 可能会降低到 900 IOPS 的工作组限制以下。

sys.dm_user_db_resource_governance 视图返回的 IOPS 和吞吐量最小/最大值作为限制/上限,而不是保证。 而且,资源治理并不保证任何特定的存储延迟。 给定用户工作负载的最佳可实现延迟、IOPS 和吞吐量不仅取决于 IO 资源治理限制,还取决于所使用的 IO 大小组合以及基础存储的功能。 SQL 数据库使用的 IO 大小在 512 KB 和 4 MB 之间变化。 为了执行 IOPS 限制,除 Azure 存储中包含的数据文件的数据库外,每个 IO 都会被计入,无论其大小如何。 在这种情况下,大于 256 KB 的 IO 计为多个 256-KB IO,以符合 Azure 存储 IO 数据记录。

对于在 Azure 存储中使用数据文件的基础、标准和通用数据库,如果数据库没有足够的数据文件来累计提供此数量的 IOPS,或者如果数据没有在文件之间均匀分布,再或者基础 Blob 的性能层将 IOPS/吞吐量限制到低于资源治理限制,则可能无法实现 primary_group_max_io 值。 同样,对于因频繁事务提交而产生的小型日志 IO,由于存在基础 Azure 存储 Blob 的 IOPS 限制,可能无法通过工作负载实现 primary_max_log_rate 值。 对于使用 Azure 高级存储的数据库,Azure SQL 数据库使用足够大的存储 Blob 来获取所需的 IOPS/吞吐量,无论数据库大小如何。 对于较大的数据库,将创建多个数据文件,以提高 IOPS/吞吐量总容量。

资源利用率值(如 sys.dm_db_resource_statssys.resource_statssys.elastic_pool_resource_stats 视图中报告的 avg_data_io_percentavg_log_write_percent),被计为最大值资源治理限制的百分比。 因此,当资源治理以外的因素限制 IOPS/吞吐量时,即使报告的资源利用率仍低于 100%,IOPS/吞吐量仍可能随着工作负载的增加而趋于平缓和延迟增加。

若要查看每个数据库文件的读取和写入 IOPS、吞吐量和延迟,请使用 sys.dm_io_virtual_file_stats() 函数。 此函数将呈现针对数据库的所有 IO,包括后台 IO,此 IO 没有计入 avg_data_io_percent,但使用基础存储的 IOPS 和吞吐量并可能会影响观测到的存储延迟。 该函数分别在 io_stall_queued_read_ms 列和 io_stall_queued_write_ms 列中显示 IO 资源治理可能引入的读取和写入额外延迟。

事务日志速率调控

事务日志速率调控是 Azure SQL 数据库中的一个进程,用于限制批量插入、SELECT INTO 和索引生成等工作负荷的高引入速率。 无论针对数据文件发出多少 IO,系统都会对日志记录生成速率跟踪并实施这些限制,使其保持在亚秒级以下,并限制吞吐量。 目前,事务日志生成速率会线性提高到与硬件相关的临界点,在 vCore 购买模型中,允许的最大日志速率为 96 MB/秒。

备注

向事务日志文件发出的实际物理 IO 不会受到调控或限制。

日志速率的设置应该做到可在各种场合下实现并保持该速率,同时,整个系统可以在尽量减轻对用户负载造成的影响的前提下保持其功能。 日志速率调控可确保事务日志备份保留在已发布的可恢复性 SLA 范围内。 这种调控还可以防止次要副本带来过多的积压工作。

生成日志记录后,将评估每个操作,以确定是否要将其延迟,从而保持最大所需日志速率(MB/秒)。 将日志记录刷新到存储时不会增大延迟,日志速率治理是在日志速率生成期间应用的。

在运行时实施的实际日志生成速率还可能受到反馈机制(暂时降低允许的日志速率,使系统保持稳定)的影响。 日志文件空间管理可避免遇到日志空间不间的情况,可用性组复制机制可以暂时降低总体系统限制。

可通过以下 wait 类型(在 sys.dm_exec_requestssys.dm_os_wait_stats 视图中公开)查看日志速率调控器流量的形状:

Wait 类型 说明
LOG_RATE_GOVERNOR 数据库限制
POOL_LOG_RATE_GOVERNOR 池限制
INSTANCE_LOG_RATE_GOVERNOR 实例级限制
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE 反馈控制。高级/业务关键型工作负荷中的可用性组物理复制不会保持
HADR_THROTTLE_LOG_RATE_LOG_SIZE 反馈控制。限制速率可以避免出现日志空间不足的情况
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO 地理复制反馈控制、限制日志速率,以避免高数据延迟和地理辅助系统不可用

当日志速率限制阻碍实现所需的可伸缩性时,请考虑以下选项:

  • 纵向扩展到更高的服务级别,以获得 96 MB/秒的最大日志速率,或切换到不同的服务层。 无论选择的服务级别如何,超大规模服务层均提供 100 MB/s 日志速率。
  • 如果加载的数据是暂时性的(例如 ETL 过程中的暂存数据),可将其载入 tempdb(记录最少量的数据)。
  • 对于分析方案,可将数据载入聚集列存储涵盖的表中。 这样,可以通过压缩来降低所需的日志速率。 此方法确实会增大 CPU 利用率,并且仅适用于可从聚集列存储索引受益的数据集。

存储空间治理

在“高级”和“业务关键”服务层级中,客户数据(包括数据文件、事务日志文件和 tempdb 文件)存储在用于托管数据库或弹性池的计算机的本地 SSD 存储中 。 本地 SSD 存储提供较高的 IOPS 和吞吐量,以及较低的 IO 延迟。 除了用于存储客户数据以外,本地存储还用于存储操作系统、管理软件、监视数据和日志,以及执行系统操作所需的其他文件。

本地存储的大小有限,具体取决于硬件功能(决定了本地存储的上限)或者为客户数据预留的本地存储。 设置此限制的目的是最大化客户数据存储,同时确保安全可靠的系统操作。 若要查找每个服务目标的最大本地存储值,请参阅单一数据库弹性池的资源限制文档。

还可使用以下查询查找此值,以及给定数据库或弹性池当前使用的本地存储量:

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();
说明
server_name 逻辑服务器名称
database_name 数据库名称
slo_name 服务目标名称,包括硬件代系
user_data_directory_space_quota_mb 最大本地存储,以 MB 为单位
user_data_directory_space_usage_mb 数据文件、事务日志文件和 tempdb 文件当前消耗的本地存储量,以 MB 为单位。 每隔五分钟更新一次。

应在用户数据库而不是 master 数据库中执行此查询。 对于弹性池,可在池内的任何数据库中执行该查询。 报告的值适用于整个池。

重要

在“高级”和“业务关键”服务层级中,如果工作负载尝试将数据文件、事务日志文件和 tempdb 文件消耗的本地存储总量增大至超过本地存储上限,则会出现空间不足错误。

随着创建、删除数据库以及增大或减小其大小,计算机上的本地存储消耗量会不断波动。 如果系统检测到计算机上的可用本地存储不足,并且某个数据库或弹性池有耗尽空间的风险,则系统会将该数据库或弹性池移到具有足够可用本地存储的其他计算机。

此移动以联机方式发生,类似于数据库缩放操作,并具有类似的影响,包括操作结束时的短暂(几秒)故障转移。 此故障转移会终止打开的连接并回退事务,这可能会影响当时使用数据库的应用程序。

由于所有数据将复制到其他计算机上的本地存储卷,移动大型数据库可能需要大量时间。 在此期间,如果数据库、弹性池或 tempdb 数据库的本地空间消耗量快速增长,则空间耗尽的风险会增加。 系统将以平衡的方式启动数据库移动,以尽量减少出现空间耗尽错误,同时避免不必要的故障转移。

备注

因本地存储不足而执行的数据库移动只会在“高级”或“业务关键”服务层级中发生。 这种移动不会在“超大规模”、“常规用途”、“标准”和“基本”服务层级中发生,因为在这些层级中,数据文件不是存储在本地存储中。

后续步骤