（2）检查分布式数据库和表的大小
-- 数据库使用空间（GB）
select sodddatname,sodddatsize/1024/1024/1024 GB from gp_toolkit.gp_size_of_database order by sodddatname;
-- 表使用空间（MB）
select relname as name, sotdsize/1024/1024 as size, sotdtoastsize/1024/1024 as toast, sotdadditionalsize/1024/1024 as other
from gp_toolkit.gp_size_of_table_disk as sotd, pg_class
where sotd.sotdoid=pg_class.oid order by relname;
-- 索引使用空间（MB）
select relname as indexname, soisize/1024/1024 as soisize
from pg_class, gp_toolkit.gp_size_of_index
where pg_class.oid=gp_size_of_index.soioid
and pg_class.relkind='i';

3. 检查数据分布倾斜

（1）查看表的分布键
\\d+ table_name

（2）查看数据分布
-- 用count(*)方式计算每个segment上的记录数，慢，不建议
select gp_segment_id, count(*) from table_name group by gp_segment_id;
-- 计算一张表在不同segment上所占空间来评估是否发生数据倾斜，推荐
select gp_segment_id, pg_relation_size('table_name')
from gp_dist_random('gp_id') order by 2 desc;

（3）检查计算倾斜
-- 不推荐
select gp_segment_id, count(*) from table_name
where column_name='column_value' group by gp_segment_id;
-- 推荐
select * from gp_toolkit.gp_workfile_usage_per_segment;
select * from gp_toolkit.gp_workfile_usage_per_query;

（4）避免极端倾斜警告
执行执行哈希联接操作的查询时，可能会收到以下警告消息：
Extreme skew in the innerside of Hashjoin

当哈希连接运算符的输入发生倾斜时，就会发生这种情况。它不会阻止查询成功完成。可以按照以下步骤来避免执行计划中倾斜：
   1. 确保分析了所有事实表。
   2. 验证是否分析了查询使用的任何填充的临时表。
   3. EXPLAIN ANALYZE查看执行计划并查找以下内容：
   . 如果使用多列筛选器的扫描产生的行数超过估计数，将gp_selectivity_damping_factor服务器配置参数设置为2或更高，然后重新测试查询。
   . 如果在连接相对较小（小于5000行）的单个事实表时发生倾斜，将gp_segments_for_planner服务器配置参数设置为1，然后重新测试查询。
   4. 检查查询中应用的筛选器是否与基表的分布键匹配。如果筛选器和分发键相同，考虑使用不同的分发键重新分发一些基表。
   5. 检查连接键的基数。如果它们的基数较低，尝试使用不同的联接列或表上的附加筛选器重写查询，以减少行数。这些更改可能会改变查询语义。

4. 查看数据库对象的元数据信息

（1）查看最后执行的操作
select schemaname as schema, objname as table, usename as role, actionname as action, subtype as type, statime as time
from pg_stat_operations
where objname='work_heat_user_operate';

（2）查看对象定义
\\d+ work_heat_user_operate

5. 查看会话的内存使用

（1）创建session_state.session_level_memory_consumption视图
psql -d dw -c "CREATE EXTENSION gp_internal_tools;"

6. 查看查询的工作文件使用

select * from gp_toolkit.gp_workfile_entries;
select * from gp_toolkit.gp_workfile_usage_per_query;
select * from gp_toolkit.gp_workfile_usage_per_segment;

7. 查看服务器日志文件

（1）搜索GP服务器日志文件
gplogfilter -n 3

gpssh -f seg_host_file
=> source /usr/local/greenplum-db/greenplum_path.sh
=> gplogfilter -n 3 /data1/primary/gp*/pg_log/gpdb*.csv

8. 使用gp_toolkit

alter role myrole set search_path to myschema,gp_toolkit;

9. SQL标准错误码

二、例行系统运维任务

1. 例行vacuum与analyze

（1）每天在每个数据库执行，释放过期行所占空间，同时释放事务号防止XID回卷失败。
#!/bin/bash
DBNAME="dw"
SYSTABLES=" table_schema || '.' || table_name || ';' from information_schema.tables
where table_type='BASE TABLE'

psql -tc "SELECT 'VACUUM FREEZE ' || $SYSTABLES" $DBNAME | psql -a $DBNAME
analyzedb -ad $DBNAME

（2）定期维护系统目录

#!/bin/bash
DBNAME="<database-name>"
SYSTABLES="' pg_catalog.' || relname || ';' FROM pg_class a, pg_namespace b
WHERE a.relnamespace=b.oid AND b.nspname='pg_catalog' AND a.relkind='r'"

reindexdb --system -d $DBNAME
psql -tc "SELECT 'VACUUM' || $SYSTABLES" $DBNAME | psql -a $DBNAME
analyzedb -as pg_catalog -d $DBNAME

（3）加强的系统目录维护（如果定期维护系统目录，不应该需要执行此高成本过程）
. 停止GP访问
. reindex pg_catalog.*
. vacuum full pg_catalog.*
. analyze pg_catalog.*

（4）为查询优化执行Vacuum与Analyze
-- 诊断膨胀空间
select * from gp_toolkit.gp_bloat_diag;
-- 先生成精确的行数再生成精确的统计信息
vacuum cust_info;
analyze cust_info;

2. 例行重建索引

通常 drop index + create index 比 reindex 快。批量插入操作（insert、update、delete大量数据）可以考虑 drop index -> 批量操作 -> create index。

3. 管理GP数据库日志文件

（1）数据库服务器日志文件
# 在master上执行
gpssh -f all_host -e 'find /data/master/gpseg-1/pg_log -mtime +10 -type f -delete'
gpssh -f all_host -e 'find /data1/primary/gp*/pg_log -mtime +10 -type f -delete'
gpssh -f all_host -e 'find /data2/primary/gp*/pg_log -mtime +10 -type f -delete'

（2）命令行工具程序日志文件
gpssh -f all_host -e 'find ~/gpAdminLogs -mtime +10 -type f -delete'

三、推荐的监控与运维任务

1. 监控数据状态

（1）列出下线的segment，5-10分钟执行一次，返回行则报警。
psql -d postgres -c "select * from gp_segment_configuration where status <> 'u';"

纠正措施：
. 确认相应segment所在主机有响应。
. 检查相应segment的pg_log文件寻找下线原因。
. 如果没有发现意外错误信息，执行gprecoverseg将相应segment重新上线。

（2）列出change tracking模式的segment（对应的mirror宕机），5-10分钟执行一次，返回行则报警。
psql -d postgres -c "select * from gp_segment_configuration where mode = 'c';"

纠正措施：
. 确认相应segment所在主机有响应。
. 检查相应segment的pg_log文件寻找mirror宕机原因。
. 如果没有发现意外错误信息，执行gprecoverseg将相应segment重新上线。

（3）列出re-syncin模式的segment，5-10分钟执行一次，返回行则报警。
psql -d postgres -c "select * from gp_segment_configuration where mode = 'r';"

纠正措施：
. 如果mode字段的值没有从'r'改为's'，检查相应segment的pg_log文件中是否存在错误。

（4）检查primary/mirror角色改变的segment（造成集群不平衡），5-10分钟执行一次，返回行则报警。
psql -d postgres -c "select * from gp_segment_configuration where preferred_role <> role;"

纠正措施：
. 等待一个可接受的时间窗口，然后重启数据库，将这些segment转换为它们首选角色。

（5）运行一个分布式查询以测试它是否在所有segment上运行，5-10分钟执行一次，每个primary segment应返回一行。
psql -d postgres -c "select gp_segment_id, count(*) from gp_dist_random('pg_class') group by 1 order by gp_segment_id;"

纠正措施：
. 如果此查询失败，则向群集中的某些segment派发有问题。这是一个罕见事件，检查无法调度的主机，以确保没有硬件或网络问题。

（6）测试master镜像状态，5-10分钟执行一次，如果不是streaming则报警。
psql -d dw -c 'select pid, state from pg_stat_replication;'

纠正措施：
. 检查master和standby master的pg_log文件是否有错误。如果没有意外错误并且机器已启动，运行gpinitstandby程序使standby master联机。

（7）执行基本检查，5-10分钟执行一次，查看master是否正常工作。
psql -d postgres -c "select count(*) from gp_segment_configuration;"

纠正措施：
. 如果此查询失败，master可能宕机。再试几次，然后手动检查master。如果master宕机，重启主机以确保活动主机上master进程，然后激活standby master。

2. 数据库警告日志监控

检查系统的FATAL和ERROR日志消息，15分钟一次，发现则并报警。
psql --pset=pager=off -x -c "
select * from gp_toolkit.gp_log_system where logseverity in ('FATAL','ERROR') and logtime > (now() - interval '15 minutes');"

3. 硬件和操作系统监控

（1）检查数据库和操作系统的空间使用，5-30分钟执行一次，硬盘使用率75%报警。
（2）检查网络错误或丢包，每小时执行一次。
（3）检查RAID错误或RAID性能降级，每5分钟执行一次。
（4）检查I/O带宽与I/O倾斜，创建群集或怀疑硬件有问题时执行。硬盘读2GB/S，硬盘写1GB/S，网络读写10Gb/S。

4. 系统目录（元数据表）监控

（1）检查集群中所有主机上的目录一致性，每星期对每个库执行一次，对识别出来的问题执行修复脚本（gpcheckcat -g生成）。
gpcheckcat -O dw

（2）检查没有相应pg_attribute条目的pg_class条目。在系统没有用户的停机期间，每个月在每个数据库中运行。对识别出来的问题执行修复脚本（gpcheckcat -g生成）。
gpcheckcat -R pgclass

（3）检查泄露的临时schema和缺少定义的schema。在系统没有用户的停机期间，每个月在每个数据库中运行。对识别出来的问题执行修复脚本（gpcheckcat -g生成）。
gpcheckcat -R namespace

（4）检查约束和随机分布表。在系统没有用户的停机期间，每个月在每个数据库中运行。对识别出来的问题执行修复脚本（gpcheckcat -g生成）。
gpcheckcat -R distribution_policy

（5）检查对不存在对象的依赖关系。在系统没有用户的停机期间，每个月在每个数据库中运行。对识别出来的问题执行修复脚本（gpcheckcat -g生成）。
gpcheckcat -R dependency

5. 数据维护

（1）检查缺少统计信息的表，在每个库上执行。在相应表上执行analyze。
select * from gp_toolkit.gp_stats_missing;

（2）检查数据文件中是否存在膨胀表。每个月在每个库上执行。在维护窗口对相应表执行VACUUM FULL。
select * from gp_toolkit.gp_bloat_diag;

6. 数据库维护

（1）标记堆表中已删除的行，以便它们占用的空间可以重用。每天执行一次。
vacuum <user_table>;

（2）更新表的统计信息。在加载数据后和查询之前执行。
analyzedb -d <database> -a

（3）备份数据库。每天，或根据备份计划的要求执行并行备份（社区版没提供）。
gpbackup

（4）对系统目录执行vacuum、reindex和analyze。对每个数据库每周执行一次（注意按顺序执行），如果频繁创建和删除数据库对象，则频率更高。
vacuum
reindexdb -s <database>
analyzedb -s pg_catalog -d <database>

7. 补丁与升级

（1）确保对Linux内核应用了任何错误修复或增强，至少每6个月执行一次。

（2）升级Greenplum数据库小版本，例如5.0.x。每季度执行一次。
升级Greenplum 6小版本过程参考：
https://docs.greenplum.org/6-14/install_guide/upgrading.html

四、性能问题排查指南

1. 执行gpstate检查down的segment。

2. 执行gpcheckperf检查segment host的硬盘、内存、网卡等硬件问题。

3. 检查活动会话（负载）
用gpadmin用户查询pg_stat_activity

4. 检查锁（连接）
select locktype, database, c.relname, l.relation, l.transactionid, l.pid, l.mode, l.granted, a.query
from pg_locks l, pg_class c, pg_stat_activity a
where l.relation=c.oid and l.pid=a.pid
order by c.relname;

select * from gp_toolkit.gp_resgroup_status;

5. 检查查询状态和系统应用
用gpssh在多台主机上同时执行ps、top、iostat、vmstat、netstat ...

6. 检查慢查询的执行计划
explain、explain analyze

7. 检查segment logs中的 out of memory 事件。

8. 检查错误日志
cd $MASTER_DATA_DIRECTORY/pg_log

gplogfilter -t

gpssh -f seg_hosts_file -e 'source /usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -f con6 /gpdata/*/pg_log/gpdb*.csv' > seglog.out

以上是关于Greenplum 监控与运维的主要内容，如果未能解决你的问题，请参考以下文章

Greenplum 实时数据仓库实践——Greenplum监控与运维

linux服务监控与运维

Redis 开发与运维Redis 的噩梦：阻塞