细说GaussDB(DWS)复杂多样的资源负载管理手段
对于如此多的管控功能,管控起来实际的效果到底如何,本篇文章就基于当前最新版本,进行效果实测,并进行一定的分析说明。
摘要:对于如此多的管控功能,管控起来实际的效果到底如何,本篇文章就基于当前最新版本,进行效果实测,并进行一定的分析说明。
本文分享自华为云社区《GaussDB(DWS) 资源负载管理:并发管控以及CPU管控效果实测以及分析说明【这次高斯不是数学家】》,作者: Malick 。
背景
GaussDB(DWS)提供了复杂多样的资源负载管理手段:既可以从单个cn的总并发数限制作业的数量(max_active_statements),也可以创建资源池,对于指定资源池的用户进行并发限制。在资源池上,即可以进行内存、CPU的限制,也可以不进行资源限制。对于CPU资源的管控,即可以使用指定具体核数的硬限制,也可以使用空闲时按需分配,cpu跑满时按照配比分配资源的软限制。
正因为有这么多的功能配置,才可以让DWS在不同的业务场景中,采取不同的配置方案,维持业务稳定性,保证重要业务的资源使用。
对于如此多的管控功能,管控起来实际的效果到底如何,本篇文章就基于当前最新版本,进行效果实测,并进行一定的分析说明。主要分为以下几个部分:
- 并发数限制在资源瓶颈时的作用
- CPU限额的实际使用效果
- CPU配额的实际效果,配额CPU与限额CPU的能力对比
场景一:并发数限制在资源瓶颈时的作用
所谓资源瓶颈,即CPU、内存、IO、网络其中的一项或者多项达到瓶颈,出现作业之前争抢资源,造成性能大幅下降。对于此类场景,我们日常解决问题时,通常想到的几个办法:
1.降低业务的并发量; 2.抓出消耗资源高的sql语句,令其优化;3.对于耗费cpu高的作业进行资源限制,保障其他作业有足够的资源可以使用。
理论上每个方法都有效果,但是效果如何,并不能简单得说清楚,需要数据来进行一些印证。
环境搭建
1.配置:3台物理机,规格:
2.GaussDB(DWS)集群规格:
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并发开始。
测试结果如下:
结论分析
- 首先我们绘制一个并发数与整体执行时间,单个执行时间的趋势变化图:
图表如下:
2.图表分析,由上折线图可以看出:
- 随着并发数的增加,整体运行时间略微有所提升,说明在CPU瓶颈的情况下,并发数的降低,并不能提升批量作业的整体性能。
- 作业整体平均运行时间也比较平稳,平均每个作业运行的时间消耗,在不同并发数下也没有大的差别。
- 第一个结束的作业运行时间,在并发数为4的情况下,只有400s+,而在并发数30拉满的情况,达到了1620s+,差距很大,变化趋势基本是随着并发数的增长线性变长。
综合说明
根据测试结论分析,在CPU瓶颈的情况下,限制并发数,实际并不能提升整体运行的性能;但是在不同场景下,可以选择不同的配置策略。
例如:需要有作业及时响应的,可以将并发数限制少一些,这样能保证总有作业能以较快的速度完成;需要整体作业运行性能较快的,根据测试数据,可以将并发数设大,这样整体运行的时间最短。
更多推荐
所有评论(0)