GaussDB(DWS) 资源负载管理:并发管控以及CPU管控效果实测以及分析说明【这次高斯不是数学家】
GaussDB(DWS) 资源负载管理:并发管控以及CPU管控效果实测以及分析说明
背景
GaussDB(DWS)提供了复杂多样的资源负载管理手段:既可以从单个cn的总并发数限制作业的数量(max_active_statements),也可以创建资源池,对于指定资源池的用户进行并发限制。在资源池上,即可以进行内存、CPU的限制,也可以不进行资源限制。对于CPU资源的管控,即可以使用指定具体核数的硬限制,也可以使用空闲时按需分配,cpu跑满时按照配比分配资源的软限制。
正因为有这么多的功能配置,才可以让DWS在不同的业务场景中,采取不同的配置方案,维持业务稳定性,保证重要业务的资源使用。
对于如此多的管控功能,管控起来实际的效果到底如何,本篇文章就基于当前最新版本,进行效果实测,并进行一定的分析说明。主要分为以下几个部分:
场景一:并发数限制在资源瓶颈时的作用
所谓资源瓶颈,即CPU、内存、IO、网络其中的一项或者多项达到瓶颈,出现作业之前争抢资源,造成性能大幅下降。对于此类场景,我们日常解决问题时,通常想到的几个办法:
1.降低业务的并发量; 2.抓出消耗资源高的sql语句,令其优化;3.对于耗费cpu高的作业进行资源限制,保障其他作业有足够的资源可以使用。
理论上每个方法都有效果,但是效果如何,并不能简单得说清楚,需要数据来进行一些印证。
环境搭建
-
配置: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 -
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。
数据来源:
-
tpcds数据由tpcds工具构造。耗时近一晚上。启动本地gds服务器,创建tpcds相应原表及外表,直接导入。HDD盘,导入性能也较差。
-
tpcc数据在其余测试数据服务器中有现成数据,直接创建原表外表进行gds导入,100x数据,导入大约10min左右。
测试思路
- 找到tpcds中高CPU消耗的语句,测试几个并发能将CPU打满,并且需要运行时间不要过长,避免影响测试效率。
- 找到语句后,定好一批作业的并发数,例如整体作业数量为30个,只需4并发就会将CPU打满,那么测试不同的并发控制下,作业性能情况。
- 不同并发下第一个完成作业时间由于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 |
结论分析
- 首先我们绘制一个并发数与整体执行时间,单个执行时间的趋势变化图:
图表如下:
2.图表分析,由上折线图可以看出:
-
随着并发数的增加,整体运行时间略微有所提升,说明在CPU瓶颈的情况下,并发数的降低,并不能提升批量作业的整体性能。
-
作业整体平均运行时间也比较平稳,平均每个作业运行的时间消耗,在不同并发数下也没有大的差别。
-
第一个结束的作业运行时间,在并发数为4的情况下,只有400s+,而在并发数30拉满的情况,达到了1620s+,差距很大,变化趋势基本是随着并发数的增长线性变长。
综合说明
根据测试结论分析,在CPU瓶颈的情况下,限制并发数,实际并不能提升整体运行的性能;但是在不同场景下,可以选择不同的配置策略。
例如:需要有作业及时响应的,可以将并发数限制少一些,这样能保证总有作业能以较快的速度完成;需要整体作业运行性能较快的,根据测试数据,可以将并发数设大,这样整体运行的时间最短。
【这次高斯不是数学家】
- 点赞
- 收藏
- 关注作者
评论(0)