Greenplum 监控与运维
监控、例行系统运维任务、推荐的监控与运维任务、性能问题排查指南
目录
一、监控
1. 检查系统状态
（1）查看 master 与 segment 的状态与配置
# 概要信息
gpstate
# 配置详细信息
gpstate -s（2）查看 mirror 段的状态与配置
# mirror状态
gpstate -m
# primary与mirror的映射
gpstate -c
# standby master状态
gpstate -f2. 检查磁盘空间使用（使用率不能超过 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_operate5. 查看会话的内存使用
（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*.csv8. 使用 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 dependency5. 数据维护
（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
一站式 AI 云服务平台
更多推荐
1
0- 0
已为社区贡献4条内容
所有评论(0)