原 GreenPlum官方监控工具gpcc简介、使用及使用gpcc进行调优

发布日期 2023年3月2日 · 已更新 2023年7月19日

0 381 2

👉 本文共约7400个字，系统预计阅读时间或需28分钟。

简介
安装配置
GPCC功能介绍
启用历史数据收集
停用gpperfmon
升级更轻松
使用GPCC历史数据调优Greenplum
第一部分，了解GPDB集群的整体性能特征
CPU与内存性能
磁盘与网络IO
第二部分，分析查询负载整体情况
gpcc发送告警邮件
总结
参考

简介

Greenplum 数据库提供基于 Web 的可视化工具—Greenplum Command Center（简称GPCC）。GPCC 可以监控 Greenplum 数据库系统的性能、集群健康状态、查询执行及系统资源使用情况。GPCC 监控系统性能指标，分析集群健康状况，并使数据库管理员能够在 Greenplum Database 环境中执行管理任务。它提供了一个本地浏览器的 HTML5 图形控制台，用于查看 Greenplum Database 系统指标和执行某些数据库管理任务。

Greenplum Command Center，或者简称GPCC，是Greenplum原生的图形化运维管理工具。在最近的开发中，基于全新的界面和用户体验，陆续推出了监控、历史数据、管理的功能，在众多商业用户上得到了广泛的应用和认可。

随着Greenplum 6.0的发布，Greenplum Command Center（也称为GPCC）也在新的版本中抵达了一个新的里程碑。我们跳过了版本5，并为GPDB 6.0发布了GPCC 6.0。对于GPDB 5.19以上用户，我们发布了4.8.0。

安装配置

请参考：https://www.dbaup.com/greenplumguanfangjiankonggongjugpcc-6deanzhuanghexiezai.html

GPCC功能介绍

启用历史数据收集

GPCC实时从GPDB集群收集查询性能数据和系统指标，并将数据存储到其自己的历史数据库中。自版本4.6.0起，历史记录功能已在GPCC中提供。但在4.8.0 / 6.0.0之前这个功能默认是关掉的，而且GPCC会依靠旧的gpperfmon实用程序来收集一些数据。现在从4.8.0 / 6.0.0开始，GPCC会收集所有历史数据，并且默认情况下会打开历史记录。由于与旧的gpperfmon历史记录相比，它具有更好的性能和更多的历史指标数据，因此我们还建议用户关闭gpperfmon。

默认情况下，GPCC历史记录会捕获所有查询。如果用户没有兴趣，可以将其设置为跳过短于某个时间阈值的查询。除了查询历史记录之外，GPCC现在还可以收集gpperfmon之前收集的系统指标，磁盘使用历史记录和pg日志历史记录。历史数据将保存到gpperfmon数据库的gpmetrics SCHEMA下的某些表中。请检查GPCC文档以获取有关这些表的详细说明。

当您需要从UI上没有提供的历史数据中获得一些见解时，可以查询这些数据库以获得帮助。

下面是一个示例，用于确定今天执行的查询中使用 SLICE 数量最多的前100个。这可以帮助识别写得不好的查询或者设计不正确的表。

停用gpperfmon

Gpperfmon是GPDB的旧的监控解决方案。与GPCC相比，它具有一些缺点，如果您使用GPCC 4.8.0或6.0.0，建议将其关闭。以下是可以帮助您了解我们为什么提出此建议的证明。

我们针对4种配置运行了pgbench（SELECT ONLY，持续15分钟）：这4种配置分别为：启用gpperfmon和GPCC历史记录的GPDB；仅启用GPCC历史记录的GPDB；仅启用gpperfmon的GPDB和没有启用监控的GPDB。事实证明，启用gpperfmon对总的TPS有很大影响。我们还在Google Cloud Platform上对4种类型的实例进行了测试。结果表明，如果启用gpperfmon，即使在强大的基础架构上运行，性能提升也非常有限。但是当它关闭时，TPS明显增大。

如果停用gpperfmon，请确保GPCC的历史数据收集是启用的。gpperfmon收集的旧数据仍将显示在GPCC中，并且无需迁移gpperfmon数据。但是，如果您有一些现有脚本使用旧的gpperfmon表中的数据，则其中的某些脚本可能将不再更新。例如，关闭gpperfmon时，那些名为 _now和 _tail表将不再更新。但是您可能会在gpmetrics SCHEMA 下的其他一些表和视图中找到所需的数据。有关该 SCHEMA 下内容的更多信息，请点击文章底部阅读原文参考文档，以帮助您修改脚本以获取更新的数据。

gpperfmon_install实用程序也可以由新的GPCC安装程序代替。GPCC安装程序现在具有用于GPCC初始化的gpperfmon_install功能，包括创建gpperfmon数据库和gpmon用户。除了一件事，使用gpperfmon_install，用户可以选择以明文方式指定gpmon用户的密码。GPCC安装程序没有该选项。但是，用户可以使用“ -W”选项来输入初始密码（不会保存在任何地方），或者不使用“ -W”选项从而获得默认密码（保存在.pgpass文件中）。

升级更轻松

过去，升级GPCC通常需要升级GPDB，这一先决条件常常使用户无法升级到新的GPCC版本。GPCC 6.x用户将不再面对这种情况。我们将使每个GPCC 6.x版本都能与所有GPDB 6.x版本一起使用。如果不升级GPDB，则可能不会获得一些新指标，但仍可能会得到错误修复和一些新功能。对于GPCC 4.x用户，如果您使用的是GPDB 5.19及更高版本，现在可以升级到GPCC 4.8.0而无需升级GPDB。而且我们也会尽量保证将来的GPCC 4.x版本也不需要升级GPDB。

使用GPCC历史数据调优Greenplum

数据库性能分析和优化是一个难题，笔者所在的Greenplum研发部门近期正好在解决一个实际用户的全局性能问题，本文记录了分析过程和解决思路。

客户在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) < 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
;

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

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

;

SELECT

ctime::date || '_' || CASE WHEN extract(hour from ctime) < 10 THEN '0' ELSE '' END || extract(hour from ctime) AS date_hour

, CAST(AVG(cpu_sys) AS numeric(10, 2)) AS cpu_sys

, CAST(avg(cpu_user) AS numeric(10, 2)) AS cpu_user

, CAST(avg(cpu_sys+cpu_user) AS numeric(10, 2)) AS cpu

, CAST(avg(mem_total/1024/1024/1024) AS numeric(10, 2)) AS mem_total_GB

, CAST(avg(mem_used/1024/1024/1024) AS numeric(10, 2)) AS mem_used

, CAST(avg(mem_actual_used/1024/1024/1024) AS numeric(10, 2)) AS mem_actual

, CAST(avg(gsh.swap_used/1024/1024/1024) AS numeric(10, 2)) as swap_used

, CAST(avg(gsh.swap_page_in) AS numeric(10, 2)) as swap_page_in

, CAST(avg(gsh.swap_page_out) AS numeric(10, 2)) as swap_page_out

, CAST(avg(load0) AS numeric(10, 2)) AS load0

, CAST(avg(load1) AS numeric(10, 2)) AS load1

, CAST(avg(load2) AS numeric(10, 2)) AS load2

, CAST((avg(disk_rb_rate) / 1024 / 1024) AS numeric(10, 2)) AS disk_R_MBs

, CAST((avg(disk_wb_rate) / 1024 / 1024) AS numeric(10, 2)) AS disk_W_MBs

, CAST((avg(net_rb_rate) / 1024 / 1024) AS numeric(10, 2)) AS net_I_MBs

, CAST((avg(net_wb_rate) / 1024 / 1024) AS numeric(10, 2)) AS net_O_MBs

FROM

gpmetrics.gpcc_system_history gsh

WHERE hostname LIKE 'sdw4%'

AND ctime >= '2023-07-09 00:00:00'

AND ctime < '2023-10-16 00:00:00'

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增加的确存在潜在的性能问题，我们列举出以下一些可能性。

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

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

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信dbaup66，谢谢！

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

获取验证码：请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。

打赏赞(2)

标签：原创 GreenPlum 监控 gpcc 性能调优调优 web界面

小麦苗

学习或考证，均可联系麦老师，请加微信db_bao或QQ646634621

发表回复取消回复

要发表评论，您必须先登录。

原 GreenPlum官方监控工具gpcc简介、使用及使用gpcc进行调优

简介

安装配置