Greenplum数据库包含一个可选的系统监控和管理数据库gpperfmon，管理员可以选择启用它。gpperfmon_install命令行工具创建gpperfmon 数据库并启用数据收集代理来存储查询和系统矩阵信息到该数据库。管理员可以查询gpperfmon 数据库中的矩阵信息。更多gpperfmon的信息，请见Greenplum Database Reference Guide。

监控系统状态

作为一个Greenplum数据库管理员，必须监控系统的问题事件，例如一个Segment宕机或者一台Segment主机磁盘空间耗尽。下面的主题描述如何监控一个Greenplum数据库系统的健康状况以及检查一个Greenplum数据库系统的特定状态信息。

检查系统状态

一个Greenplum数据库系统由横跨多台机器的多个PostgreSQL实例（Master和Segment）构成。要监控一个 Greenplum数据库系统，需要了解整个系统的信息以及个体实例的状态信息。gpstate 工具提供有关一个Greenplum数据库系统的状态信息。

查看Master和Segment的状态及配置

默认的gpstate行为是检查Segment实例并且显示可用和失效Segment的一个简短状态。例如，要快速查看Greenplum数据库系统的状态：

$ gpstate

$ gpstate

要查看Greenplum数据库阵列配置更详细的信息，使用带有-s选项的gpstate：

$ gpstate -s

1	$ gpstate -s

查看镜像配置和状态

如果在使用镜像作为数据冗余，用户可能想要看看系统中的镜像Segment实例列表、它们当前的同步状态以及镜像和主Segment之间的映射。例如，要查看一个系统中的镜像Segment和它们的状态：5

$ gpstate -m

1	$ gpstate -m

要查看主Segment到镜像Segment的映射：

$ gpstate -c

1	$ gpstate -c

要查看后备Master镜像的状态：

$ gpstate -f

1	$ gpstate -f

检查磁盘空间使用

一个数据库管理员最重要的监控任务是确保Master和Segment数据目录所在的文件系统的使用率不会超过 70%的。完全占满的数据磁盘不会导致数据损坏，但是可能会妨碍数据库的正常操作。如果磁盘占用得太满，可能会导致数据库服务器关闭。

可以使用gp_toolkit管理模式中的gp_disk_free外部表来检查Segment主机文件系统中的剩余空闲空间（以KB为计量单位）。例如：

=# SELECT * FROM gp_toolkit.gp_disk_free    ORDER BY dfsegment;

1	=# SELECT * FROM gp_toolkit.gp_disk_free ORDER BY dfsegment;

检查分布式数据库和表的大小

gp_toolkit管理模式包含几个可以用来判断Greenplum数据库的分布式数据库、模式、表或索引磁盘空间使用的视图。

用于检查数据库对象尺寸和磁盘空间的视图列表，请见Greenplum Database Reference Guide.

查看一个数据库的磁盘空间使用情况

要查看一个数据库的总大小（以字节计），使用gp_toolkit管理模式中的gp_size_of_database 视图。例如：

=> SELECT * FROM gp_toolkit.gp_size_of_database    ORDER BY sodddatname;

1	=> SELECT * FROM gp_toolkit.gp_size_of_database ORDER BY sodddatname;

查看一个表的磁盘空间使用情况

gp_toolkit管理模式包含几个检查表大小的视图。表大小视图根据对象ID （而不是名称）列出表。要根据一个表的名称检查其尺寸，必须在pg_class表中查找关系名称（relname）。例如：

=> SELECT relname AS name, sotdsize AS size, sotdtoastsize 
   AS toast, sotdadditionalsize AS other 
   FROM gp_toolkit.gp_size_of_table_disk as sotd, pg_class 
   WHERE sotd.sotdoid=pg_class.oid ORDER BY relname;

=> SELECT relname AS name, sotdsize AS size, sotdtoastsize

AS toast, sotdadditionalsize AS other

FROM gp_toolkit.gp_size_of_table_disk as sotd, pg_class

WHERE sotd.sotdoid=pg_class.oid ORDER BY relname;

可用的表大小视图的列表请见Greenplum Database Reference Guide.

查看索引的磁盘空间使用情况

gp_toolkit管理模式包含几个用于检查索引大小的视图。要查看一个表上所有索引的总大小，使用 gp_size_of_all_table_indexes视图。要查看一个特定索引的大小，使用gp_size_of_index视图。该索引大小视图根据对象ID（而不是名称）列出表和索引。要根据一个索引的名称查看其尺寸，必须在pg_class 表中查找关系名称（relname）。例如：

=> SELECT soisize, relname as indexname
   FROM pg_class, gp_toolkit.gp_size_of_index
   WHERE pg_class.oid=gp_size_of_index.soioid 
   AND pg_class.relkind='i';

=> SELECT soisize, relname as indexname

FROM pg_class, gp_toolkit.gp_size_of_index

WHERE pg_class.oid=gp_size_of_index.soioid

AND pg_class.relkind='i';

检查数据分布倾斜

Greenplum数据库中所有的表都是分布式的，意味着它们的数据被按规则划分到系统中的所有Segment上。不均匀分布的数据可能会削弱查询处理性能。一个表的分布策略在表创建时被确定。有关选择表分布策略的信息，请见下列主题：

gp_toolkit管理模式还包含一些用于检查表上数据分布倾斜的视图。有关如何检查非均匀数据分布的信息，请见Greenplum Database Reference Guide.

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

查看一个表的分布键

要查看一个表中被用作数据分布键的列，可以使用psql中的\d+ 元命令来检查表的定义。例如：

=# \d+ sales
                Table "retail.sales"
 Column      |     Type     | Modifiers | Description
-------------+--------------+-----------+-------------
 sale_id     | integer      |           |
 amt         | float        |           |
 date        | date         |           |
Has OIDs: no
Distributed by: (sale_id)

=# \d+ sales

Table "retail.sales"

Column | Type | Modifiers | Description

-------------+--------------+-----------+-------------

sale_id | integer | |

amt | float | |

date | date | |

Has OIDs: no

Distributed by: (sale_id)

当我们创建复制表时，Greenplum数据库会在每个Segment上都存储一份完整的表数据。复制表没有分布键。 \d+元命令会展示分布表的分布键，复制表展示状态为Distributed Replicated。

查看数据分布

要查看一个表中行的数据分布（每个Segment上的行数），可以运行一个这样的查询：

=# SELECT gp_segment_id, count(*)    FROM table_name GROUP BY gp_segment_id;

1	=# SELECT gp_segment_id, count(*) FROM table_name GROUP BY gp_segment_id;

如果所有的Segment都有大致相同的行数，一个表就可以被认为是分布均匀的。

Note:

如果在复制表上运行该查询会执行失败，因为Greenplum数据库不允许用户查询复制表的gp_segment_id 系统列数据。由于每个Segment上都有一份完整的表数据，复制表必然是均匀的。

检查查询过程倾斜

当一个查询被执行时，所有的Segment应该具有等量的负载来保证最好的性能。如果发现了一个执行性能低下的查询，可能需要使用EXPLAIN命令进行深入研究。有关使用EXPLAIN命令和查询分析的信息，请见查询分析.

如果表的数据分布策略与查询谓词没有很好地匹配，查询执行负载可能会倾斜。要检查执行倾斜，可以运行一个这样的查询：

=# SELECT gp_segment_id, count(*) FROM table_name   WHERE column='value' GROUP BY gp_segment_id;

1	=# SELECT gp_segment_id, count(*) FROM table_name WHERE column='value' GROUP BY gp_segment_id;

这将显示对于给定的WHERE谓词，Segment会返回的行数。

如查看数据分布所说的, 该查询在复制表上运行时也会报错，因为在复制表上查询的 gp_segment_id列不具有参考价值。

避免极度倾斜警告

当执行一个使用哈希连接操作的查询时，可能会收到下面的警告消息：

Extreme skew in the innerside of Hashjoin

当一个哈希连接操作符的输入倾斜时，就会发生这种情况。它不会阻碍查询成功完成。可以按照这些步骤来避免计划中的倾斜：

确保所有的事实表都被分析过。
验证该查询用到的任何已填充临时表都被分析过。
查看该查询的EXPLAIN ANALYZE计划，并且在其中查找以下信息：
- 如果有带多列过滤的扫描产生超过预估的行数，则将gp_selectivity_damping_factor 服务器配置参数的值设置为当前值的2倍以上并且重新测试该查询。
- 如果在连接一个相对较小（小于5000行）的单一事实表时发生倾斜，将gp_segments_for_planner 服务器配置参数设置为1并且重新测试该查询。
检查应用于该查询的过滤属性是否匹配基表的分布键。如果过滤属性和分布键相同，考虑用不同的分布键重新分布一些基表。
检查连接键的基数。如果基数较低，尝试用不同的连接列或者表上额外的过滤属性来重写该查询以降低行数。这些更改可能会改变查询的语义。

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

Greenplum数据库在其系统目录中跟踪各种有关存储在数据库中对象（例如表、视图、索引等等）和全局对象（例如角色和表空间）的元数据信息。

查看最后一个执行的操作

可以使用系统视图pg_stat_operations和 pg_stat_partition_operations 查看在一个对象（例如一个表）上执行的动作。例如，要查看在一个表上执行的动作，比如它何时被创建以及它上一次是什么时候被清理和分析：

=> 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='cust';
 schema | table | role | action  | type  | time
--------+-------+------+---------+-------+--------------------------
  sales | cust  | main | CREATE  | TABLE | 2016-02-09 18:10:07.867977-08
  sales | cust  | main | VACUUM  |       | 2016-02-10 13:32:39.068219-08
  sales | cust  | main | ANALYZE |       | 2016-02-25 16:07:01.157168-08
(3 rows)

=> 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='cust';

--------+-------+------+---------+-------+--------------------------

(3 rows)

查看一个对象的定义

要查看一个对象（例如表或者视图）的定义，在psql中可以使用\d+元命令。例如，要查看一个表的定义：

=> \d+ mytable

1	=> \d+ mytable

查看会话内存使用信息

参考：https://www.xmmup.com/greenplumchakanhuihuaneicunshiyongxinxi.html

可以创建并且使用session_level_memory_consumption视图来查看正在Greenplum数据库上运行查询的会话的当前内存利用信息。该视图包含会话信息以及该会话连接到的数据库、该会话当前运行的查询和会话处理所消耗的内存等信息。

创建session_level_memory_consumption视图

要在Greenplum数据库中创建session_level_memory_consumption视图，为每一个数据库运行一次扩展创建语句CREATE EXTENSION gp_internal_tools;。例如，要在数据库testdb中安装该视图，可使用这个命令：

$ psql -d testdb -c "CREATE EXTENSION gp_internal_tools;"

1	$ psql -d testdb -c "CREATE EXTENSION gp_internal_tools;"

session_level_memory_consumption视图

session_level_memory_consumption视图提供有关正在运行SQL查询的会话的内存消耗以及闲置时间的信息。

当基于资源队列的资源管理方式启用时，在该视图中，列is_runaway表示是否Greenplum数据库认为该会话是一个失控会话，这种判断基于该会话的查询的vmem内存消耗来做出。在资源队列管理模式下，当查询消耗过多内存时， Greenplum数据库认为该会话处于失控状态。Greenplum数据库的服务器配置参数runaway_detector_activation_percent 控制Greenplum数据库什么时候会认为一个会话是失控会话。

在该视图中，当基于组的资源管理方式启用时，列is_runaway, runaway_vmem_mb,和 runaway_command_cnt功能失效。

列	类型	描述
datname	name	该会话连接到的数据库名。
sess_id	integer	会话ID。
usename	name	会话用户的用户名。
current_query	text	该会话正在运行的当前SQL查询。
segid	integer	Segment ID。
vmem_mb	integer	该会话的总vmem内存使用，以MB计。
is_runaway	boolean	会话被标记为在Segment上失控。
qe_count	integer	该会话的查询处理数量。
active_qe_count	integer	该会话的活动查询处理数量。
dirty_qe_count	integer	还没有释放其内存的查询处理的数量。对于没有运行的会话该值为-1。
runaway_vmem_mb	integer	当会话被标记为失控会话时消耗的vmem内存量。
runaway_command_cnt	integer	当会话被标记为失控会话时的命令计数。
idle_start	timestamptz	这个会话中上一次一个查询处理变成空闲的时间。

查看查询工作文件使用信息

Greenplum数据库管理方案gp_toolkit包含显示Greenplum数据库工作文件信息的视图。如果没有足够的内存让查询完全在内存中执行，Greenplum数据库会在磁盘上创建工作文件。这些信息可以用来故障排查和查询调优。这些视图中的信息也可以被用来为Greenplum数据库配置参数 gp_workfile_limit_per_query和gp_workfile_limit_per_segment 指定值。

在模式gp_toolkit中有下面这些视图：

gp_workfile_entries视图为当前在Segment上创建了工作文件的每个操作符都包含一行。
gp_workfile_usage_per_query视图为当前在Segment上创建了工作文件的每个查询都包含一行。
gp_workfile_usage_per_segment视图为每个Segment都包含一行。每一行显示了当前在该Segment上用于工作文件的总磁盘空间。

有关使用gp_toolkit的信息请见使用gp_toolkit。

查看数据库服务器日志文件

Greenplum数据库中的每一个数据库实例（Master和Segment）都运行着一个有着自己的服务器日志文件的 PostgreSQL数据库服务器。日常的日志文件被创建在Master和每个Segment的数据目录中的 pg_log目录下。

日志文件格式

服务器日志文件被写成一种逗号分隔值（CSV）格式。一些日志项并不会所有的域都有值。例如，只有与一个查询工作者进程相关的日志项才会有slice_id值。可以用查询的会话标识符（gp_session_id）和命令标识符（gp_command_count）来确定一个特定查询的相关日志项。

下列域会被写入到日志中：

#	域名称	数据类型	描述
1	event_time	timestamp with time zone	该日志项被写入到日志中的时间
2	user_name	varchar(100)	数据库用户名
3	database_name	varchar(100)	数据库名
4	process_id	varchar(10)	系统进程ID（以”p”为前缀）
5	thread_id	varchar(50)	线程号（以”th”为前缀）
6	remote_host	varchar(100)	在Master上，是客户端机器的主机名/地址。在Segment上，是Master的主机名/地址。
7	remote_port	varchar(10)	Segment或者Master的端口号
8	session_start_time	timestamp with time zone	会话连接被打开的时间
9	transaction_id	int	Master上的顶层事务ID。这个ID是任何子事务的父亲。
10	gp_session_id	text	会话标识符号（以”con”为前缀）
11	gp_command_count	text	会话中的命令号（以”cmd”为前缀）
12	gp_segment	text	Segment内容标识符（主Segment以”seg”为前缀，镜像Segment以”mir”为前缀）。Master的内容ID总是为-1。
13	slice_id	text	切片ID（被执行的查询计划的一部分）
14	distr_tranx_id	text	分布式事务ID
15	local_tranx_id	text	本地事务ID
16	sub_tranx_id	text	子事务ID
17	event_severity	varchar(10)	值包括：LOG、ERROR、FATAL、PANIC、DEBUG1、DEBUG2
18	sql_state_code	varchar(10)	与日志消息相关的SQL状态代码
19	event_message	text	日志或者错误消息文本
20	event_detail	text	与一个错误或者警告消息相关的详细消息文本
21	event_hint	text	与一个错误或者警告消息相关的提示消息文本
22	internal_query	text	内部生成的查询文本
23	internal_query_pos	int	内部生成的查询文本的指针式索引
24	event_context	text	这个消息产生的上下文
25	debug_query_string	text	完整的用户提供的查询字符串，用于调试。内部使用可能会修改这个字符串。
26	error_cursor_pos	int	该查询字符串中的指针式索引
27	func_name	text	这个消息产生的函数
28	file_name	text	产生该消息的内部代码文件
29	file_line	int	产生该消息的内部代码文件的行号
30	stack_trace	text	与这个消息相关的堆栈跟踪

搜索Greenplum服务器日志文件

Greenplum数据库提供一个名为gplogfilter的工具，它可以在一个Greenplum数据库日志文件中搜索匹配指定条件的项。默认情况下，这个工具在默认日志位置搜索Greenplum数据库的Master日志。例如，要显示Master日志文件的最后三行：

$ gplogfilter -n 3

1	$ gplogfilter -n 3

要同时搜索所有Segment的日志文件，可以通过gpssh工具来运行gplogfilter。例如，要显示每个Segment日志文件的最后三行：

$ gpssh -f seg_host_file
=> source /usr/local/greenplum-db/greenplum_path.sh=> gplogfilter -n 3 /gpdata/gp*/pg_log/gpdb*.log

1 2	$ gpssh -f seg_host_file => source /usr/local/greenplum-db/greenplum_path.sh=> gplogfilter -n 3 /gpdata/gp/pg_log/gpdb.log

监控Greenplum数据库日志文件

了解系统日志文件的位置和内容并且定期监控它们而不是在问题发生时才监控。

下面的表格展示了各种Greenplum数据库日志文件的位置。在文件路径中：

$GPADMIN_HOME 是操作系统用户gpadmin的家目录路径。
$MASTER_DATA_DIRECTORY是Greenplum数据库master主机的数据目录。
$GPDATA_DIR是Greenplum数据库segment主机的数据目录。
host表示segment主机的主机名。
segprefix是segment前缀。
N是segment实例数量。
date是YYYYMMDD格式的日期。

路径	描述
$GPADMIN_HOME/gpAdminLogs/	很多不同种类的日志文件，每台服务器都有的目录。$GPADMIN_HOME是gpAdminLogs/目录的默认存放位置。用户也可以在运行管理工具命令时指定一个另外的位置。
$GPADMIN_HOME/gpAdminLogs/gpinitsystemdate.log	系统初始化日志
$GPADMIN_HOME/gpAdminLogs/gpstart*date.log	启动日志
$GPADMIN_HOME/gpAdminLogs/gpstop*date.log	停止日志
$GPADMIN_HOME/gpAdminLogs/gpsegstart.pyhost:gpadmindate.log*	segment主机启动日志
$GPADMIN_HOME/gpAdminLogs/gpsegstop.pyhost:gpadmin_date.log	segment主机停止日志
$MASTER_DATA_DIRECTORY/pg_log/startup.log, $GPDATA_DIR/segprefixN/pg_log/startup.log	segment实例启动日志
$MASTER_DATA_DIRECTORY/gpperfmon/logs/gpmon..log	gpperfmon日志
$MASTER_DATA_DIRECTORY/pg_log/.csv, $GPDATA_DIR/segprefixN/pg_log/.csv	master和segment数据库日志
$GPDATA_DIR/mirror/segprefixN/pg_log/.csv	镜像segment数据库日志
$GPDATA_DIR/primary/segprefixN/pg_log/*.csv	主segment数据库日志
/var/log/messages	Linux系统消息

首先使用gplogfilter -t（--trouble）在master日志中搜索以 ERROR:、FATAL:或者PANIC:开始的消息。以WARNING开始的消息也可能提供有用的信息。

要在segment主机上搜索日志文件，可以用gpssh从master主机连接到segment主机使用 Greenplum的gplogfilter工具。用户可以通过statement_id在 segment日志中定位对应的日志项。

Greenplum数据库可以基于文件大小或当前日志文件年龄配置数据库日志的循环复写周期。log_rotation_size 配置参数设置单独一个日志文件的循环触发大小。当前日志文件大小大于等于该值时，该文件被关闭并新建另一个日志文件。log_rotation_age配置参数指定当前日志文件的循环触发年龄。当从该文件创建到目前的时间达到该设置时，创建一个新的日志文件。默认的log_rotation_age为1d（1天），当前日志文件写完后，会创建一个新的以天为单位的文件。

使用gp_toolkit

使用Greenplum数据库的管理方案gp_toolkit来查询系统目录、日志文件和操作系统环境以得到系统状态信息。 gp_toolkit方案包含一些可以用SQL命令访问的视图。gp_toolkit方案对所有数据库用户都可以访问。一些对象要求超级用户权限。用与下面类似的命令把gp_toolkit方案增加到用户的方案搜索路径中：

=> ALTER ROLE myrole SET search_path TO myschema,gp_toolkit;

1	=> ALTER ROLE myrole SET search_path TO myschema,gp_toolkit;

有关可用的管理方案视图及其用法的描述，请见 Greenplum Database Reference Guide.

用操作系统工具监控

下面的Linux/UNIX工具可以被用来评估主机性能：

iostat 允许用户监控segment主机上的磁盘活动。
top 显示操作系统进程的动态视图。
vmstat 显示内存使用统计信息。

用户可以使用gpssh在多台主机上运行相关工具。

最佳实践

实现Greenplum数据库管理员指南中的“推荐的监控和维护任务”。
在安装时运行gpcheckperf，并且在安装之后定期运行它，将其输出保存起来以对比不同时刻的系统性能。
使用所有能支配的工具来理解系统在不同负载下的行为。
检查异常事件以确定原因。
通过定期运行执行计划监控系统上的查询活动，以确保查询以最优的方式运行。
检查执行计划以确定索引是否被使用以及分区裁剪是否按照预期发生。

附加信息

gpcheckperf详细信息请见Greenplum数据库工具指南。
“推荐的监控和日常运维任务”部分详情请柬Greenplum数据库管理员指南。
Sustainable Memory Bandwidth in Current High Performance Computers. John D. McCalpin. Oct 12, 1995.
请参考www.netperf.org来使用netperf, netperf必须被安装在所有测试机器上。更多有关gpcheckperf的信息请移步命令详细出处。

用ANALYZE更新统计信息

良好查询性能的最重要的先决条件是从表的正确统计信息开始。用ANALYZE语句更新统计信息让查询规划器能生成最优的查询计划。当表被分析时，有关数据的信息被存储在系统目录表中。如果存储的信息过时，规划器可能会生成低效的执行计划。

有选择地生成统计信息

不带参数运行ANALYZE 会为数据库中所有的表更新统计信息。这样操作运行时间可能会非常长，因此不推荐这样做。当数据被改变时，使用者应该有选择地ANALYZE表或者使用analyzedb工具。

在大型表上运行ANALYZE可能需要很长时间。如果在非常大的表的所有列上运行ANALYZE 行不通，使用者可以只使用ANALYZE table(column,…)为选择的列生成统计信息。确保包括用在连接、WHERE子句、SORT子句、GROUP BY子句或者 HAVING子句中的列都被收集了统计信息。

对于一个分区表，使用者可以只在更改过的分区（例如，使用者增加一个分区）上运行ANALYZE。注意对于分区表，使用者可以在父（主）表上或者叶子节点（实际存储数据和统计信息的分区文件）上运行ANALYZE。子分区表的中间文件没有存储数据或统计信息，因此在其上运行ANALYZE没有效果。使用者可以在 pg_partitions系统目录中寻找分区表的名字：

SELECT partitiontablename from pg_partitions WHERE tablename='parent_table;

1	SELECT partitiontablename from pg_partitions WHERE tablename='parent_table;

提升统计信息质量

在生成统计信息所花的时间和统计信息的质量或者准确性之间存在着权衡。

为了允许大型表能在合理的时间内被分析完，ANALYZE会对表内容做随机采样而不是检查每一行。要对所有表列增加采样，可调整default_statistics_target配置参数。其目标值取值范围从 1到1000，默认的目标值是100。default_statistics_target变量默认会被应用到所有的列。更大的目标值会增加执行ANALYZE所需的时间，但是可以提升查询规划器的评估质量。对于带有不规则数据模式的列尤其如此。default_statistics_target可以在master或者会话级别设置，并且要求重新载入配置。

何时运行ANALYZE

在下列时机运行ANALYZE：

装载数据后；
CREATE INDEX操作后；
在显著更改底层数据的INSERT、UPDATE以及DELETE 操作之后。

ANALYZE仅在表上要求一个读锁，因此它可以与其他数据库活动并行运行。但不要在执行装载、INSERT、UPDATE、DELETE以及CREATE INDEX 操作期间运行ANALYZE。

配置统计信息自动收集

gp_autostats_mode配置参数与gp_autostats_on_change_threshold 参数一起决定何时触发自动分析操作。当自动统计信息收集被触发时，规划器会为查询增加一个ANALYZE 步骤。

gp_autostats_mode默认为on_no_stats，这会为任何没有统计信息的表上的CREATE TABLE AS SELECT、INSERT或者COPY 操作触发统计信息收集。

把gp_autostats_mode设置为on_change时，只有当受影响的行数超过由 gp_autostats_on_change_threshold定义的阈值时才会触发统计信息收集，该阈值参数的默认值为2147483647。on_change设置下能触发自动统计信息收集的操作有： CREATE TABLE AS SELECT、UPDATE、DELETE、INSERT以及COPY。 CREATE TABLE AS SELECT、UPDATE、DELETE、 INSERT以及COPY。

将gp_autostats_mode设置为none会禁用自动统计信息收集。

对于分区表，如果数据从分区表的顶层父表插入，则自动统计信息收集不会被触发。但是如果数据直接被插入在分区表的叶子表（存储数据的地方）中，则自动统计信息收集会被触发。

管理数据库膨胀

Greenplum数据库的堆表使用PostgreSQL的多版本并发控制（MVCC）存储实现。被删除或更新的行被从数据库逻辑删除，但是该行的一个不可见映像保留在表中。这些被删除的行（也被称为过期行）被存储在一个空闲空间映射文件中。运行VACUUM会把过期行标记为可以被后续插入重用的空闲空间。

如果空闲空间映射不足以容纳所有的过期行，VACUUM命令就不能从导致空闲空间映射溢出的过期行回收空间。磁盘空间只能通过运行VACUUM FULL恢复，这个操作会锁住表，逐行拷贝到文件的开头，然后截断文件。这是一种昂贵的操作，对于大型的表，它可能需要超乎想象的时间来完成。应该只在较小的表上使用这种操作。如果使用者尝试杀死VACUUM FULL操作，系统可能会损坏。

Important:

在大量的的UPDATE以及DELETE操作之后非常有必要运行VACUUM，这样可以避免运行VACUUM FULL。

如果空闲空间映射溢出并且需要恢复空间，推荐使用CREATE TABLE…AS SELECT命令把该表拷贝为一个新表，这将会创建一个新的紧凑的表。然后删除原始表并且重命名拷贝的表为原始表名。

对于频繁更新的表来说，有少量或者中等数量的过期行以及空闲空间很正常，空闲空间将随着新数据的加入而被重用。但是当表被允许增长得非常大以至于活动数据只占空间的一小部分时，该表就明显地“膨胀”了。膨胀的表要求更多磁盘存储以及可能拖慢查询执行的额外I/O。

膨胀影响堆表、系统目录和索引。

在表上定期运行VACUUM语句可以防止它们长得过大。如果表确实出现了明显的膨胀，必须使用 VACUUM FULL语句（或者可替代的过程）来紧缩文件。如果一个大型表变得明显膨胀，更好的方法是使用从数据库表移除膨胀中描述的方法之一来移除膨胀。

CAUTION:

绝不运行VACUUM FULL 并且不要在Greenplum 数据库中的大型表上运行VACUUM FULL。

检测膨胀

ANALYZE语句所收集的统计信息可以被用来计算存储一个表所要求的磁盘页面的预计数量。页面的预计数量和实际数量之间的差别就是膨胀的度量。gp_toolkit模式提供了一个gp_bloat_diag 视图，它通过预计页数和实际页数的比率来确定表膨胀。要使用这个视图，确定为数据库中所有的表都收集了最新的统计信息。然后运行下面的SQL：

gpadmin=# SELECT * FROM gp_toolkit.gp_bloat_diag; bdirelid | bdinspname | bdirelname | bdirelpages | bdiexppages |                bdidiag                ----------+------------+------------+-------------+-------------+---------------------------------------    21488 | public     | t1         |          97 |           1 | significant amount of bloat suspected(1 row)

其结果只包括发生了中度或者明显膨胀的表。当实际页面数和预期页面的比率超过4但小于10时，就会报告为中度膨胀。当该比率超过10时就会报告明显膨胀。

gp_toolkit.gp_bloat_expected_pages视图会为每个数据库对象列出其已用页面的实际数量和预期数量。

gpadmin=# SELECT * FROM gp_toolkit.gp_bloat_expected_pages LIMIT 5; btdrelid | btdrelpages | btdexppages ----------+-------------+-------------    10789 |           1 |           1    10794 |           1 |           1    10799 |           1 |           1     5004 |           1 |           1     7175 |           1 |           1(5 rows)

1	gpadmin=# SELECT * FROM gp_toolkit.gp_bloat_expected_pages LIMIT 5; btdrelid \| btdrelpages \| btdexppages ----------+-------------+------------- 10789 \| 1 \| 1 10794 \| 1 \| 1 10799 \| 1 \| 1 5004 \| 1 \| 1 7175 \| 1 \| 1(5 rows)

btdrelid是该表的对象ID。btdrelpages列报告该表使用的页面数， btdexppages列是预期的页面数。另外，报出的数字是基于表统计信息的，因此要确保在已经被更改的表上运行ANALYZE。

从数据库表移除膨胀

VACUUM命令会把过期行加入到共享的空闲空间映射中，这样这些空间能被重用。当在被频繁更新的表上定期运行VACUUM时，过期行所占用的空间可以被迅速地重用，从而防止表文件长得更大。在空闲空间映射被填满之前运行VACUUM也很重要。对于更新密集的表，用户可能需要每天运行VACUUM至少一次来防止表膨胀。

Warning: 当表出现显著膨胀时，在运行ANALYZE之前先运行VACUUM 会更好。如果采样包含空的数据页，分析膨胀表会生成不合适的统计信息，所以在分析表之前先做VACUUM 是最好的选择。

当表积累了显著的膨胀时，运行VACUUM命令并不能起到明显作用。对于小型表，运行 VACUUM FULL 能够回收导致空闲空间映射溢出的行所使用的空间并且减小表文件的尺寸。不过，VACUUM FULL语句是一种昂贵的操作，它要求一个ACCESS EXCLUSIVE 锁并且可能需要异常长的时间完成。比起在一个大型表上运行VACUUM FULL，采用另一种方法从大型文件中移除膨胀会更好。注意每一种从大型表中移除膨胀的方法都是资源密集型的，并且只应该在极端情况下完成。

第一种从大型表中移除膨胀的方法是创建一个将过期行排除在外的表拷贝，删掉原始的表并且把这个拷贝重命名为原来的表名。这种方法使用CREATE TABLE AS SELECT语句创建新表，例如：

gpadmin=# CREATE TABLE mytable_tmp AS SELECT * FROM mytable;gpadmin=# DROP TABLE mytable;gpadmin=# ALTER TABLE mytabe_tmp RENAME TO mytable;

1	gpadmin=# CREATE TABLE mytable_tmp AS SELECT * FROM mytable;gpadmin=# DROP TABLE mytable;gpadmin=# ALTER TABLE mytabe_tmp RENAME TO mytable;

第二种从表移除膨胀的方法是重新分布该表，这会把该表重建为不含过期行的表。参考步骤如下：

把表的分布列记下来。
把该表的分布策略改为随机分布：
ALTER TABLE mytable SET WITH (REORGANIZE=false) DISTRIBUTED randomly;
1
ALTER TABLE mytable SET WITH (REORGANIZE=false) DISTRIBUTED randomly;
这会为该表更改分布策略，但不会移除任何数据。该命令应该会立即完成。
将分布策略改回其初始设置：
ALTER TABLE mytable SET WITH (REORGANIZE=true) DISTRIBUTED BY (<original distribution columns>);
1
ALTER TABLE mytable SET WITH (REORGANIZE=true) DISTRIBUTED BY (<original distribution columns>);
这一步会重新分布数据。因为表之前是用同样的分布键分布的，表中的行只需要简单地在同一Segment上重写即可，同时排除过期行。

从索引移除膨胀

VACUUM命令只会从表中恢复空间。要从索引中恢复空间，需要使用REINDEX命令重建它们。 The VACUUM command only recovers space from tables. To recover the space from indexes, recreate them using the REINDEX command.

要在一个表上重建所有的索引，可运行REINDEX table_name;。要重建一个特定的索引，可运行REINDEX index_name;。REINDEX会将该索引相关 reltuples和relpages的值设置为0（零），如果要更新统计信息，则有必要在重建索引后运行ANALYZE来更新它们。

从系统目录移除膨胀

Greenplum数据库系统目录也是堆表并且也可能随着时间推移变得膨胀。随着数据库对象被创建、修改或者删除，过期行会留在系统目录中。使用gpload装载数据会加剧膨胀，因为gpload 会创建并且删除外部表。（为了避免使用gpload，推荐使用gpfdist装载数据。）

系统目录中的膨胀会导致扫描表所需的时间增加，例如在创建执行计划时需要扫描系统目录。系统目录会被频繁扫描，那么如果它们变得膨胀，整体的系统性能都会退化。

推荐每晚在系统目录上运行VACUUM，或者至少每周运行一次。同时，运行REINDEX SYSTEM 从索引中移除膨胀。此外，还可以使用带-s（--system）选项的 reindexdb工具对系统目录重建索引。在移除系统目录膨胀后，还有必要运行ANALYZE 以更新系统目录表的统计信息。

以下是Greenplum数据库系统目录维护步骤。

在系统目录表上执行REINDEX操作用于重建系统目录索引。该操作可以移除索引膨胀并提高 VACUUM性能。
Note: 当在系统目录表上执行REINDEX操作时，会锁住相应的表，进而影响到当前正在执行的查询性能。用户可以在系统的非活动窗口时间来调用REINDEX命令重建索引，以避免打扰正常业务操作的进行。
在系统目录表上执行VACUUM命令。
在系统目录表上执行ANALYZE操作来更新表的统计信息。

如果在维护窗口期内，由于时间限制需要停止目前正在进行的系统目录维护，可以运行Greenplum数据库函数 pg_cancel_backend()来安全的停止该任务。

下面的脚本在系统目录上运行REINDEX、VACUUM和 ANALYZE。

#!/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 -s -d $DBNAME
psql -tc "SELECT 'VACUUM' || $SYSTABLES" $DBNAME | psql -a $DBNAME
analyzedb -s pg_catalog -d $DBNAME

#!/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 -s -d $DBNAME

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

analyzedb -s pg_catalog -d $DBNAME

如果系统目录膨胀得很厉害，使用者就必须执行一次大强度的系统目录维护过程。采用CREATE TABLE AS SELECT 移除膨胀的方法以及重新分布数据的方法均不能被用于系统目录。使用者必须转而在计划的停机时段运行VACUUM FULL。在此期间，停止系统上所有的目录活动，VACUUM FULL会对系统目录加排他锁。定期运行 VACUUM能够预防最终不得不采用上面的高代价方法。

以下是较为彻底解决系统目录膨胀的步骤。

停止Greenplum数据库上所有系统目录操作。
在系统目录表上执行REINDEX操作来重建系统目录索引。该操作可以移除索引膨胀并提高VACUUM性能。
在系统目录表上执行VACUUM FULL操作。注意关注下面提到的注意事项。
在系统目录表上执行ANALYZE操作来更新系统目录表的统计信息。

Note: 系统目录表pg_attribute通常是这里面最大的表。如果pg_attribute 表明显膨胀，在该表上的VACUUM FULL操作会占用很长时间，此时可能需要将操作分解。以下两种情形表明pg_attribute表存在明显膨胀并可能需要运行长时间的VACUUM FULL 操作：

pg_attribute表包含大量记录。
gp_toolkit.gp_bloat_diag视图中有关pg_attribute表的诊断信息上显示该表存在明显膨胀。

从追加优化表移除膨胀

对追加优化表的处理与堆表有很大不同。尽管追加优化表允许更新、插入和删除，但它们并非为这些操作而优化，因此不推荐对追加优化表使用这些操作。如果使用者采纳这一建议并且为一次装载/多次读取 负载使用追加优化，追加优化表上的VACUUM几乎会即刻运行。

如果使用者确实在追加优化表上运行了UPDATE或者DELETE 命令，过期行会由一个辅助位图而不是空闲空间映射来跟踪。VACUUM是唯一能恢复空间的方式。在有过期行的追加优化表上运行VACUUM会通过把整个表重写成没有过期行的表以紧缩该表。不过，如果表中过期行的百分数超过了gp_appendonly_compaction_threshold 配置参数的值，则不会执行任何操作，该参数的默认值是10（10%）。每个segment上都会检查该阈值，因此VACUUM语句可能会在某些segment上对追加优化表进行紧缩而在其他segment 上不做紧缩。通过将gp_appendonly_compaction参数设置为no 可以禁用对追加表的紧缩。

Recommended Monitoring and Maintenance Tasks

This section lists monitoring and maintenance activities recommended to ensure high availability and consistent performance of your Greenplum Database cluster.

The tables in the following sections suggest activities that a Greenplum System Administrator can perform periodically to ensure that all components of the system are operating optimally. Monitoring activities help you to detect and diagnose problems early. Maintenance activities help you to keep the system up-to-date and avoid deteriorating performance, for example, from bloated system tables or diminishing free disk space.

It is not necessary to implement all of these suggestions in every cluster; use the frequency and severity recommendations as a guide to implement measures according to your service requirements.

Database State Monitoring Activities

Activity	Procedure	Corrective Actions
List segments that are currently down. If any rows are returned, this should generate a warning or alert.Recommended frequency: run every 5 to 10 minutesSeverity: IMPORTANT	Run the following query in the postgres database:`SELECT * FROM gp_segment_configuration WHERE status <> 'u';*`	If the query returns any rows, follow these steps to correct the problem:Verify that the hosts with down segments are responsive.If hosts are OK, check the pg_log files for the primaries and mirrors of the down segments to discover the root cause of the segments going down.If no unexpected errors are found, run the gprecoverseg utility to bring the segments back online.
Check for segments that are currently in change tracking mode. If any rows are returned, this should generate a warning or alert.Recommended frequency: run every 5 to 10 minutesSeverity: IMPORTANT	Execute the following query in the postgres database: `SELECT * FROM gp_segment_configurationWHERE mode = 'c';`	If the query returns any rows, follow these steps to correct the problem:Verify that hosts with down segments are responsive.If hosts are OK, check the pg_log files for the primaries and mirrors of the down segments to determine the root cause of the segments going down.If no unexpected errors are found, run the gprecoverseg utility to bring the segments back online.
Check for segments that are currently re-syncing. If rows are returned, this should generate a warning or alert.Recommended frequency: run every 5 to 10 minutesSeverity: IMPORTANT	Execute the following query in the postgres database:`SELECT FROM gp_segment_configuration WHERE mode = 'r';`	When this query returns rows, it implies that the segments are in the process of being re-synched. If the state does not change from 'r' to 's', then check the pg_log files from the primaries and mirrors of the affected segments for errors.
Check for segments that are not operating in their optimal role. If any segments are found, the cluster may not be balanced. If any rows are returned this should generate a warning or alert.Recommended frequency: run every 5 to 10 minutesSeverity: IMPORTANT	Execute the following query in the postgres database: `SELECT * FROM gp_segment_configurationWHERE preferred_role <> role;`	When the segments are not running in their preferred role, hosts have uneven numbers of primary segments on each host, implying that processing is skewed. Wait for a potential window and restart the database to bring the segments into their preferred roles.
Run a distributed query to test that it runs on all segments. One row should be returned for each primary segment.Recommended frequency: run every 5 to 10 minutesSeverity: CRITICAL	Execute the following query in the postgres database:`SELECT gp_segment_id, count() FROM gp_dist_random('pg_class') GROUP BY 1;`	If this query fails, there is an issue dispatching to some segments in the cluster. This is a rare event. Check the hosts that are not able to be dispatched to ensure there is no hardware or networking issue.
Test the state of master mirroring on a Greenplum Database 4.2 or earlier cluster. If the value is “Not Synchronized”, raise an alert or warning.Recommended frequency: run every 5 to 10 minutesSeverity: IMPORTANT	Execute the following query in the postgres database:`SELECT summary_stateFROM gp_master_mirroring;`	Check the pg_log from the master and standby master for errors. If there are no unexpected errors and the machines are up, run the gpinitstandby utility to bring the standby online. This requires a database restart on GPDB 4.2 and earlier.
Test the state of master mirroring on Greenplum Database. If the value is not “STREAMING”, raise an alert or warning.Recommended frequency: run every 5 to 10 minutesSeverity: IMPORTANT	Run the following psql command:`psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;'`	Check the pg_log file from the master and standby master for errors. If there are no unexpected errors and the machines are up, run the gpinitstandby utility to bring the standby online.
Perform a basic check to see if the master is up and functioning.Recommended frequency: run every 5 to 10 minutesSeverity: CRITICAL	Run the following query in the postgres database:`SELECT count() FROM gp_segment_configuration;`	If this query fails the active master may be down. Try again several times and then inspect the active master manually. If the active master is down, reboot or power cycle the active master to ensure no processes remain on the active master and then trigger the activation of the standby master.

Database Alert Log Monitoring

Activity	Procedure	Corrective Actions
Check for FATAL and ERROR log messages from the system.Recommended frequency: run every 15 minutesSeverity: WARNINGThis activity and the next are two methods for monitoring messages in the log_alert_history table. It is only necessary to set up one or the other.	Run the following query in the gpperfmon database:`SELECT * FROM log_alert_historyWHERE logseverity in ('FATAL', 'ERROR') AND logtime > (now() - interval '15 minutes');`	Send an alert to the DBA to analyze the alert. You may want to add additional filters to the query to ignore certain messages of low interest.

Hardware and Operating System Monitoring

Activity	Procedure	Corrective Actions
Check disk space usage on volumes used for Greenplum Database data storage and the OS.Recommended frequency: every 5 to 30 minutesSeverity: CRITICAL	Set up a disk space check.Set a threshold to raise an alert when a disk reaches a percentage of capacity. The recommended threshold is 75% full.It is not recommended to run the system with capacities approaching 100%.	Free space on the system by removing some data or files.
Check for errors or dropped packets on the network interfaces.Recommended frequency: hourlySeverity: IMPORTANT	Set up a network interface checks.	Work with network and OS teams to resolve errors.
Check for RAID errors or degraded RAID performance.Recommended frequency: every 5 minutesSeverity: CRITICAL	Set up a RAID check.	Replace failed disks as soon as possible.Work with system administration team to resolve other RAID or controller errors as soon as possible.
Run the Greenplum gpcheck utility to test that the configuration of the cluster complies with current recommendations.Recommended frequency: when creating a cluster or adding new machines to the clusterSeverity: IMPORTANT	Run gpcheck.	Work with system administration team to update configuration according to the recommendations made by the gpcheck utility.
Check for adequate I/O bandwidth and I/O skew.Recommended frequency: when create a cluster or when hardware issues are suspected.	Run the Greenplum gpcheckperf utility.	The cluster may be under-specified if data transfer rates are not similar to the following:2GB per second disk read1 GB per second disk write10 Gigabit per second network read and writeIf transfer rates are lower than expected, consult with your data architect regarding performance expectations.If the machines on the cluster display an uneven performance profile, work with the system administration team to fix faulty machines.

Catalog Monitoring

Activity	Procedure	Corrective Actions
Run catalog consistency checks to ensure the catalog on each host in the cluster is consistent and in a good state.Recommended frequency: weeklySeverity: IMPORTANT	Run the Greenplum gpcheckcat utility in each database:`gpcheckcat -O`	Run repair scripts for any issues detected.
Run a persistent table catalog check.Recommended frequency: monthlySeverity: CRITICAL	During a downtime, with no users on the system, run the Greenplum gpcheckcat utility in each database:`gpcheckcat -R persistent`	Run repair scripts for any issues detected.
Check for pgclass entries that have no corresponding pgattribute entry.Recommended frequency: monthlySeverity: IMPORTANT	During a downtime, with no users on the system, run the Greenplum gpcheckcat utility in each database:`gpcheckcat -R pgclass`	Run the repair scripts for any issues identified.
Check for leaked temporary schema and missing schema definition.Recommended frequency: monthlySeverity: IMPORTANT	During a downtime, with no users on the system, run the Greenplum gpcheckcat utility in each database:`gpcheckcat -R namespace`	Run the repair scripts for any issues identified.
Check constraints on randomly distributed tables.Recommended frequency: monthlySeverity: IMPORTANT	During a downtime, with no users on the system, run the Greenplum gpcheckcat utility in each database:`gpcheckcat -R distribution_policy`	Run the repair scripts for any issues identified.
Check for dependencies on non-existent objects.Recommended frequency: monthlySeverity: IMPORTANT	During a downtime, with no users on the system, run the Greenplum gpcheckcat utility in each database:`gpcheckcat -R dependency`	Run the repair scripts for any issues identified.

Data Maintenance

Activity	Procedure	Corrective Actions
Check for missing statistics on tables.	Check the gp_stats_missing view in each database:`SELECT FROM gp_toolkit.gp_stats_missing;`	Run ANALYZE on tables that are missing statistics.
Check for tables that have bloat (dead space) in data files that cannot be recovered by a regular VACUUM command.Recommended frequency: weekly or monthlySeverity: WARNING	Check the gp_bloat_diag view in each database: `SELECT * FROM gp_toolkit.gp_bloat_diag;`	Execute a VACUUM FULL statement at a time when users are not accessing the table to remove bloat and compact the data.

Database Maintenance

Activity	Procedure	Corrective Actions
Mark deleted rows in heap tables so that the space they occupy can be reused.Recommended frequency: dailySeverity: CRITICAL	Vacuum user tables:`VACUUM <table>;`	Vacuum updated tables regularly to prevent bloating.
Update table statistics.Recommended frequency: after loading data and before executing queriesSeverity: CRITICAL	Analyze user tables. You can use the analyzedb management utility:`analyzedb -d <database> -a`	Analyze updated tables regularly so that the optimizer can produce efficient query execution plans.
Backup the database data.Recommended frequency: daily, or as required by your backup planSeverity: CRITICAL	Run the gpbackup utility to create a backup of the master and segment databases in parallel.	Best practice is to have a current backup ready in case the database must be restored.
Vacuum, reindex, and analyze system catalogs to maintain an efficient catalog.Recommended frequency: weekly, or more often if database objects are created and dropped frequently	VACUUM the system tables in each database.Run REINDEX SYSTEM in each database, or use the reindexdb command-line utility with the -s option:`reindexdb -s <database>`ANALYZE each of the system tables:`analyzedb -s pg_catalog -d <database>`	The optimizer retrieves information from the system tables to create query plans. If system tables and indexes are allowed to become bloated over time, scanning the system tables increases query execution time. It is important to run ANALYZE after reindexing, because REINDEX leaves indexes with no statistics.

Patching and Upgrading

Activity	Procedure	Corrective Actions
Ensure any bug fixes or enhancements are applied to the kernel.Recommended frequency: at least every 6 monthsSeverity: IMPORTANT	Follow the vendor's instructions to update the Linux kernel.	Keep the kernel current to include bug fixes and security fixes, and to avoid difficult future upgrades.
Install Greenplum Database minor releases, for example 5.0.x.Recommended frequency: quarterlySeverity: IMPORTANT	Follow upgrade instructions in the Greenplum Database Release Notes. Always upgrade to the latest in the series.	Keep the Greenplum Database software current to incorporate bug fixes, performance enhancements, and feature enhancements into your Greenplum cluster.

参考

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/10e56fb7693f9f44.md

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/812829ad68eaa546.md

打赏赞(1)

标签： GreenPlum 性能监控

小麦苗

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

发表回复取消回复

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

2023年 3月
一	二	三	四	五	六	日
	1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

嘿，我是小麦，需要帮助随时找我哦

18509239930
个人微信
麦老师QQ聊天
个人邮箱
点击加入QQ群
个人微店
回到顶部

Greenplum的日常监控

简介

监控数据库活动和性能