Greenplum 监控与运维

Posted wzy0623

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Greenplum 监控与运维相关的知识,希望对你有一定的参考价值。

目录

一、监控

1. 检查系统状态

2. 检查磁盘空间使用(使用率不能超过70%)

3. 检查数据分布倾斜

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

5. 查看会话的内存使用

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

7. 查看服务器日志文件

8. 使用gp_toolkit

9. SQL标准错误码

二、例行系统运维任务

1. 例行vacuum与analyze

2. 例行重建索引

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

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

1. 监控数据状态

2. 数据库警告日志监控

3. 硬件和操作系统监控

4. 系统目录(元数据表)监控

5. 数据维护

6. 数据库维护

7. 补丁与升级

四、性能问题排查指南


一、监控

1. 检查系统状态

(1)查看master与segment的状态与配置
# 概要信息
gpstate
# 配置详细信息
gpstate -s

(2)查看mirror段的状态与配置
# mirror状态
gpstate -m
# primary与mirror的映射
gpstate -c
# standby master状态
gpstate -f

2. 检查磁盘空间使用(使用率不能超过70%)

(1)查看segment剩余空间(KB)
select * from gp_toolkit.gp_disk_free order by dfsegment;

(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监控与运维

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

linux服务监控与运维

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

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

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