GaussDB(DWS) 资源负载管理:并发管控以及CPU管控效果实测以及分析说明【这次高斯不是数学家】

举报
Malick 发表于 2022/05/28 14:48:56 2022/05/28
【摘要】 GaussDB(DWS)提供了复杂多样的资源负载管理手段:既可以从单个cn的总并发数限制作业的数量(max_active_statements),也可以创建资源池,对于指定资源池的用户进行并发限制。在资源池上,即可以进行内存、CPU的限制,也可以不进行资源限制。如此多的功能,实际效果如何,应该如何配置,还是要用实测数据来说话。

GaussDB(DWS) 资源负载管理:并发管控以及CPU管控效果实测以及分析说明


背景

​ GaussDB(DWS)提供了复杂多样的资源负载管理手段:既可以从单个cn的总并发数限制作业的数量(max_active_statements),也可以创建资源池,对于指定资源池的用户进行并发限制。在资源池上,即可以进行内存、CPU的限制,也可以不进行资源限制。对于CPU资源的管控,即可以使用指定具体核数的硬限制,也可以使用空闲时按需分配,cpu跑满时按照配比分配资源的软限制。

​ 正因为有这么多的功能配置,才可以让DWS在不同的业务场景中,采取不同的配置方案,维持业务稳定性,保证重要业务的资源使用。

​ 对于如此多的管控功能,管控起来实际的效果到底如何,本篇文章就基于当前最新版本,进行效果实测,并进行一定的分析说明。主要分为以下几个部分:


场景一:并发数限制在资源瓶颈时的作用

​ 所谓资源瓶颈,即CPU、内存、IO、网络其中的一项或者多项达到瓶颈,出现作业之前争抢资源,造成性能大幅下降。对于此类场景,我们日常解决问题时,通常想到的几个办法:

​ 1.降低业务的并发量; 2.抓出消耗资源高的sql语句,令其优化;3.对于耗费cpu高的作业进行资源限制,保障其他作业有足够的资源可以使用。

​ 理论上每个方法都有效果,但是效果如何,并不能简单得说清楚,需要数据来进行一些印证。

环境搭建
  1. 配置:3台物理机,规格:

    os cpu 磁盘 内存
    RedHat 7.4 2*8物理核;超线程 32逻辑核 单盘,大小14T,HDD 94G
    RedHat 7.4 2*8物理核;超线程 32逻辑核 单盘,大小14T,HDD 94G
    RedHat 7.4 2*8物理核;超线程 32逻辑核 单盘,大小14T,HDD 94G
  2. GaussDB(DWS)集群规格:

    版本 cn dn 备注
    GaussDB 8.1.3 3 2*3 1.只使用1个cn;
    2.由于测试物理机都只有一个raid,部署方式为每个节点一个raid,两个dn,共6dn。

    PS:集群的版本对测试结果基本没有影响,各个版本功能规格基本没有变化。

数据构造

测试CPU资源管控对于灵活短查询以及复杂查询的影响,复杂查询采取TPCDS数据和灵活查询采取TPCC数据。此处构造1500x的TPCDS/100xTPCC。

数据来源:

  1. tpcds数据由tpcds工具构造。耗时近一晚上。启动本地gds服务器,创建tpcds相应原表及外表,直接导入。HDD盘,导入性能也较差。

  2. tpcc数据在其余测试数据服务器中有现成数据,直接创建原表外表进行gds导入,100x数据,导入大约10min左右。

测试思路
  1. 找到tpcds中高CPU消耗的语句,测试几个并发能将CPU打满,并且需要运行时间不要过长,避免影响测试效率。
  2. 找到语句后,定好一批作业的并发数,例如整体作业数量为30个,只需4并发就会将CPU打满,那么测试不同的并发控制下,作业性能情况。
  3. 不同并发下第一个完成作业时间由于CPU争抢程度不同,时间都不一样,因此也需要记录下来。
测试数据

说明:tpcds-Q9,在本测试环境1500x数据下,单并发可使物理机cpu达到30%-50%,单并发运行时间在100s左右。;本测试采取Q9*30作为一批作业。控制不同并发数,记录每批的运行情况;4并发时cpu基本已经达到瓶颈,因此本轮测试从4并发开始。

测试结果如下:

max_active_statements 4 8 12 16 20 24 28 30
第一个结束(ms) 244433 472352 702401 932618 1164983 1393876 1623739 1744169
总时间(ms,即最后一个结束) 1847229 1771256 1761520 1750989 1751561 1751296 1760981 1744330
平均运行时间 61574.3 59041.8 58717.3 58366.3 58385.3 58376.5 58699.3 58144.3
load average 89 107 166 244 320 421 433 444
机器CPU情况(us) 97 98.3 99 99 98.9 99 99 99
结论分析
  1. 首先我们绘制一个并发数与整体执行时间,单个执行时间的趋势变化图:

图表如下:

image-20220528114016557

2.图表分析,由上折线图可以看出:

  1. 随着并发数的增加,整体运行时间略微有所提升,说明在CPU瓶颈的情况下,并发数的降低,并不能提升批量作业的整体性能。

  2. 作业整体平均运行时间也比较平稳,平均每个作业运行的时间消耗,在不同并发数下也没有大的差别。

  3. 第一个结束的作业运行时间,在并发数为4的情况下,只有400s+,而在并发数30拉满的情况,达到了1620s+,差距很大,变化趋势基本是随着并发数的增长线性变长。

综合说明

根据测试结论分析,在CPU瓶颈的情况下,限制并发数,实际并不能提升整体运行的性能;但是在不同场景下,可以选择不同的配置策略。

例如:需要有作业及时响应的,可以将并发数限制少一些,这样能保证总有作业能以较快的速度完成;需要整体作业运行性能较快的,根据测试数据,可以将并发数设大,这样整体运行的时间最短。

【这次高斯不是数学家】

https://bbs.huaweicloud.com/blogs/351189

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。