首次利用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版本已经发布，请使用最新版本)，并正确开启了历史数据收集（参见博文如何开启https://greenplum.cn/2019/10/12/how-to-use-gpcc）。在支持人员的协助下，我们得以获得升级前后的相关历史数据。
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)
, 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
GROUP BY 1
ORDER BY 1
;
* 由于每个主机都会被采样，这里我们更关心Segment的负载，因此在WHERE条件上过滤掉了MASTER。也可以根据需要反过来观察MASTER或单个主机上的性能指标。
* 这里我们更关心每个小时的平均值，因此多采用avg()，实际应用中还可以根据需要活用max(), min(), rank()等分析角度。
取得的结果我们可以导入到 Excel、Grafana、Tableu 等办公软件进行图形化的对比。下图是对客户升级前后各取一周时间的样本，重叠到一起观察变化趋势。
CPU与内存性能
剖析
*整体来看CPU处于非常繁忙状态、全天（周）都处在平均70%以上
*图中可以看出GP4时代用户每天有一段时间做维护（ANALYZE、VACUUM）导致系统态CPU出现峰值。GP5之后没有每天做。与用户自述一致。
*GP5之后整体CPU比GP4低几个百分点，这个比较复杂，有可能是GP5优化更好，也可能是计算资源不能充分利用，引起查询变慢，尚不明确。
*内存方面，升级前后系统总内存没变。进程占用的内存前后无太大变化。
*大部分内存被用作Buff+Cache，这是PostgreSQL特性，无异常。
*Load也表现出GP5略低于GP4，与CPU降低相通，尚不明确。
*系统整体负载没有明显变化趋势，所以基本排除升级后9月22日到10月中旬期间用户人为引入额外工作负载带来整体性能下降的可能。（后续其他分析佐证）
磁盘与网络IO
剖析
* 磁盘IO对比差异明显，GP5的IO大幅增加。
* 网络IO同样提示GP5的开销增大了。
初步诊断用户升级GP5之后磁盘IO/网络IO增加的确存在潜在的性能问题，我们列举出以下一些可能性。
1. 用户升级后跑的查询个数是否变多了？（见下面第二部分）
2. 表里的数据行数是否变多了？（见下面第三部分）
3. 查询的执行计划是否变差了？（见下面第四部分）
4. GP5的执行器、BufferPool等内核组件是否有bug？
针对这些怀疑，我们需要进一步查证用户的查询负载。
（未完待续）
关于作者
王昊，Pivotal Greenplum工程技术经理
曾任职于Teradata SQL实验室。长期从事分布式数据仓库的研究，深谙高并发MPP数据库之美，作为Greenplum内核研发团队的核心成员，主持全新一代自治数据库平台GPCC的规划、设计和开发，奠定了Greenplum在自动化运维领域的领先地位。同时凭借丰富的工程经验和行业洞悉，为中国研发团队在分布式引擎、ETL工具、扩展组件、质量保证等多项领域提供创新输入和人才培养。
- 发表于:
- 原文链接：https://kuaibao.qq.com/s/20191225A0GH8M00?refer=cp_1026
- 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号（企鹅号）传播渠道之一，根据《腾讯内容开放平台服务协议》转载发布内容。
- 如有侵权，请联系 cloudcommunity@tencent.com 删除。
相关快讯
扫码
添加站长 进交流群
领取专属 10元无门槛券
私享最新 技术干货
腾讯云开发者
