【实录】首次利用GPCC历史数据调优Greenplum 完结篇

了解更多Greenplum技术干货，欢迎访问Greenplum中文社区网站

本文作者Pivotal Greenplum工程技术经理王昊所在的Greenplum研发部门近期在帮助客户解决一个全局性能问题，并通过本文记录了分析过程和解决思路。我们在【实录】首次利用GPCC历史数据调优Greenplum 第一部分中帮助大家了解了GPDB集群的整体性能特征，在【实录】首次利用GPCC历史数据调优Greenplum 第二部分中分析了查询负载整体情况。今天，将为大家带来《首次利用GPCC历史数据调优Greenplum》系列的完结篇——分析数据表行数变化趋势供大家学习讨论。

第三部分，分析数据表行数变化趋势

在第一部分的末尾，我们怀疑的另一个方向就是用户的数据量是否发生了显著的增加。由于数据量增加可以直接导致磁盘IO变多，侧面上也能联系到“整体性能下降”的反馈。

GPCC4.9/6.1即将提供数据表大小的监控和变化趋势历史数据的功能，但撰写本文时，该功能还在研发中，本次客户的数据当然也不包括这些全新历史数据。

但是这并不意味着我们束手无策，这里我们介绍GPCC4.8的第三个历史表：gpmetrics.gpcc_plannode_history。这个表可以记录（1）Master上生成的查询计划树（2）查询执行时每个查询计划节点在每个Segment进程上运行的实际结果。

执行计划节点历史（gpmetrics.gpcc_plannode_history）是GPCC 4.x的新功能，以前的GPPerfmon并没有类似功能。这个表提供的信息非常丰富，因此也需要占用更多空间，为了平衡GPCC目前只对执行时间超过10秒的查询记录完整的计划节点历史。这个表的用途非常多，例如绘制图形化的执行计划树，在以前的介绍文章《新一代Greenplum监控管理平台》里有过介绍。

这里我们借助这个表的信息推算用户数据表大小及变化趋势。我们知道GP执行查询时通过Seq Scan节点进行表扫描；如果扫描节点的条件是空，则说明是一个全表扫描；在此基础上累加所有Segment 上同一扫描节点的输出的行数，即为该表的实际行数。

基于此下面的查询可以统计出所有的全表扫描的结果。

WITH master_nodes (tmid, ssid, ccnt, nodeid, rel_oid, relation_name) AS (SELECT tmid, ssid, ccnt, nodeid, max(rel_oid), max(relation_name)FROM gpmetrics.gpcc_plannode_historyWHERE ctime >= '2019-09-23' AND ctime < '2019-10-17'AND node_type IN ('Seq Scan', 'Append-only Scan', 'Append-only Columnar Scan', 'Table Scan', 'Bitmap Heap Scan')AND condition = '' -- 只统计没有过滤条件的全表扫描AND segid = -1      -- MASTER记录的执行计划过滤出适合的query id + node idGROUP BY tmid, ssid, ccnt, nodeid
),
table_rows (rel_oid, relation_name, hash_name, cdate, row_cnt, scan_cnt) AS (SELECT rel_oid, relation_name, substring(md5(relation_name) FROM 1 FOR 12) tname, ctime::date ctime, round