【实录】首次利用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?

针对这些怀疑,我们需要进一步查证用户的查询负载。

(未完待续)

关于作者

王昊,Pivotal Greenplum工程技术经理

曾任职于Teradata SQL实验室。长期从事分布式数据仓库的研究,深谙高并发MPP数据库之美,作为Greenplum内核研发团队的核心成员,主持全新一代自治数据库平台GPCC的规划、设计和开发,奠定了Greenplum在自动化运维领域的领先地位。同时凭借丰富的工程经验和行业洞悉,为中国研发团队在分布式引擎、ETL工具、扩展组件、质量保证等多项领域提供创新输入和人才培养。



“【实录】首次利用GPCC历史数据调优Greenplum 第一部分”的2个回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注