目录

6.1. 监控错误和警报

6.1.1. 使用 kbbadger

6.2. 监控数据库性能

6.3. 监控锁

6.3.1. 使用 sys_locks

6.3.2. 监控死锁

6.4. 监控等待事件

6.4.1. 等待事件

6.5. 性能监控视图

---

定期监视数据库的操作很重要。这样做不仅可以通知您尚未引起注意的错误，还可以让您更好地了解数据库的正常操作。反过来，熟悉正常行为可以帮助您识别何时出现问题。

监控错误和警报

您可以监控数据库错误和警报以预防、检测和解决问题。

监控数据库性能

监控性能包括监控锁和等待事件以及查询一组数据字典视图。

6.1. 监控错误和警报

可以监控数据库错误和警报以预防、检测和解决问题。对于数据库运行过程中的错误，除了人工去查看数据库运行过程中产生的日志文件外，也可以使用 kbbadger 工具自动分析。

6.1.1. 使用 kbbadger

Kbbadger可以分析大型的日志文件。当日志文件足够长时，kbbadger可以自动检测日志文件的格式（syslog，stderr，csvlog或jsonlog）。

由kbbadger生成的所有图表都是可缩放的并且可单独下载为PNG文件。另外，在生成的报告中SQL查询将突出显示。

Kbbadger生成的报告中包含的关于SQL查询的信息有：

• 总体统计

• 占用时间最多的查询

• 最常见的查询

• 最常见的错误

• 查询时间直方图

• 会话时间直方图

• 参与顶级查询的用户

• 涉及顶级查询的应用程序

• 生成最多取消的查询

• 大多数查询已取消

• 最耗时的准备/绑定查询

报告也会提供每小时的统计图表，其内容包括：

• SQL查询统计信息

• 临时文件统计

• 检查点统计

• 自动vacuum和自动分析统计

• 已取消查询

• 错误事件（死机、致命、错误和警告）

• 错误的类分布

在kbbadger的使用过程中，可以使用命令行选项来启用并行处理模式从而加快日志解析速度，使用-j命令行选项来指定解析使用的CPU核心数，使用-J命令行选项来并行解析的文件数，两个选项可以同时使用。另外，可以使用-A命令行选项来调整直方图的粒度。默认情况下，它们将报告每小时发生的每个主要查询/错误的平均值。

Kbbadger使用方法

1. 配置kingbase.conf

在开始之前，必须在kingbase.conf中启用并设置一些配置指令。

您必须首先启用SQL查询日志记录才能进行解析：

log_min_duration_statement = 0

在这里，每条语句都会被记录，在繁忙的服务器上，您可能需要增加此值以仅记录持续时间较长的查询。请注意，不要启用log_statement，因为kbBadger不会解析它的日志格式并且如果您将log_statement设置为'all'，则不会通过log_min_duration_statement指令记录任何内容。如果要保证系统性能，也可以使用log_duration来仅提供有关持续时间和查询数量的报告。有关更多信息，请参见下一章。

kbBadger支持任何设置到kingbase.conf文件的log_line_prefix中的自定义格式，只要它指定时间转义序列（％t，％m或％n）和与进程相关的转义序列（％p或％c）。

例如：

--使用“ stderr”日志格式，log_line_prefix必须至少为：
log_line_prefix = '%t [%p]: '

--日志行前缀可以添加用户，数据库名称，应用程序名称和客户端IP地址，如下所示：
log_line_prefix = '%t [%p]: user=%u,db=%d,app=%a,client=%h '

--或用于syslog日志文件格式：
log_line_prefix = 'user=%u,db=%d,app=%a,client=%h '

--stderr输出的日志行前缀也可以是：
log_line_prefix = '%t [%p]: db=%d,user=%u,app=%a,client=%h '

--或用于syslog输出：
log_line_prefix = 'db=%d,user=%u,app=%a,client=%h '

--您也可以在kingbase.conf中启用其他参数，以从日志文件中获取更多信息：
log_checkpoints = on
log_connections = on
log_disconnections = on
log_lock_waits = on
log_temp_files = 0
log_autovacuum_min_duration = 0
log_error_verbosity = default

注意

数据库日志中的内容必须为英文，否则kbbadger可能无法解析日志中的内容：

lc_messages='en_US.UTF-8'

1. 使用kbBadger生成统计信息

kbbadger /var/log/kingbase.log
kbbadger /var/log/kingbase.log.2.gz /var/log/kingbase.log.1.gz /var/log/kingbase.log
kbbadger /var/log/kingbase/kingbase-2012-05-*
kbbadger --exclude-query="^(COPY|COMMIT)" /var/log/kingbase.log
kbbadger -b "2012-06-25 10:56:11" -e "2012-06-25 10:59:11" /var/log/kingbase.log
cat /var/log/kingbase.log | kbbadger -
kbbadger --prefix '%t [%p]: user=%u,db=%d,client=%h ' /sys_log/kingbase-2012-08-21*
kbbadger --prefix '%m %u@%d %p %r %a : ' /sys_log/kingbase.log
# Log line prefix with syslog log output
kbbadger --prefix 'user=%u,db=%d,client=%h,appname=%a' /sys_log/kingbase-2012-08-21*
# Use my 8 CPUs to parse my 10GB file faster, much faster
kbbadger -j 8 /sys_log/kingbase-10.1-main.log

详细请参见 –help

1. 举例说明

$ ./kbbadger ./ sys_log/kingbase-2019-10-26_1544* -f stderr -J 12 -j 32
[========================>] Parsed 283210387 bytes of 283210387 (100.00%),
queries: 327810, events: 51
LOG: Ok, generating html report...

生成的统计信息效果图如下：

 

 

 

6.2. 监控数据库性能

监控性能包括监控锁和等待事件以及查询一组数据字典视图。

监控锁

锁是防止访问同一资源的事务之间的破坏性交互的机制。资源可以是用户对象，例如表和行，也可以是用户不可见的系统对象，例如内存中的共享数据结构和数据字典行。

监控等待事件

等待事件是由服务器进程递增的统计信息，表明它必须等待事件完成才能继续处理。会话可能出于多种原因等待，包括等待更多输入、等待操作系统完成诸如磁盘写入之类的服务，或者它可能等待锁定或闩锁。

性能监控数据字典视图

您可以查询一组性能视图来监控 KES 数据库实例。

6.3. 监控锁

锁是防止访问同一资源的事务之间进行破坏性交互的机制。资源可以是用户对象，例如表和行，也可以是用户不可见的系统对象，例如内存中的共享数据结构和数据字典行。

KES 数据库在执行 SQL 语句时会自动获取并管理必要的锁，因此您无需关心这些细节。但是，数据库还允许您手动锁定数据。

当两个或更多用户正在等待彼此锁定的数据时，可能会发生死锁。死锁会阻止某些事务继续工作。KES 数据库自动检测死锁情况并通过回滚死锁中涉及的一条语句来解决它们，从而释放一组冲突的行锁。 KES 数据库旨在避免死锁，它们并不常见。大多数情况下，它们发生在事务显式覆盖数据库的默认锁定时。死锁会影响数据库的性能，因此 KES 提供了一些脚本和视图，使您能够监控锁。

6.3.1. 使用 sys_locks

所有活动事务持有的监控锁的基本配置即为系统视图 sys_locks。这个视图为每个可加锁的对象、已请求的锁模式和相关事务包含一行记录。

test=# select * from sys_locks;
-[ RECORD 1 ]------+----------------
locktype           | relation
database           | 16384
relation           | 12168
page               |
tuple              |
virtualxid         |
transactionid      |
classid            |
objid              |
objsubid           |
virtualtransaction | 3/744
pid                | 224515
mode               | AccessShareLock
granted            | t
fastpath           | t

6.3.2. 监控死锁

显式锁定的使用可能会增加死锁的可能性，死锁是指两个（或多个）事务相互持有对方想要的锁。

例如，如果事务 1 在表 A 上获得一个排他锁，同时试图获取一个在表 B 上的排他锁， 而事务 2 已经持有表 B 的排他锁，同时却正在请求表 A 上的一个排他锁，那么两个事务就都不能进行下去。KES 能够自动检测到死锁情况 并且会通过中断其中一个事务从而允许其它事务完成来解决这个问题（具体哪个事务会被中 断是很难预测的，而且也不应该依靠这样的预测）。

要注意死锁也可能会作为行级锁的结果而发生（并且因此，它们即使在没有使用显式锁定的情况下也会发生)。考虑如下情况，两个并发事务在修改一个表。第一个事务执行：

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 11111;

这样就在指定帐号的行上获得了一个行级锁。然后，第二个事务执行：

UPDATE accounts SET balance = balance + 100.00 WHERE acctnum = 22222;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;

第一个 UPDATE 语句成功地在指定行上获得了一个行级锁，因此它成功更新了该行。 但是第 二个 UPDATE 语句发现它试图更新的行已经被锁住了，因此它等待持有该锁的事务结束。事 务二现在就在等待事务一结束，然后再继续执行。现在，事务一执行：

UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 22222;

事务一试图在指定行上获得一个行级锁，但是它得不到：事务二已经持有了这样的锁。所以 它要等待事务二完成。因此，事务一被事务二阻塞，而事务二也被事务一阻塞：一个死锁。 KES 将检测这样的情况并中断其中一个事务。

6.4. 监控等待事件

可以查看系统视图 sys_stat_activity 来进行查看每个连接上的等待事件。

注意

当前执行的查询语句和等待事件状态需要在开启 track_activities 参数的情况下才可以查看。开启该参数会带来一定的性能损耗。

sys_stat_activity 视图结构如下：

表 6.4.2 视图结构

字段名	类型	说明
datid	oid	数据库OID
datname	name	数据库名称
pid	integer	服务于这个连接的进程ID
usesysid	oid	用户ID
usename	name	用户名
application_name	text	应用名称
client_addr	inet	客户端地址
client_hostname	text	客户端主机名
client_port	integer	客户端端口号
backend_start	timestamp with time zone	该连接的启动时间
xact_start	timestamp with time zone	当前事务开始时间
query_start	timestamp with time zone	当前查询开始时间
state_change	timestamp with time zone	当前状态改变时间
wait_event_type	text	当前等待事件的类型
wait_event	text	当前等待事件
state	text	当前的状态
backend_xid	xid	这个后端的顶层事务标识符
backend_xmin	xid	这 个进程的当前事务被启动的时间
query	text	当前查询语句
backend_type	text	后端进程的类型

其中，state为当前连接的状态，其可能的值主要有：

• active：后端正在执行一个查询。

• idle：后端正在等待一个新的客户端命令。

• idle in transaction：后端在一个事务中，但是当前没有正在执行一个查询。

• idle in transaction (aborted)：这个状态与 idle in transaction 相似，不过在该事务中的一个语句导致了一个错误。

• fastpath function call：后端正在执行一个 fast-path 函数。

• disabled：如果在这个后端中 track_activities 被禁用，则报告这个状态。

注意

如果一个查询或者事务执行的时间过长而一直没有结束，很有可能会拖累整个系统的性能表现，需要具体分析问题的原因并采取合适的办法。

6.4.1. 等待事件

等待事件是数据库内部记录的一种统计信息，该信息出现表明数据库的服务进程必须在等待事件完成后才能继续处理。等待事件揭示了可能影响性能的各种问题症状，比如缓冲区中争用、锁争用等。

sys_stat_activity 里记录的等待事件是瞬时信息，没有对等待事件的时间进行累计，所以量化等待事件上存在一些问题。用户可以考虑多次人工采样来收集等待事件信息，如果在等待的连接较多，则需要等待事件对系统性能造成了较大影响，需要做具体分析。

注意

当前执行的查询语句和等待事件状态需要在开启 track_activities 参数的情况下才可以查看。开启该参数会带来一定的性能损耗。

sys_stat_activity 视图中，wait_event_type 和 wait_event 字段记录了等待时间相关的内容。当一个会话处于等待状态时，wait_event 与 wait_event_type 两列非空，表示会话正在等待的事件和等待事件类型。

KES 的等待事件分类包括：

• LWLock：轻量级锁

• Lock：重量级锁

• BufferPin：数据缓冲区等待

• Activity：后台辅助进程活动等待

• Client：客户端等待

• Extension：扩展插件等待

• IPC：进程间通讯等待

• TimeOut：超时等待

• IO：IO 等待

每一个等待事件的名称和产生的原因，可以参考《KingbaseES 等待事件》。

查询等待事件示例：

test=# select * from sys_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid            |
datname          |
pid              | 236705
usesysid         |
usename          |
application_name |
client_addr      |
client_hostname  |
client_port      |
backend_start    | 2022-05-27 11:23:30.833022+08
xact_start       |
query_start      |
state_change     |
wait_event_type  | Activity
wait_event       | AutoVacuumMain
state            |
backend_xid      |
backend_xmin     |
query            |
backend_type     | autovacuum launcher

6.5. 性能监控视图

您可以通过查询一组性能视图来监控 KES 数据库实例的运行状态。

在使用性能视图的数据时，你必须了解这些信息并非是实时更新的。每个独立的服务器进程只在进入闲置状态之前才向统计收集器传送新的统计计数；因此正在进行的查询或事务并不影响显示出来的总数。同样，收集器本身也最多每 500 毫秒发送一次新的报告。因此显示的信息总是落后于实际活动。但是由 track_activities 收集的当前查询信息总是最新的。

当一个服务器进程被要求显示任何这些统计信息时，它首先取得收集器进程最近发出的报告并且接着为所有统计视图和函数使用这个快照，直到它的当前事务的结尾。因此只要你继续当前事务，统计数据将会一直显示静态信息。相似地，当任何关于所有会话的当前查询的信息在一个事务中第一次被请求时，这样的信息将被收集。并且在整个事务期间将显示相同的信息。这是一种特性而非缺陷，因为它允许你在该统计信息上执行多个查询并且关联结果而不用担心那些数字会在你不知情的情况下改变。但是如果你希望用每个查询都看到新结果，要确保在任何事务块之外做那些查询。或者，你可以调用 sys_stat_clear_snapshot()，那将丢弃当前事务的统计快照（如果有）。下一次对统计性信息的使用将导致获取一个新的快照。

一个事务也可以在视图 sys_stat_xact_all_tables、sys_stat_xact_sys_tables、sys_stat_xact_user_tables 和 sys_stat_xact_user_functions 中看到它自己的统计信息（还没有被传送给收集器）。这些数字并不像上面所述的那样行动，相反它们在事务期间持续被更新。

关于每个性能视图的描述，可以参考《KingbaseES 动态性能视图参考手册》。

实时刷新的性能视图：

非实时刷新的性能视图：

比如，通过 sys_stat_bgwriter 视图参考后台写和检查点的统计信息：

test=# select * from sys_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed     | 344
checkpoints_req       | 0
checkpoint_write_time | 3749
checkpoint_sync_time  | 1
buffers_checkpoint    | 37
buffers_clean         | 0
maxwritten_clean      | 0
buffers_backend       | 0
buffers_backend_fsync | 0
buffers_alloc         | 82
stats_reset           | 2022-05-30 09:35:50.464433+08

通过 sys_stat_database 查看每个库的事务和元组统计信息：

test=# select * from sys_stat_database;
-[ RECORD 1 ]---------+------------------------------
datid                 | 16384
datname               | test
numbackends           | 1
xact_commit           | 44930
xact_rollback         | 15
blks_read             | 59142
blks_hit              | 11122493
tup_returned          | 160318834
tup_fetched           | 1491817
tup_inserted          | 1380883
tup_updated           | 7324
tup_deleted           | 35999
conflicts             | 0
temp_files            | 288
temp_bytes            | 2359296
deadlocks             | 0
checksum_failures     |
checksum_last_failure |
blk_read_time         | 8225.142
blk_write_time        | 6.066
stats_reset           | 2022-05-16 18:06:12.851563+08