【实录】首次利用GPCC历史数据调优Greenplum 第一部分

数据库性能分析和优化是一个难题，笔者所在的Greenplum研发部门近期正好在解决一个实际用户的全局性能问题，本文记录了分析过程和解决思路。本案例是第一次对实际客户的生产库以GPCC历史数据为核心剖析性能问题，所以有必定的开创性和借鉴意义，故撰文供研发同事、现场工程师、支持工程师参考，同时也适合具有必定GP基础并但愿提升的读者阅读。同时为了保护客户的商业秘密，本文不透露任何关于该商业用户的名称、行业等信息，并对数据中的缩写、表名等敏感信息都进行了脱敏处理。

客户在2019-09-22执行了从 GP4.3 到 GP5.20 的升级，随后在10月中旬提出升级后总体性能降低的问题 “overall performance degrade after upgrade” 。现场工程师提出了包括ANALYZE、VACUUM等合理建议，同时售后支持和研发着手分析性能问题。

该客户升级先后都使用了GPCC，GP4.3使用了GPPerfmon+GPCC3的组合，GP5.20使用的是GPCC4.8 (截止发稿时4.9版本已经发布，请使用最新版本)，并正确开启了历史数据收集（参见博文如何开启）。在支持人员的协助下，咱们得以得到升级先后的相关历史数据。

GPCC的历史数据主要包括系统性能信息和查询历史，后文会结合分析过程详细展开。

该部分历史数据很是庞大，仅9月22日升级后到十月中旬几周内，GPCC 4.8就记录了1.5亿次查询。面对overall performance这一模糊的课题，咱们要想真正帮到客户，就须要让这些数听说话。

第一部分，了解GPDB集群的总体性能特征

先介绍GPCC的系统性能历史表

这个表的定义从GPPerfmon到GPCC4.8变化不大，在GPPerfmon时表明名为public.system_history，GPCC4之后为gpmetrics.gpcc_system_history。

GPCC运做时会每分钟四次（分别在00秒、15秒、30秒、45秒）对GPDB集群的每一个主机（包括Master、Segment和Standby Master）采样上面所列信息，做用是掌握用户数据库的总体负载情况，能够帮助咱们回答诸如如下几个问题：

• 用户的系统负载高不高
• 什么时间段负载最高，是否呈现按小时、天、周的规律
• CPU和DiskIO是否用满，谁是瓶颈
• 系统负载是否随时间推移愈来愈高（性能退化）

咱们使用下面查询来分析一周内的系统资源变化状况

SELECT
   ctime::date || '_' || CASE WHEN extract(hour from ctime) < 10 THEN '0' ELSE '' END || extract(hour from ctime) AS date_hour
 , avg(cpu_sys) AS cpu_sys
 , avg(cpu_user) AS cpu_user
 , avg(cpu_sys+cpu_user) AS cpu
 , avg(mem_total) AS mem_total
 , avg(mem_used) AS mem_used
 , avg(mem_actual_used) AS mem_actual
 , avg(load0) AS load0
 , avg(load1) AS load1
 , avg(load2) AS load2
 , avg(disk_rb_rate) / 1024 / 1024 AS disk_R_MBs
 , avg(disk_wb_rate) / 1024 / 1024 AS disk_W_MBs
 , avg(net_rb_rate) / 1024 / 1024 AS net_I_MBs
 , avg(net_wb_rate) / 1024 / 1024 AS net_O_MBs
FROM
   gpmetrics.gpcc_system_history
WHERE
   hostname LIKE 'sdw%'
AND ctime >= '2019-10-09 00:00:00'
AND ctime < '2019-10-16 00:00:00'
GROUP BY 1
ORDER BY 1
;

• 因为每一个主机都会被采样，这里咱们更关心Segment的负载，所以在WHERE条件上过滤掉了MASTER。也能够根据须要反过来观察MASTER或单个主机上的性能指标。
• 这里咱们更关心每一个小时的平均值，所以多采用avg()，实际应用中还能够根据须要活用max(), min(), rank()等分析角度。

取得的结果咱们能够导入到 Excel、Grafana、Tableu 等办公软件进行图形化的对比。下图是对客户升级先后各取一周时间的样本，重叠到一块儿观察变化趋势。

剖析

• 总体来看CPU处于很是繁忙状态、全天（周）都处在平均70%以上
• 图中能够看出GP4时代用户天天有一段时间作维护（ANALYZE、VACUUM）致使系统态CPU出现峰值。GP5以后没有天天作。与用户自述一致。
• GP5以后总体CPU比GP4低几个百分点，这个比较复杂，有多是GP5优化更好，也多是计算资源不能充分利用，引发查询变慢，尚不明确。
• 内存方面，升级先后系统总内存没变。进程占用的内存先后无太大变化。
• 大部份内存被用做Buff+Cache，这是PostgreSQL特性，无异常。
• Load也表现出GP5略低于GP4，与CPU下降相通，尚不明确。
• 系统总体负载没有明显变化趋势，因此基本排除升级后9月22日到10月中旬期间用户人为引入额外工做负载带来总体性能降低的可能。（后续其余分析佐证）

剖析

• 磁盘IO对比差别明显，GP5的IO大幅增长。
• 网络IO一样提示GP5的开销增大了。

初步诊断用户升级GP5以后磁盘IO/网络IO增长的确存在潜在的性能问题，咱们列举出如下一些可能性。

1. 用户升级后跑的查询个数是否变多了？（见下面第二部分）
2. 表里的数据行数是否变多了？（见下面第三部分）
3. 查询的执行计划是否变差了？（见下面第四部分）
4. GP5的执行器、BufferPool等内核组件是否有bug？

针对这些怀疑，咱们须要进一步查证用户的查询负载。

（未完待续）

得到更多关于Greenpum的技术干货，请访问Greenplum中文社区网站。

---