一文详解GaussDB（DWS）的并发管控和内存管控

　　本文分享自华为云社区《GaussDB（DWS）并发管控内存管控云社区华为云》，作者：fighttingman。1背景
　　这里将并发管控和内存管控写在一起，是因为内存管控实际是通过限制语句的并发达到内存管控的目的的。内存管控是基于语句的估算内存的前提下进行管控的，通俗的说就是语句有个估算内存，当资源池的剩余内存小于语句的估算内存时，这个语句就会排队等待，等资源池内的语句执行完，资源池有足够的剩余内存的时候，才会让这个语句执行。所以内存管控的实际效果和语句的估算内存有很大关系，估算的大了就会造成大量语句排队，实际没有使用那么多内存，造成内存资源浪费，相反估算的小了，就会有很多语句下发，实际内存使用就会变多，就有语句报内存不足的错误风险。
　　数据库系统的并发控制，在整个系统中起着很重要的作用，比如很多用户的业务压力过大时，有时会导致连接数量被占满，有时会导致某种计算资源被占满，有时会导致存储空间被占满，这些情况都会导致整个集群进入异常甚至不可用的状态：正在执行的作业互相争抢CPU，会导致大家都不能好好执行；大量作业执行时，占用大量内存，很容易触发到内存瓶颈，造成作业内存不可用问题，导致业务报错等等。在不进行并发控制的情况下，这些情况都很可能会出现，影响到正常业务。2总体介绍
　　DWS的负载管理分为两层，第一层为cn的全局并发控制，第二层为资源池级别的并发控制。在通过第一层控制的时候，会继续向前走到第二层资源池控制，根据资源池当前的负载资源情况决定作业继续执行或者排队。
　　基于DWS并发控制逻辑看出，实际作业执行中，可能会在两种队列中排队：
　　一种是全局队列（globalqueue）这种队列不区分简单和复杂作业，也不区分是DDL或者是普通语句，这种是每个cn生效。
　　一种是资源池队列（resourcepoolqueue），用户下发的一般语句会根据资源消耗估算以及复杂程度在这里进行判断是否排队。
　　在两层队列的过滤下，DWS会筛选出当前能执行的语句，使其正常运行，运行时也会受到其所属资源池资源的限制（只能使用资源池配置的CPU、内存、IO配额）。3全局排队
　　这里介绍几个常用视图以及SQL语句，可以迅速判断目前的业务出现问题的原因，受限根据以下视图可以看到目前的作业是不是在排队，之后要迅速分析为什么在排队，是因为负载管理各个参数配置问题，还是因为正在执行的语句占据了过多的资源导致的排队。
　　pgxcstatactivity（活跃视图）
　　查询当前执行时间最长的语句的排队状态，queryid（数据库中作业的唯一标识），以及详细的语句信息。
　　选择coorname，usename，currenttimestampquerystart作为持续时间，排队，queryid，从pgxcstatactivity查询，其中stateactive和usenameRuby顺序按持续时间说明；
　　根据该语句可以迅速判断出哪些语句执行时间很长，是什么样的语句执行很慢以及该语句的queryid，便于迅速进入下一步排查。
　　该视图中enqueue字段中如果显示正在等待全局队列就代表在全局排队。全局排队是受GUC参数maxactivestatements参数控制的，是单cn生效的，也就是每个cn都可以支持这么大的并发量。比如集群中有3个cn实例，GUC参数maxactivestatements参数设置为60，也就是说每个cn都支持60个语句并发执行，集群全局支持360180并发执行作业。当下发作业大于这个cn设置的maxactivestatements的时候就会进行全局排队，在pgxcstatactivity视图中enqueue字段就会显示等待全局队列。4资源池排队4。1静态负载管理
　　当GUC参数enabledynamicworkload设置为off的时候就代表是静态负载管理模式。静态负载管理的情况下，pgxcstatactivity视图中enqueue字段只会有waitinrepoolqueue。并发控制参数为资源池的maxdop（简单作业）和activestatements（复杂作业）。
　　1）简单作业和复杂作业的定义
　　在静态负载管理中，简单作业是估算代价成本值小于GUC参数parctlmincost值的作业。反之则判定为复杂作业。该GUC参数默认为10W，
　　当parctlmincost为1时，或者作业估算成本小于10时，作业都判定为简单作业。
　　2）简单作业并发限制ALTERRESOURCEPOOLresourcepoola1WITH（maxdop10）；
　　通过设置资源池的maxdop参数设置简单作业并发，关联资源池resourcepoola1的用户都受到这个参数的控制。当所有关联这个资源池的用户的所有作业数量之和大于这个参数的时候，就会进行资源池排队，活跃视图enqueue字段就会显示正在等待的respoolqueue。
　　3）复杂作业并发限制ALTERRESOURCEPOOLresourcepoola2WITH（activestatements10）；
　　通过设置资源池的activestatements参数控制复杂作业的并发数，关联资源池resourcepoola2的用户都受到这个参数的控制。当MEMPERCENT参数数值为0时，ACTIVESTATEMENTS为x（1INTMAX），该资源池上的作业并发数不大于x。当ACTIVESTATEMENTS参数数值为1且MEMPERCENT为正值时，并发由运行作业的内存估值和MEMPERCENT的取值决定。当MEMPERCENT参数数值为正值且ACTIVESTATEMENTS为x（1INTMAX）时，并发由运行作业的内存估值和MEMPERCENT的取值决定，且并发不能大于x。当MEMPERCENT参数数值为0且ACTIVESTATEMENTS为1时，资源池并发不受限。
　　资源池使用并发点数的计数方式来计算可执行的复杂作业并发数量，并发点数计算公式为
　　作业使用内存点数：activepoints（querymemrespoolmem）activestatements100
　　作业使用并发点数：activepoints100
　　资源池总点数：totalpointsactivestatements100
　　单位点数：100
　　4）相关说明资源池分快慢车道，快车道管控简单作业，慢车道管控复杂作业MAXDOP对快车道并发进行限制，取值范围为1INTMAX，默认为1，表示不管控。ACTIVESTATEMENTS取值范围为1INTMAX，默认值为10，建议使用该默认值。当取值设置为0或者1时，慢车道并发不受ACTIVESTATEMENTS限制。MEMPERCENT取值范围为0100，当取值设置为0时，慢车道并发不受MEMPERCENT限制。慢车道并发受ACTIVESTATEMENTS和MEMPERCENT限制，同时点数由ACTIVESTATEMENTS决定。当ACTIVESTATEMENTS1或0时，totalpoints90。totalpoints点数耗尽后，慢车道查询会触发排队操作，队列满足先进先出。querymem为优化器估算的作业内存大小，即PGSESSIONWLMSTAT视图中的statementmem；作业无估算内存数值时，不进行并发控制。respoolmem为资源池的实际内存。4。2动态负载管理
　　当GUC参数enabledynamicworkload设置为on的时候就代表是动态负载管理模式。动态负载管理的情况下，pgxcstatactivity视图中enqueue字段会有在重新队列中等待和在全局队列中等待。
　　1）简单作业和复杂作业的定义
　　动态负载管理下优化器估算内存大于32M认为是复杂作业，反之认为是简单作业。
　　运行中的作业复杂简单情况可以通过PGSESSIONWLMSTAT中的attribute字段查看。
　　2）动态负载管理相关说明集群有一个CN会作为中心协调节点（CCN），用于收集和调度作业执行，该节点可以通过cmctlquerycv查询到，CentralCoordinatorState会显示其状态。当CCN不存在时，作业不再受动态负载管理控制。CCN上包含全局内存管控队列和资源池队列，目前暂不支持跨队列优先级，在以下场景下优先级低的作业可能优先下发：如果优先级高的作业在全局内存管控队列排队，优先级低的作业在资源池队列排队，则优先级低的作业会优先下发。单CN上依然受到maxactivestatements参数限制，但不是强制限制，实际运行的作业可能稍微大于该数值。简单查询作业（估算值32MB）、非DML（即非INSERT、UPDATE、DELETE和SELECT）语句，不走自适应负载，需要通过maxactivestatements来进行单CN的上限控制。默认workmem数值为512MB，在自适应负载特性下，该数值不能变大，否则会引起内存不受控（例如未做Analyze的语句）。作业估算内存小于等于0时，如果强制将作业指定为慢车道管控，作业不会发往CCN管控将直接运行。以下场景或语句由于内存使用特殊性和不确定性，可能导致大并发场景内存不受控，如果遇到需要降低并发数。单条元组占用内存过大的场景，例如，基表包含超过MB级别的宽列。完全下推语句的查询。需要在CN上耗费大量内存的语句，例如，不能下推的语句，withholdcursor场景。由于计划生成不当导致hashjoin算子建立的hash表重复值过多，占用大量内存。包含UDF的场景，且UDF中使用大量内存的场景。
　　3）短查询加速（默认开启，建议开启）
　　混合负载场景下，复杂查询可能会长时间占用大量资源，虽然简单查询执行时间短、消耗资源少，但是因为资源耗尽，简单查询不得不在队列中等待复杂查询执行完成。为提升执行效率、提高系统吞吐量，GaussDB（DWS）的短查询加速功能，实现对简单查询的单独管理。开启短查询加速后，简单查询与复杂查询分开管理。关闭短查询加速后，简单查询与复杂查询执行相同的工作负载管理。
　　虽然单个简单作业资源消耗少，但是大量简单作业并发运行还是会占用大量资源，因此短查询加速开启情况下，需要对简单查询进行并发管理；资源管理可能会影响查询性能，影响系统吞吐量，因此简单查询不进行资源管理，异常规则也不生效。
　　设置方法：通过GUC参数wlmqueryaccelerate设置通过资源池alterResourcePoolquerypoolwith（shortaccf）；4。3资源池内存管理
　　资源池的内存管理是基于语句的估算内存进行管理的。
　　1）资源池可用内存设置方法ALTERRESOURCEPOOLresourcepoola1WITH（MEMPERCENT20）；当MEMPERCENT参数取值设置为0时，表示查询作业的内存不受限。当MEMPERCENT参数取值设置为x（1x100）时，表示设置资源池使用的内存大小为可用内存大小的x，查询作业将使用给定的内存来运行。
　　2）资源池作业估算内存限制设置方法ALTERRESOURCEPOOLresourcepoola1WITH（MEMORYLIMIT300MB）；当MEMORYLIMIT参数取值设置为unlimited时，表示作业内存受数据库内存限制。当MEMORYLIMIT参数取值设置为default时，表示作业内存限制为资源池内存的12。当MEMORYLIMIT参数取值设置为xkBMBGB时，表示作业内存限制为xkBMBGB。当memorylimit配置小于256M时，为防止估算内存过小导致问题，作业估算内存上限为256MB。5资源管理相关视图
　　GaussDB（DWS）对外提供诸多系统视图，可以用来辅助资源管理及资源使用相关问题的分析定位，常用视图及用法说明如下表所示。（代表常用程度）
　　除过上述常用视图，资源管理问题定位过程需要根据实际场景，结合实例日志、集群状态等共同分析定位。6推荐配置
　　因为并发的配置和业务的复杂程度和集群的规格配置有很大的关系，本推荐仅做参考。推荐基于3CN12DN，每个dn实例最大可使用64G内存情况下推荐的
　　在813内核版本及以上版本推荐配置如下。
　　GUC参数：maxactivestatements60（每个cn的最大并发数，控制全局队列排队）enabledynamicworkloadon（开启动态负载）wlmqueryaccelerate1（开启短查询加速）
　　资源池参数：将资源池resourcepoola1更改为（MAXDOP50）（简单作业数50并发）将资源池resourcepoola1更改为（activestatements10）（复杂作业10并发）7并发控制常用定位方法及解决措施7。1排队问题
　　出现业务阻塞、性能下降、查询无响应等类似现网问题时，通过以下方法可以排查是否排队问题并定位排队原因，同时根据排队原因给出相应规避措施。7。1。1确认是否排队
　　首先确认是否排队问题，其次排查排队原因，确认是否属于正常排队：813及以上版本查询资源池监控视图selectrpname，slowrun，slowwait，slowlimit，usedcpu，cpulimit，usedmem，estimatememfromgsrespoolresourceinfo；老版本查询作业负载视图selectresourcepool，attribute，lane，status，enqueue，sum（statementmem）asstmtmem，count（1）frompgxcsessionwlmstatwherestatus！finishedandattribute！Internalandusename！Rubygroupby1，2，3，4，5；
　　通过视图可以获取到各资源池快慢车道作业运行信息，据此可以判断是否排队问题：
　　如果有作业处于排队状态，则可能是排队导致的问题，否则排除排队问题；可能的排队原因包括：单CN全局并发排队；快车道并发排队；静态慢车道并发排队；静态慢车道内存排队；动态CCN全局内存排队；动态CCN慢车道并发排队；动态CCN慢车道内存排队。
　　排查排队原因
　　常见排队原因及解决措施
　　1）全局并发排队
　　单CN实际运行作业数全局并发上限，则全局并发排队正常；
　　单CN实际运行作业数长时间小于全局并发上限，则可能存在计数泄露。
　　2）快车道排队
　　快车道实际运行作业数快车道并发上限，则快车道并发排队正常；
　　快车道实际运行作业数长时间小于快车道并发上限，则可能存在计数泄露。
　　3）静态慢车道排队
　　慢车道实际运行作业数慢车道并发上限，则慢车道并发排队正常；
　　慢车道实际运行作业累计估算内存慢车道内存上限，则慢车道内存占用达到上限导致排队，关注是否有查询估算内存过大；
　　如果慢车道并发和内存占用长时间达不到上限，则可能存在计数泄露。
　　4）动态CCN排队
　　如果查询在CCN排队，则需要查询CCN开发者视图确认排队原因：
　　selectfrompgstatgetworkloadstructinfo（）；
　　CCN上可能的排队原因：CCN全局可用内存不足导致排队，此时需特别关注是否有查询估算内存过大；资源池实际运行作业数慢车道车道并发上限，资源池并发上限，正常排队；资源池实际运行作业累计估算内存慢车道内存上限，则慢车道内存占用达到上限导致排队，此时需特别关注是否有查询估算内存过大；资源池实际运行作业数或占用内存与记账值不符，则可能存在计数泄露BUG；队首作业在CCN哈希中不存在，说明队首作业残留导致查询不能正常下发；CNCCN处于recover状态或收集DN内存信息失败（多CCN）导致所有查询等待5s下发，现象为所有查询排队时间均为56s。8常见案例8。1CCN排队
　　1）查询资源池监控视图，确认是否正常排队（813及以上版本）
　　下面以单CN下发作业为例，多CN下发作业需查询pgxcrespoolresourceinfo视图。selectrpname，slowrun，slowwait，slowlimit，usedcpu，cpulimit，usedmem，estimatememfromgsrespoolresourceinfo；如果slowwait不等于0，说明有查询在CCN排队，否则无查询排队；如果slowrun大于等于slowlimit，说明达到慢车道并发上限导致排队，否则说明不是并发过大导致排队；如果estimatemem大于资源池内存上限，说明内存不足导致排队，否则说明不是内存不足导致排队；如果usedmem长时间远小于estimatemem，说明该资源池上运行作业估算内存过大，可以尝试analyze；如果usedmem大于estimatemem，则查询可能触发内存二次扩展（默认资源池）或查询内存不可控；如果usedcpu长时间接近甚至大于等于cpulimit，说明资源池分配CPU过少，可能导致作业大量堆积；
　　通过该查询可以直观的观察各资源池作业负载信息，如果资源池running作业并发、内存长时间无法达到资源池上限，则考虑是否存在排队异常。
　　2）查询作业负载视图（813以下版本）
　　813及以上版本建议使用上边方法确认是否有排队异常，当然也可以使用以下方法确认存在排队异常，排除特性BUG影响。
　　813以下版本仅有pgsessionwlmstat视图，没有pgxc视图，可通过以下语句创建临时pgxc视图：CREATEORREPLACEVIEWpgxcsessionwlmstattpASSELECTFROMpgcatalog。pgxcparallelquery（cn，SELECTpgcatalog。pgxcnodestr（），FROMpgcatalog。pgsessionwlmstat）AS（nodenamename，datidoid，datnamename，threadidbigint，processidinteger，usesysidoid，appnametext，usenamename，prioritybigint，attributetext，blocktimebigint，elapsedtimebigint，totalcputimebigint，cpuskewpercentinteger，statementmeminteger，activepointsinteger，dopvalueinteger，controlgrouptext，statustext，enqueuetext，resourcepoolname，querytext，isplanaboolean，nodegrouptext，lanetext）；
　　查询集群内各资源池在所有CN上的作业运行、排队统计信息：selectresourcepool，attribute，lane，status，enqueue，sum（statementmem）asstmtmem，count（1）frompgxcsessionwlmstatwherestatus！finishedandattribute！Internalandusename！Rubygroupby1，2，3，4，5；
　　通过该查询可以直观的观察各资源池作业负载信息，如果资源池running作业并发、内存长时间无法达到资源池上限，则考虑是否存在排队异常。
　　确认是否存在排队异常
　　如果经过前两个步骤分析，怀疑可能存在排队异常，可能的原因有以下几种：大批作业一开始运行就报错退出，依靠CCN周期任务完成作业同步和唤醒；CCN全局内存排队导致资源池并发、内存长时间无法达到资源池上限。
　　点击下方，第一时间了解华为云新鲜技术
　　华为云博客大数据博客AI博客云计算博客开发者中心华为云