# DWS资源管理简介 数据库的系统资源（CPU资源、内存资源、IO资源和存储资源）是有限的，DWS在同时运行多种类型的业务（如数据加载、批量分析、实时查询等）时，各类型业务之间可能会竞争资源，从而出现资源性能瓶颈，导致吞吐量下降，造成整体性能低下。那么对系统的资源进行合理的分配，能避免产生资源不合理利用而导致的系统运行效率下降等问题，因此DWS提供了资源管理功能，用户可以根据自身业务将资源按需划分成不同的资源池，不同资源池之间资源互相隔离。 资源管理基本流程架构如[图1 资源管理架构图]所示，其中： - 计算资源池：指定用户的CPU、内存和IO的系统资源，通过资源池进行管理。通过对资源的集中管控，可以有效避免"作业"占用资源的冲突，实现所有作业和谐共处，高优先级的作业优先执行，以及用户间的资源隔离。资源池运行时的可查看用户任务队列、并发度及异常阈值信息。 - 数据存储空间：创建资源池时通过设置**"存储资源(MB)"**来指定存储空间大小，用于限定不同用户可以使用的空间配额。 - 内存管理可以实现节点级别的控制和作业级别的控制。执行作业时，根据资源池定义，进行CPU/内存/IO/存储的资源空间和隔离。 图1资源管理架构图 ![](https://support.huaweicloud.com/mgtg-dws/figure/zh-cn_image_0000002657174367.png "点击放大") #### 视频介绍 #### 功能介绍 资源管理功能由以下几部分组成： - **资源管理配置**：包括资源管理开关、全局最大并发数。这里的全局最大并发数指的是单个CN上的最大并发数，如果关闭了资源管理功能，那么所有的资源管理功能将不可用。 - **[资源池](https://support.huaweicloud.com/mgtg-dws/dws_01_07231.html)**：计算资源管理主要由资源池功能实现，对计算资源进行隔离和限制，防止异常SQL查询导致集群级异常。 - **[资源管理计划](https://support.huaweicloud.com/mgtg-dws/dws_01_72363.html)**：按计划进行资源管理自动配置，应对复杂多变的负载场景，实现更为灵活的资源管理。 - **[schema空间管理](https://support.huaweicloud.com/mgtg-dws/dws_01_72366.html)**：设置schema的最大存储空间，防止磁盘满和数据库只读。 - **用户空间管理** ：创建资源池时，设置存储空间的大小，将资源池关联到用户上，详情请参见[添加资源池](https://support.huaweicloud.com/mgtg-dws/dws_01_07231.html#ZH-CN_TOPIC_0000002617625207__section1239585215495)。 - **[异常规则](https://support.huaweicloud.com/mgtg-dws/dws_01_72367.html)**：用于异常查询的识别和快速处理，防止"低质量SQL"长时间占用大量资源，导致其他查询阻塞或性能下降。 - **[查询过滤器](https://support.huaweicloud.com/mgtg-dws/dws_01_72368.html)**：通过建立过滤规则提前进行语句拦截，解决因慢SQL导致整个集群系统性能变差甚至不可用等痛点问题。 #### 约束与限制 - 资源管理仅8.0.0及以上集群版本支持。 - CPU专属限额仅8.1.3及以上集群版本支持。 - 资源管理计划仅支持8.1.0.100及以上集群版本。 #### 并发管理 DWS提供了精细化的资源管理功能，在查询进行资源管理前，根据查询预期执行时间和资源消耗，将查询划分为执行时间长、资源消耗多的复杂查询和执行时间短、资源消耗少的简单查询。简单查询和复杂查询的划分和资源消耗相关，因此根据估算内存对查询进行划分： - **简单查询：**估算内存小于32MB。 - **复杂查询：**估算内存大于或等于32MB。 混合负载场景下，复杂查询可能会长时间占用大量资源，虽然简单查询执行时间短、消耗资源少，但是因为资源耗尽，简单查询不得不在资源池中等待复杂查询执行完成。为提升执行效率、提高系统吞吐量，DWS的短查询加速功能，实现对简单查询的单独管理。在资源池页面**"短查询配置"**一栏，您可以通过开关键决定是否开启短查询加速功能。如果需要对简单语句并发数（默认值为-1，0 或-1表示不控制）进行修改，可选择打开短查询加速。 并发管理规则如下： - **短查询加速开启：**复杂查询受资源池并发控制，简单查询受短查询并发控制。简单查询与复杂查询分开管理，简单查询无需与复杂查询竞争资源。 - **短查询加速关闭：**复杂查询和简单查询均受资源池并发控制，短查询并发控制无效。简单查询与复杂查询执行相同的资源管理操作（基于估算内存的查询划分一方面依赖估算内存的准确性，另一方面查询执行时间和CPU消耗可能与内存消耗不成正比，因此对于性能不敏感、业务明确的资源池可以通过关闭短查询加速实现对简单作业的资源管理和异常处理）。 虽然单个简单作业资源消耗少，但是大量简单作业并发运行还是会占用大量资源，因此短查询加速开启情况下，需要对简单查询进行并发管理（并发，即资源池中的最大查询并发数），并发管理作为运行前管理，用于限制查询并发运行的数量，通过限制查询并发数降低资源争抢，保证资源的有序高效利用。资源管理可能会影响查询性能，影响系统吞吐量，因此简单查询不进行资源管理，异常规则也不生效。 #### 内存管理 内存资源，即资源池所占用的内存百分比。 内存管理的目的：防止数据库系统占用内存过高导致内存溢出（OOM）和实现资源池之间的内存隔离和限制。为满足这两个目的，资源管理从以下两方面进行内存管理： - **全局内存管理** 为防止数据库系统使用内存过大导致OOM，设置数据库系统全局内存上限（max_process_memory），对数据库全局内存进行管理。全局内存管理包含运行前管理和运行中管理，运行中管理防止实际使用内存超限，运行前管理防止查询执行过程中报错，具体如下： - **运行前管理：** 一方面慢车道运行的所有查询估算内存都会进行统计，另一方面数据库系统实际使用内存会进行反馈，当实际使用内存大于统计内存时，对统计内存进行调整。查询运行前，判断全局剩余内存能否满足查询运行，满足情况下查询可以直接运行，否则查询需要排队，等待其他查询释放资源后运行。**运行前管理包含** **并发管理** **和运行前** **内存管理**。 - **运行中管理：** 查询执行过程中实际使用的内存也会进行统计，查询在申请内存时判断内存使用是否超限，内存超限查询报错，已用内存释放。**运行中管理包含运行中** **内存管理** **、** **CPU管理** **、** **空间管理** **和** **异常规则**。 - **资源池内存管理** 资源池内存管理属于专属限额的管理方式，即资源池分配多少内存就只能使用多少内存，空闲出来的内存其他资源池不能使用。 资源池内存分配采用百分比方式，取值范围0\~100。0表示资源池不进行内存管理，100表示资源池进行内存管理且可使用全局所有内存。 所有资源池分配的内存百分比之和不能超过100%。资源池内存管理仅管控慢车道查询，且只包含运行前管理，处理逻辑与全局内存运行前管理类似。资源池慢车道查询运行前，进行估算内存统计，当统计内存大于资源池内存时，查询需要排队，等待资源池内其他查询运行结束释放资源后才能运行。 #### CPU管理 DWS主要利用cgroup（control group，控制组）进行CPU资源管控，涉及CPU、cpuacct、cpuset子系统。目前支持**"共享配额"** 和**"专属限额"** 两种CPU管理方式，在资源池页面**"资源配置"** 一栏，您可以修改当前资源池的CPU**"共享配额"** 和**"专属限额"**。 #### 共享配额 **CPU共享配额** ：在CPU系统繁忙的情况下，不同资源池按照共享配额配置分配CPU资源；在CPU系统空闲的情况下，该配置不生效。 - **共享**：CPU是所有控制组共享的，其他控制组能够使用空闲的CPU资源。 - **配额**：业务繁忙、CPU满负载情况下，控制组之间按照配额比例进行CPU抢占。 共享配额基于**cpu.shares**实现，只有在CPU满负载情况下生效，CPU没有占满的情况下不触发管控，因此在CPU空闲情况下并不能保证控制组能够抢占到配额比例的CPU资源。CPU空闲并不能理解为没有CPU资源争抢，控制组内任务可以任意使用CPU。虽然CPU平均使用率可能不高，但是某个特定时刻还是可能存在CPU资源争抢的。 例如：10个CPU上运行10个作业，每个CPU上运行1个作业，这种情况下各作业在任意时刻请求CPU都可以瞬间得到响应，作业之间没有任何CPU资源的争抢；但假如10个CPU上运行20个作业，因为作业不会一直占用CPU，在某些时间可能等待IO、网络等，因此CPU使用率可能并不高，此时CPU资源看似空闲，但是在某个时刻可能出现2\~N作业同时请求一个CPU的情况出现，即会导致CPU资源争抢，影响作业性能。 #### 专属限额 **CPU专属限额** ：限制资源池使用的CPU核数上限，无论CPU系统繁忙或者空闲，该资源池上的作业都无法突破该限额配置。 - **专属**：CPU是某个控制组专属的，其他已设置限额的控制组不能使用空闲的CPU资源。 - **限额**：只能使用限额配置的CPU资源，其他控制组空闲的CPU资源，也不能抢占。 专属限额基于**cpuset.cpu**实现，通过合理的限额设置可以实现控制组之间CPU资源的绝对隔离，各控制组间任务互不影响。但因为CPU的绝对隔离，因此在控制组空闲时就会导致CPU资源的极大浪费，因此限额设置不能太大。从作业性能来看并不是限额越大越好。 例如：10个作业运行在10个CPU上，CPU平均使用率5%左右；10个作业运行在5个CPU上，CPU平均使用率10%左右。通过上面共享配额的分析可知：虽然10个作业运行在5个CPU上CPU使用率很低，看似空闲，但是相对10个作业运行在10个CPU上还是存在某种程度的CPU资源争抢，因此10个作业运行在10个CPU上性能要好于运行在5个CPU上。但也不是越多越好，10个作业运行在20个CPU上，在任意一个时刻，总会至少10个CPU是空闲的，因此理论上10个作业运行在20个CPU上并不会比运行在10个CPU上性能更好。对于并发为N的控制组，分配cpus小于N的情况下，CPU越多作业性能越好；但是当分配CPUs大于N的情况下，性能就不会有任何提升了。 #### 共享配额和专属限额区别 表1共享配额和专属限额区别 | CPU资源 | 资源优势 | 资源劣势 | |:---|:---|:---| | 共享配额 | 共享配额拥有更高的CPU使用率和更高的整体作业吞吐量，可以实现CPU资源的充分利用。 | 资源池之间隔离不彻底，可能影响查询性能。 | | 专属限额 | 专属限额CPU隔离彻底，可以实现CPU资源的绝对隔离，更满足性能敏感用户的使用诉求。 | 在资源池CPU资源空闲时，会造成资源的浪费。 | #### CPU资源管控应用场景 数据库系统中运行多种类型作业出现CPU争抢时，可根据不同场景，选择不同的CPU资源管控方式。 表2CPU场景管控场景 | 场景 | 描述 | 应用建议 | |:---|:---|:---| | 场景一 | 实现CPU资源的充分利用，不关注单一类型作业的性能，主要关注CPU整体吞吐量。 | 不建议进行用户之间的CPU隔离管控，无论哪一种CPU管控都会对CPU整体使用率产生影响。 | | 场景二 | 允许一定程度的CPU资源争抢和性能损耗，在CPU空闲情况下实现CPU资源充分利用，在CPU满负载情况下需要各业务类型按比例使用CPU。 | 可以采用基于cpu.shares的共享配额管控方式，在实现满负载CPU隔离管控前提下，尽量提高CPU整体使用率。 | | 场景三 | 部分作业对性能敏感，允许CPU资源的浪费。 | 可以采用基于cpuset.cpu的专属限额管控方式，实现不同类型作业之间的CPU绝对隔离。 |