探讨建立基于应用维度的系统资源的监控与分析

举报
babu1801 发表于 2021/09/27 16:34:52 2021/09/27
【摘要】 一、数据仓库系统资源的监控与规划数据仓库系统的用户通常分为三种角色:管理员,开发人员以及使用人员。不同角色对于系统资源的关注点是不一样的。在实际的客户场景中,即便管理员也是分为平台管理员和应用管理员两个不同的方向。平台管理员:关注的是物理层面的资源使用信息,目的是保证整个平台的稳定性。所以对于系统资源的使用情况自底向上的层次递进关系为:SQL->CN/DN节点->服务器->集群,(如图1)。...

一、数据仓库系统资源的监控与规划

数据仓库系统的用户通常分为三种角色:管理员,开发人员以及使用人员。不同角色对于系统资源的关注点是不一样的。在实际的客户场景中,即便管理员也是分为平台管理员和应用管理员两个不同的方向。
平台管理员:关注的是物理层面的资源使用信息,目的是保证整个平台的稳定性。所以对于系统资源的使用情况自底向上的层次递进关系为:SQL->CN/DN节点->服务器->集群,(如图1)。对于平台管理员来说,业务维度的资源消耗情况不敏感,他们只会聚焦在集群上的总体资源消耗没有达到瓶颈,或是出现异常。通常集群的性能变化分为突变和渐变两种情况。性能突变是由于硬件可能出现故障或者某些应用在一定时段内对于资源的使用出现了非正常的消耗,这些是需要对于问题进行快速定位,分析根因,针对问题采取消解方案就可以解决突变情况。而性能的渐变则是长时间业务的发展,导致集群承载的业务总量在不断增加后,使得整体资源渐渐地不能满足业务总量的资源需求情况下出现的正常发展趋势。平台管理员一方面会推动应用侧进行应用优化,另一方面则会着手准备系统扩容。因此在平台管理者的性能统计报表中,对于系统的实时健康情况和不同维度(节点,服务器到集群)的资源使用变化情况的指标是管理员的侧重点。

图1.png


图1 平台管理员系统资源监控层级图
应用管理员:应用管理员的职责是管理运行在数据仓库平台上的作业、应用的性能。数据仓库平台是整个企业的数据基座,提供了统一的,高质量的整合数据,在这个基础上会进一步开发众多的领域/集市应用,这些应用会对应到不同的团队,部门。所以作为应用管理员,需要了解到按照组织机构,应用模块,甚至是为实现某一个业务目标而开发的作业群组为统计单元的数据库资源消耗情况。这就如同数据仓库是一个大的资源池,不同的开发团队和使用部门都是不同的租户,应用管理员要对不同租户的资源使用情况有所掌握,对于重要的租户分配更多的资源,对于资源消耗大户需要审视资源利用率,降低因为不规范的代码或者查询对于资源的浪费,也需要根据系统的整理压力,采用合理的手段在特定的时间段进行资源的动态分配和管理。这一切管理手段都需要数据库提供能基于应用,基于部门维度的资源使用情况的统计和分析。(如图2)

图2.png

图2 应用管理员系统资源监控层级图

二、GaussDB(DWS)资源监控系统表

2.1 SQL
首先,系统参数enable_resource_track设置为on的情况下(默认为on),系统可以监控到SQL执行代价(优化器估算)大于等于参数resource_track_cost的取值(默认值是100000)的SQL资源情况。(注:特殊场景下,可以监控到operator算子级别)。
实时场景下,通过系统视图gs_wlm_session_statistics和pgxc_wlm_session_statistics可以即时了解到当前正在运行的SQL所消耗的内存、下盘、CPU时间、IO等资源。
已执行完毕的SQL记录会按照如下规则进行记录和归档:当用户SQL执行完成后(包括异常终止等情况),可以通过GS_WLM_SESSION_HISTORY视图获取当前CN完成的SQL的相关统计信息。在参数enable_resource_record设置为on的情况下,每隔3分钟被转储到系统表GS_WLM_SESSION_INFO中进行归档(注:归档的SQL标准是,SQL执行时间不小于参数resource_track_duration的取值,该参数默认值是1min)。
以上的SQL日志可以分别称为实时topsql和历史topsql(注:如果把resource_track_cost和resource_track_duration设置为0,可以近似认为sql日志可以记录所有的DML语句信息,对于重负载的系统需要进一步调节其他相关参数,避免sql日志过于庞大)。
通过Topsql表,可以分析出单条语句的客户端信息(如执行的用户名,登录的客户端地址和工具信息),语句静态信息(SQL语句,开始/结束时间,执行计划,状态等),语句动态信息(执行时长,阻塞时长,CPU时长,内存信息,下盘信息,IOPS等)。进一步可以通过username和application_name来识别用户和应用,并汇总到相应维度上进行统计。

图3.png



2.2 CN/DN
GaussDB DWS提供了监控单个CN、DN实例资源使用状态(包括内存,CPU,磁盘IO,进程物理IO和进程逻辑IO)的系统表GS_WLM_INSTANCE_HISTORY及监控整个集群所有CN/DN的资源使用状态的函数pgxc_get_wlm_current_instance_info。
GS_WLM_INSTANCE_HISTORY与PGXC_NODE表进行关联后,可以进一步汇总得到数据库实例在对应节点的CPU和IO资源使用情况。这个数据可以结合操作系统层面对主机资源的使用情况信息汇总,得到Host级别的资源使用情况的数据。

三、打通应用级别的资源分析路径

GaussDB DWS数据库提供了SQL级别和CN/DN的资源信息,可以满足平台管理的系统资源分析,但是只有SQL级别的资源信息,没有办法建立基于应用的自底向上的各级资源使用指标体系。要实现这一目标,就需要在应用中利用两个参数:application_name和query_band.
3.1 application_name
连接数据库的客户端程序名称。例如gsql提交的SQL,默认值就是gsql,JDBC驱动的客户端提交的SQL,默认值是PostgreSQL JDBC Driver。
在应用程序、SQL脚本中,可以设置application_name的值为sql脚本的名称。这样可以把Topsql表的记录根据application_name进行分组汇总。
3.2 query_band
用于标示当前会话的作业类型,由用户自定义。这个自定义的参数就给予了应用的自由度,通过使用key=value这种方式组合的字符串,可以把很多应用的关键信息透传到SQL Log中,再通过对于query_band字符串的解析提取不同的key值就实现了对于不同的JobGroup,Application甚至是到Dempartment级别的资源汇总统计。从而实现基于应用的层次化资源统计。
建议在实际应用中,application_name对应作业名称,而query_band设置构建基于项目的关键词列表。充分利用query_band参数还能够实现基于query_band的动态负载管理。

四、QUERY_BAND的设计实践
在sql脚本中设置query_band,可以结合项目组的实际需求设置不同的QB规范。这里给出几个实践的例子及其用途作为抛砖引玉。
4.1 设置作业名称及版本号
有些sql的优化不是基于单个sql的,可能会把一个复杂的sql拆分成多个子句,或者建立临时表的方式来进行整体优化。所以考虑到优化效果的分析,就需要统计整个作业的消耗总数。在query_band中设置作业名和版本号,可以通过不同版本的资源消耗数据对比,观察优化手段对于整个作业是否带来提升。
set query_band to 'JOBNAME=customer_history;VERSION=1.0';
根据query_band进行资源汇总示例:
select 
   split_part(split_part(query_band,';',1),'=',2) as job_name,  
    split_part(split_part(query_band,';',2),'=',2) as version
   .....
from xxxxx where xxxxx  group by 1,2 order by 1,2
4.2 设置共享账号的实际用户
对于很多项目组来说, 灵活查询业务往往是多人共享一个数据库账号, 在排查SQL的问题和性能时,通常只能确定到数据库用户和登陆IP. 而具体提交的SQL使用人员来说需要逐个询问和排查,效率较低. 通过在工具连接数据库的驱动配置中,设置初始SQL,就可以把该报表的开发人员及其他相关信息写入query_band,为后续的监控和分析提供便利手段.


4.3 设置JobGroup, Application等信息
在批量脚本中初始化的地方设置query_band参数,可以把JobGroup, Priority, Application, Department。利用此类参数可以把作业分类分组,从业务角度把作业按照群组,业务重要性,集市归属,部门归属等关键词进行设置,后期在分析TOPSQL表资源性质的时候。

4.4 通过queryband实现负载识别和队列内优先级控制
用户根据业务场景可灵活配置query band识别队列.示例:
设置query_band“JobName=abc”关联资源池p1、队列内优先级Rush、次序为1。
gs_wlm_set_queryband_action('JobName=abc','respool=p1;priority=rush',1);
gs_wlm_set_queryband_action
-----------------------------
t
(1 row)

图4.png


五、总结

GaussDB(DWS)的元数据系统中对基于SQL和CN/DN Node的资源消耗设置了相关的信息收集的系统表。在此基础上可以针对SQL级别,Node级别和Host级别进行资源消耗的监控和分析。但在项目中,对于仓库开发人员,数据应用开发人员来说更为关注的是从不同的部门,集市和应用角度出发来了解对系统资源的消耗,针对这种需求,结合数据库query_band的特性,提出了灵活设置query_band参数,把底层的SQL和应用层面的业务信息给结合起来的方式,从而能够实现基于应用维度的系统资源的监控和分析,为数据仓库的集群发展规划,容量规划,性能优化等工作提供了最坚实的数据基础。

想了解GuassDB(DWS)更多信息,欢迎微信搜索“GaussDB DWS”关注微信公众号,和您分享最新最全的PB级数仓黑科技,后台还可获取众多学习资料哦~!

logo.png

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

评论(0

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

全部回复

上滑加载中

设置昵称

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

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

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