理论 + 示例，详解 GaussDB(DWS) 资源管理
本文分享自华为云社区《GaussDB(DWS)资源管理能力介绍与应用示例》，作者： 门前一棵葡萄树 。
一、资源管理能力
1.1 概述
数据库运行过程中使用的公共资源包含：系统资源（CPU、内存、网络等）和数据库共享资源(锁、计数等)。作业运行过程中总是希望获得更多的公共资源，以获得最好的执行性能。但是公共资源的滥用可能导致数据库系统的不稳定，引发资源过载，影响高优业务的 QoS（服务质量），甚至阻塞业务运行。因此，合理地管理和分配系统资源，是保证数据库系统稳定高效运行的关键。
资源管理的目标：
防止资源过载，引发系统级故障；
实现高优业务的优先调度，保证高优业务 QoS；
实现业务之间的资源隔离，防止业务之间资源争抢严重；
实现业务的错峰分时调度，防止瞬时高并发影响系统稳定性；
快速识别异常查询，保证正常业务稳定运行。
1.2 基本原理
资源池是一种用于对系统资源进行划分的技术，通过为资源池设置资源上限的方式，实现对其内运行作业的资源管控。资源池可以帮助系统管理员更好地管理和分配系统资源，提高系统的可用性和稳定性。
GaussDB(DWS)提供了资源管理功能，借助资源池实现业务之间的资源隔离和查询调度（不同业务路由至不同资源池）。GaussDB(DWS)支持两种路由策略：
用户-资源池：将用户关联至资源池，用户执行作业时，根据“用户-资源池”的关联关系，将作业路由至对应资源池执行。
query_band 负载识别：业务设置 query_band（USERSET 参数），根据 query_band 和资源池关联关系，将作业路由至对应资源池执行。
实际应用过程中，建议优先使用用户-资源池的路由方式；在用户-资源池的路由方式无法满足隔离诉求时，使用 query_band 负载识别实现业务隔离。
1.3 能力介绍
GaussDB(DWS)支持负载管理、资源管控、异常规则、查询过滤器以及负载计划等资源管理能力，不同的资源管理能力有不同的使用场景，实际应用中可能会用到其中 1~N 个资源管理能力。
1.3.1 负载管理
支持基于并发和估算内存的查询调度，防止并发过大引发资源争抢严重、导致查询堆积。多 CN 场景下，CN 之间互相不感知负载情况，因此无法精确控制整个集群的并发和内存使用，可能触发内存不足报错。因此为保证多 CN 场景下的并发和内存可控，设计实现 CCN 用于查询的统一调度。CM 在第一次集群启动时，通过集群部署形式，选择编号最小的 CN 作为 CCN，CCN 故障之后，由 CM 选择新的 CCN 进行替换。
虽然 CCN 管控可以实现更为精准的管控，但是 CCN 管控逻辑更为复杂且涉及 CN-CCN 间通信，通信延迟（10ms~1s 之间）和复杂的管控逻辑可能导致作业性能不稳定，此外 CCN 还可能成为提高系统并发的瓶颈。因此设计实现“短查询加速”功能，实现对简单查询和复杂查询的分别管控。复杂查询执行时间长、内存消耗大，CCN 管控对其性能影响有限；简单查询执行时间短、内存消耗小，CN 管控可以降低管控对其的性能影响。CCN 管控的主要目的是防止内存不足报错，因此我们根据估算内存对查询进行分类：
简单查询：估算内存小于 32MB；
复杂查询：估算内存大于等于 32MB。
为提升简单查询性能，默认情况下简单查询只进行并发控制，而不进行内存和 CPU 管控。实际应用场景下，优先级低的业务可能性能不敏感，而且需要精准管控其使用的 CPU 和内存资源，此时简单查询也需要进行资源管控。为适应更多的使用场景，短查询加速功能支持开启和关闭：
开启短查询加速：简单查询在 CN 进行管控，复杂查询在 CCN 管控；
关闭短查询加速：不区分简单查询和复杂查询，所有查询均在 CCN 进行管控。
为了便于区分，我们将 CN 管控称为快车道，CCN 管控称为慢车道。快车道只在 CN 上进行并发控制，不支持内存和 CPU 管控；慢车道在 CCN 上进行并发和内存控制，同时支持 CPU 管控。其中，快车道并发对应资源池 max_dop 参数，慢车道并发对应资源池 active_statements 参数，慢车道内存对应资源池 mem_percent 参数。
1.3.2 CPU 资源管控
GaussDB(DWS)基于 cgroups 实现了两种 CPU 管控能力：基于 cpu.shares 的共享配额管控和基于 cpuset 的专属限额管控。
专属限额限制资源池内作业可以使用的 CPU 核，隔离更为彻底，用于防止低优作业占用过多 CPU，影响高优作业性能。
共享配额仅在 CPU 繁忙时生效，不同资源池之间按照配额比例轮询占用 CPU，不同业务之间存在 CPU 争抢，可能影响业务性能。
1.3.3 网络管控（821 以上版本支持）
GaussDB(DWS)支持基于 SP+DWRR 算法的网络调度与基于令牌桶的网络流控，实现资源池之间按比例的网络调度的同时，实现了网络欠佳 SQL 的降级与流控。
1.3.4 空间管控（非本文重点）
空间管控主要有两层目的：一是防止磁盘满，一是对业务使用磁盘空间进行限制。GaussDB(DWS)支持以下空间管控能力：
数据库只读：CM 每 10 分钟检测一次数据盘使用率，使用率超过阈值时，设置数据库只读；使用率低于阈值时，解除数据库只读。数据库只读情况下，只允许只读作业执行。数据库只读后，通过读写事务内执行 DROP/TRUNCATE 清理磁盘空间： " START TRANSACTION READ WRITE;DROP/TRUNCATE TABLE;COMMIT; "。
用户空间管控：限制用户在单个 CN/DN 上可以使用的空间上限，根据表的属主（owner）进行管控，而不管执行插入的用户是谁。相关语法：CREATE ALTER USER xxx PERM SPACE ‘xxx G/M/K’。
Schema 空间管控：提供 Schema 级别的单实例空间管控能力，相关语法：CREATE/ALTER SCHEMA xxx WITH PERM SPACE 'xx G/M/K'。
1.3.5 异常规则
异常规则用于预防单个作业占用资源过多、执行时间过长，防止单个作业长时间大量占用资源，导致系统整体吞吐下降、影响其他作业性能。GaussDB(DWS)支持以下异常规则：
1.3.6 查询过滤器
GaussDB(DWS)查询过滤器提供查询过滤功能，对加入黑名单的作业进行过滤，禁止执行。主要应用场景包含以下两种：
异常熔断机制：配置异常规则后，作业频繁触发异常规则，对于触发异常规则次数达到阈值的查询自动加入黑名单进行过滤。
紧急拦截：作业引发 CORE、hang 或性能大幅下降等问题时，需要紧急规避时，可以将作业加入黑名单进行过滤。
1.3.7 资源管理计划
用户在不同时间需要重点保障的业务可能不一样，每个业务所需的并发和资源在不同时间段也可能不相同，因此用户在不同时间所需的资源管理配置可能就有所不同。资源管理计划支持在指定时间自动切换资源管理配置，用户可按需创建多个资源管理计划。创建资源管理计划、配置计划生效时间并启动计划后，GaussDB(DWS)将在计划生效时间自动切换资源配置。
1.4 能力边界（注意点）
首先，需要明确的一点是资源管理不是万能的，并不是所有的资源类问题资源管理都能解决，大部分资源不足类问题资源管理基本都解决不了。 其次需要清楚资源管理有两个主要目的：其一是为了避免资源的无序使用，从而防止系统级故障的发生，同时避免查询堆积的情况出现；其二是为了实现业务之间的资源隔离，防止不同业务之间因为资源争抢而导致高优业务性能下降，从而影响高优业务的 QoS。明确了以上几点，我们再来看资源管理能干什么、不能干什么，可能就更好理解了：
资源管理可以对业务并发进行限制，实现流量削峰。但是限制并发也就意味着吞吐量的下降，如果业务并发持续走高，限制并发可能导致业务运行不完，不限制并发又会影响其他业务，此时可能就需要考虑其他方法提升业务性能（扩容/升配/SQL 优化）。
资源管理并不能提升系统整体吞吐量，相反，资源隔离很有可能降低系统整体吞吐。例如：应用资源管理前，CPU 持续飙高在 90%以上，查询堆积严重，业务运行不完。这种情况下对低优业务进行 CPU 限额隔离后，很有可能可以大幅降低 CPU 使用率；但是相应的低优业务可能大面积报错或无法完成。
资源管理可以实现资源隔离与管控，但是相较于无背景压力，隔离管控后业务性能可能还是有所损耗。例如：有些用户只对低优业务进行了 CPU 限额管控，而没有对高优业务进行 CPU 管控。此时高优业务和低优业务很可能使用相同 CPU，此时 CPU 使用率可能不到 100%、甚至不足 90% 。但是相对无背景压力，同一时刻请求同一 CPU 的线程会更多，因此 CPU 调度时延也就越大。想要完成隔离 CPU 对性能的影响，需要对两个业务都进行 CPU 限额管控，但是进行限额管控后，相对无背景压力使用所有 CPU 性能可能也是有所下降的，此处不再展开。
资源管理并不能提升作业性能。有些用户业务并发大、资源需求高，但是系统资源却很少。业务串行可能都难以正常运行结束，此时想通过资源管理保障业务正常运行，基本是不可行的，最好的办法还是扩容/升配/SQL 优化。
二、应用示例
2.1 确认业务场景
资源管理的目的是对业务进行隔离管控，因此设计资源管理方案前，首先需要确认用户业务场景：业务分类、业务优先级、业务类型、业务并发情况、业务执行时间段以及业务高峰时间段。
确认业务分类，才能确定应该划分几个资源池；
确认业务优先级，才能确定应该给哪个资源池多预留资源和并发；
确认业务并发和业务类型，才能确定是否需要进行并发控制和异常规则；
确认业务执行时间段，才能确认是否需要使用资源管理计划；
确认业务高峰时间段，才能确认预留多少资源和并发合适。
为了避免过多的资源池对整体吞吐率产生负面影响，同时为了简化资源管理方案，建议将资源池数量控制在 5 个以下，最好是 3 个及以下。如果业务分类较少（3 个及以下），可以为每个业务分类创建一个资源池，以便更好地进行分类管理。如果业务分类较多，可以将优先级相同的业务归为同一类，并使用同一个资源池来管理。
业务优先级一般分为以下几类：
性能敏感的高优业务：该类业务一般执行时间短、业务并发不大，对性能非常敏感，一般不接受性能抖动；
无时效性要求的低优业务：该类业务对执行性能没有要求，一般只要能出结果就行，包括但不限于：外围应用查询、自助分析业务等；
其他有一定性能要求的业务：该类业务普遍并发较大、执行时间较长，对性能有一定要求，但是可以有性能抖动，比如：标准报告、实时入库等。
2. 2 明确管控诉求
确认业务场景后，下一步就需要和用户明确管控诉求。第一步确认业务场景后，其实已经可以形成初步资源管理方案，比如：应该创建几个资源池、限制低优业务并发和资源使用（限额）、是否使用资源管理计划等。
示例：
业务场景：用户业务包含：入库、查询和外部接入。其中入库和查询使用同一用户(user1)，外部接入使用一个用户(user2)；入库优先级略低于查询且入库不能影响查询性能，外部接入优先级很低、接受报错和长时间不出结果；入库并发较大、消耗 CPU 较高。
对于以上业务场景，有以下基本诉求和初步资源管理方案：
有三类业务且优先级各不相同，且各业务间有隔离管控诉求，因此需要创建 3 个资源池；
所有业务全部使用自建资源池，资源池进行并发控制，因此单 CN 并发上限（max_active_statements）可以设置一个较大值（建议 300/500）；
外部接入优先级低，因此考虑外部接入并发设置小一些，CPU 核分配少一些，同时考虑到对其进行严格的 CPU 管控，因此关闭短查询加速；
入库和查询使用同一用户，因此需要用到 query_band 负载识别，用于区分入库和查询业务；
入库优先级略低于查询且入库不能大幅影响查询性能，因此考虑对入库和查询均进行 CPU 限额管控，同时关闭短查询加速；
查询估算内存可能存在偏差，当估算过大时可能导致异常排队，因此建议设置查询估算内存上限。
初步资源管理方案资源池配置如下：
单 CN 并发上限：max_active_statements = 300/500 ??
其中，参数值后有“??”的表示参数大小为初步预估，需要与用户沟通确认参数最终大小。
形成初步资源管理方案后，与用户针对资源管理方案进行讨论，确认管控诉求：
资源池：确认资源池数量是否合适，业务与资源池对应关系是否合适（可能存在多个业务对应一个资源池的情况）；
并发控制：各业务是否需要并发控制，并发上限是否合适；（资源管理上线前并发上限较难预估，一般前期会给一个比较大的值，后续上线后根据实际运行效果调整）
内存管控：业务是否需要内存管控，内存大小设置是否合理；（内存资源充足、业务间内存争取不严重的场景下不需要内存管控；内存设置过小，内存管控可能导致不必要的排队，影响系统吞吐）
查询估算内存限制：可以通过 TopSQL 历史记录中作业估算内存和实际使用内存判断是否合理；（估算内存上限设置过小可能影响作业性能，设置过大可能因为估算偏差导致异常排队，需要综合业务性能和内存使用情况考虑）
CPU 管控：通过资源管理上线前，CPU 使用率情况确认是否存在 CPU 瓶颈，同时确认后续是否有新业务上线；（存在 CPU 瓶颈或者后续可能上限大批新业务情况下建议提前配置好 CPU 管控，预防业务上线后大幅影响高优业务性能）
资源管理计划：业务高峰时间段不同的情况下，可能需要用到资源管理计划，在不同时间段重点保障不同业务；
其他管控诉求：确认用户是否有其他管控诉求，比如：设置异常规则，防止查询堆积和资源争抢严重（虽然进行了资源隔离，但是烂 SQL 可能影响本业务内其他作业）。
以上只是列举了常见的管控诉求讨论点，实际应用中可以多发散。
三. 配置资源管理
以上一章节中资源管理方案为例，说明如何配置资源管理方案。
3.1 配置资源池
如下图所示，以 respool_select 资源池为例，按照用户指南添加资源池中步骤添加资源池。名称填写“respool_select”；CPU 资源选择专属限额，限额 50%；内存资源限额 50%；查询并发（特指慢车道并发）上限 100。填写完成后点击确认，完成资源池添加。资源池操作说明详见：添加资源池、修改资源池、删除资源池。
添加资源池完成后，显示下图所示界面。刚刚配置完成的参数在资源配置标签内显示；短查询加速默认开启且不限制简单语句并发上限；中间位置显示资源池关联的异常规则，默认情况下关联有两个默认异常规则：单 DN 平均消耗 CPU 占比不超过 50%，单 DN 算子下盘不超过数据盘的 1/10，超过限制后作业报错退出；最下方显示资源池关联的用户，点击关联用户按钮将“查询用户”关联至该资源池。同理创建另外两个资源池，并将“外部接入用户”关联至 respool_other 资源池。
注：对于需要设置自定义异常规则的资源池，在下方异常规则标签栏点击编辑即可配置异常规则。
3.2 短查询加速配置
在资源池下拉列表中选择刚刚添加的资源池 respool_select，点击短查询配置右上方的编辑，修改简单语句并发为 150，修改完成后点击保存。
对于另外两个资源池，需要关闭短查询加速，在资源池下拉列表中选择对应资源池后，点击短查询配置中“短查询加速”开关，关闭短查询加速。
3.3 查询估算内存设置
查询估算内存上限暂时还不支持在界面配置，可以通过 DAS 执行 SQL 直接修改：
3.4 配置 query_band
1. 修改用户入库业务，入库业务会话内设置 query_band：SET query_band='Jobname=upsert';--执行业务;--作业执行完重置 query_band：reset query_band;示例：
2. 配置 query_band，将入库业务路由至资源池 respool_upsert 运行：
3. 查询 pg_queryband_action 视图，确认 query_band 配置成功：
4. 运行入库作业过程中，查询 TopSQL 实时视图，确认 query_band 是否生效
3.5 其他配置
1. 需要使用资源管理计划的，可以参考资源管理计划操作配置资源管理计划。
2. GaussDB(DWS) 8.2.1 及以上版本支持网络资源管控，假设三个资源池网络带宽权重配比为 respool_select:respool_upsert:respool_other = 5:4:1，使用 DAS 执行以下 SQL 配置网络管控：
配置示例参见下图：
假设外部接入业务运行超过 20min，且网络带宽占用超过 128MB 降级：
配置示例参见下图：
版权声明: 本文为 InfoQ 作者【华为云开发者联盟】的原创文章。
原文链接:【http://xie.infoq.cn/article/dd9b1feb0ed9192601ade5970】。文章转载请联系作者。
提供全面深入的云计算技术干货 2020-07-14 加入
生于云，长于云，让开发者成为决定性力量
评论