检修性能问题

性能问题分析策略¶

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

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

查看系统状态¶

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

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

查看活动会话（负载）¶

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.pid以查看更多会话持有或者等待持有锁的信息。例如：

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;

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

SELECT * FROM sc_toolkit.sc_resgroup_status;

查看查询状态和系统利用¶

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

检查有问题的查询¶

如果一个查询执行得很糟糕，查看它的查询计划以帮助确定问题。

EXPLAIN命令展示一个给定查询的查询计划。

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

研究错误消息¶

SeaboxMPP数据库的日志消息被写入到Coordinator或executor的数据目录中sd_log子目录下的文件中。由于Coordinator的日志文件包含了大部分的信息，用户应该总是先检查它。

日志文件会每日滚动并且使用下面的命名习惯：scdb-YYYY-MM-DD_hhmmss.csv.要在Coordinator主机上定位日志文件：

$ cd $COOR_DATA_DIRECTORY/sd_log

日志行的格式：

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