检修性能问题

检修性能问题

这一节为在一个Greenplum数据库系统中确定和解决性能问题提供了指导。

这一主题列出了可以帮助用户确定性能问题原因的步骤。如果问题影响了一种特定的负载或查询，用户可以聚焦于调节该特定负载。如果性能问题是系统范围的，那么硬件问题、系统失效或者资源竞争可能是原因。

Parent topic: 性能管理

检查系统状态

使用gpstate 工具来确定失效的Segment。当Segment实例宕机时， Greenplum数据库系统将会引发性能退化，因为其他主机必须负担起宕掉的Segment的责任。

失效的Segment可能表明有硬件失效，例如一个失效的磁盘驱动器或者网卡。 Greenplum数据库提供了硬件验证工具gpcheckperf来确定有硬件问题的Segment主机。

检查活动会话（负载）

pg_stat_activity 系统目录视图为每个服务器进程展示了一行，它显示数据库OID、数据库名、进程ID、用户OID、用户名、当前查询、当前查询开始执行的时间、进程开始时间、客户端地址和端口号。要获得大部分有关当前系统负载的信息，可以作为数据库超级用户查询这个视图。例如：

SELECT * FROM pg_stat_activity;

注意信息不会立刻更新。

检查锁（竞争）

pg_locks系统目录视图允许用户查看有关未解除的锁的信息。如果一个事务在一个对象上持有一个锁，任何其他查询在能够继续之前都必须等待该锁被释放。这对于用户来说可能就好像一个查询悬而不决。

在pg_locks中检查未授予的锁，以便帮助确定数据库客户端会话之间的竞争。 pg_locks 提供了数据库系统中所有锁的一个全局视图，而不只是那些与当前数据库相关的锁。用户可以把它的relation列与pg_class.oid连接在一起以确定被锁住的关系（例如表），但这只对当前数据库中的关系能正确地工作。用户可以把pid列连接到pg_stat_activity.procpid以查看更多会话持有或者等待持有锁的信息。例如：

SELECT locktype, database, c.relname, l.relation, 
l.transactionid, l.pid, l.mode, l.granted, 
a.current_query 
        FROM pg_locks l, pg_class c, pg_stat_activity a 
        WHERE l.relation=c.oid AND l.pid=a.procpid 
        ORDER BY c.relname;

如果用户把资源组用于负载管理，在一个组中等候的查询也会显示在pg_locks中。要查看一个资源组有多少查询正在等待运行，可使用 gp_resgroup_status 系统目录视图。例如：

SELECT * FROM gp_toolkit.gp_resgroup_status;

同样的，如果用户把资源队列用于负载管理，在一个队列中等候的查询也会显示在 pg_locks。要查看一个资源队列中有多少查询正在等待运行，可使用 gp_resqueue_status 系统目录视图。例如：

SELECT * FROM gp_toolkit.gp_resqueue_status;

检查查询状态和系统利用

用户可以使用ps、top、iostat、vmstat、 netstat之类之类的系统监控工具监控Greenplum数据库阵列中主机上的数据库活动。这些工具能够帮助确定当前运行在系统上的Greenplum数据库进程（postgres 进程）以及资源占用最多（CPU、内存、磁盘I/O或者网络活动）的任务。查看这些统计信息以确定降低数据库性能的查询，它们会让系统超载并且消耗极多的资源。Greenplum数据库的管理工具gpssh允许用户在多个主机上同时运行这些系统监控命令。

用户可以创建并使用Greenplum数据库的session_level_memory_consumption视图，它为在Greenplum数据库上运行查询的会话提供有关当前内存利用和闲置时间的信息。有关该视图的信息请见查看会话内存使用信息.

用户可以启用一个专用数据库gpperfmon，运行在每个Segment主机上的数据收集代理把查询和系统的使用指标保存在其中。参考Greenplum数据库管理工具参考指南中gperfmon_install的管理使用建议来创建gpperfmon数据库以及管理代理。gpperfmon数据库以及管理代理的帮助请参考Greenplum数据库参考指南。

检修问题查询

如果一个查询执行得很糟糕，查看它的查询计划以帮助确定问题。 EXPLAIN命令展示一个给定查询的查询计划。更多有关阅读查询计划并且确定问题的信息请见查询分析。

当查询执行期间发生内存不足事件时，Greenplum数据库内存核算框架会报告事件发生时运行的每一个查询的详细内存消耗。这些信息被写入到Greenplum数据库的Segment日志中。

研究错误消息

Greenplum数据库的日志消息被写入到Master或Segment的数据目录中pg_log 子目录下的文件中。由于Master的日志文件包含了大部分的信息，用户应该总是先检查它。日志文件会每日滚动并且使用下面的命名习惯：gpdb-YYYY-MM-DD_hhmmss.csv. 要在Master主机上定位日志文件：

$ cd $MASTER_DATA_DIRECTORY/pg_log

日志行的格式：

timestamp | user | database | statement_id | con#cmd# 
|:-LOG_LEVEL: log_message

用户可能想把搜索聚焦在WARNING、 ERROR、FATAL或者PANIC日志级别的消息上。用户可以使用Greenplum的工具gplogfilter在Greenplum数据库的日志文件中搜索。例如，在Master主机上运行下列命令时，它会在标准日志位置检查有问题的日志消息：

$ gplogfilter -t

要在Segment日志文件中搜索相关的日志项，用户可以使用 gpssh在Segment主机上运行gplogfilter。可以根据 statement_id 或者 con#（会话标识符）确定对应的日志项。例如，要在Segment日志文件中搜索含有字符串 con6的日志消息并且把输出保存到一个文件：

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