金仓数据库KWR使用说明

1.KWR性能报告介绍

KWR是Kingbase Workload Repertories的简称，中文全称是自动负载信息库，是一种性能收集和分析工具，提供了一个时间段内整个系统的报表数据，里面包含了常见的等待时间分析，TOP SQL,TOP EVENT等。通过参数设置可以定期生成指定格式的KWR性能报告，可以清理指定日期以外的快照。
kwr每小时采集一次KingbaseES的统计数据生成快照数据，快照数据默认保留8天。快照数据主要来源是：

• 累计式等待事件（sys_stat_waitaccum视图）
• Top SQL（sys_stat_statements视图）
• Schema对象统计信息（sys_stat_*, sys_statio_*视图）

2.部署KWR性能报告功能

2.1.修改配置文件

vi /home/kingbase/KingbaseES/V8/data/kingbase.conf

shared_preload_libraries = 'sys_kwr,sys_stat_statements'

sys_stat_statements.track='top'
track_sql=on
track_wait_timing=on
track_io_timing=on
track_functions='all'
track_activities=on
sys_kwr.enable=on

参数解释：

track_activities：开启记录等待事件，默认为on。
track_wait_timing：开启累积式等待事件记录等待时间的功能，默认为off
track_io_timing：开启IO计时统计功能，默认为off
track_functions：开启函数统计功能，默认为
sys_stat_statements.track：跟踪统计SQL语句的访问，推荐用 ‘top’，默认为’none’
sys_kwr.enable：自动对收集到的数据生成快照并保存到kwr库里
其他参数一般情况下使用默认值即可：
sys_kwr.topn：kwr报告显示topn条件记录，默认20条
sys_kwr.history_days：kwr快照数据保留天数，默认8天
sys_kwr.interval：kwr自动采集快照的间隔，默认60分钟
sys_stat_statements.track_parse：sys_stat_statements记录parse次数和时间，默认
开启
sys_stat_statements.track_plan：sys_stat_statements记录plan次数和时间，默认开启

2.2.使配置文件中参数生效

重启数据库
sys_ctl -D /home/kingbase/KingbaseES/V8/data restart

2.3.创建KWR扩展

ksql test system连接数据库
create extension sys_kwr;

3.使用KWR快照功能

3.1.创建KWR快照

连接数据库执行下面命令创建KWR快照：
select * from perf.create_snapshot();

3.2.管理快照

3.2.1.快照查询

快照查询通过下面的语句进行查找
select * from perf.kwr_snapshots;

3.2.2.手动创建快照

手动快照则是由 DBA 通过 SQL 语句执行而生成快照，执行 perf.create_snapshot() 函数，返回快照编号：

select * from perf.create_snapshot();

3.2.3.自动快照

创建快照有2种不同的方式，自动快照和手工快照。
自动快照由后台进程周期性的生成快照，需要配置 kingbase.conf 参数：

sys_kwr.interval=10

修改参数后，重启 KES 服务器:

sys_ctl -D /home/kingbase/KingbaseES/V8/data restart

sys_kwr.interval是自动快照间隔，默认 60 分钟一次，这里设置为 10 分钟一次。后台进程 kwr_collector 就会自动每 10 分钟采集一次快照。
这些快照以表的形式存在于当前库，可以通过 SELECT 去查看里面的内容。

3.2.4.清理快照

1.select perf.reset_snapshots();        #清空所有快照
2.select perf.drop_snapshots($begin_snap_id,$end_snap_id);			#清除指定范围的快照

可以通过函数perf.reset_snapshots()清理所有快照，也可以 drop extension sys_kwr 删除插件后再重新创建插件的方式清理全部的快照。

3.2.5.定期清理快照

sys_kwr.history_days参数是kwr快照数据保留天数，默认8天
这里根据自己需要修改保留天数。

4.生成KWR报告

4.1生成text格式报告

4.1.1.使用perf.kwr_report()函数

调用 perf.kwr_report(start_id,end_id) 来生成 text 报告，这个函数默认生成text文本格式的报告，如果生成html的报告需要加上函数参数’html’,此函数生成的报告默认保存在data/sys_log目录下。

select * from perf.kwr_report(start_id,end_id);

start_id：起始快照ID
end_id：结束快照ID

4.1.2使用perf.kwr_generate_report()函数

调用perf.kwr_generate_report(start_id,end_id,format)来生成text报告，并且可以指定报告输出位置。

start_id：起始快照ID
end_id：结束快照ID
format：报告的格式，只支持’text’和’html’格式，建议使用’html’格式

ksql -Usystem -dtest -c "select * from perf.kwr_generate_report(start_id,end_id,'text')" > /home/kingbase/kwr_report/kwr_report_02_24_10_10.text

4.1.3使用perf.kwr_report_to_file()函数

调用perf.kwr_report_to_file (start_id,end_id,format,path)来生成指定位置指定文件名的text报告。

start_id：起始快照ID
end_id：结束快照ID
format：报告的格式，只支持’text’和’html’格式，建议使用’html’格式
path：在服务器上保存报告文件的全路径，必须有写文件的权限

select * from perf.kwr_report_to_file(start_id,end_id,’text’,’/home/kingbase/kwr_report/kwr_report_02_24_10_15.text);

4.2.生成html格式报告

4.2.1.使用perf.kwr_report()函数

调用 perf.kwr_report(start_id,end_id,format) 来生成 html 报告，生成的报告默认保存在data/sys_log目录下。

select * from perf.kwr_report(start_id,end_id,’html’);

4.2.2.使用perf.kwr_generate_report()函数

调用perf.kwr_generate_report(start_id,end_id,format)来生成html报告，并且可以指定报告输出位置。

ksql -Usystem -dtest -c "select * from perf.kwr_generate_report(start_id,end_id,'html')" > /home/kingbase/kwr_report/kwr_02_24_10_24.html

4.2.3.使用perf.kwr_report_to_file()函数

调用perf.kwr_report_to_file (start_id,end_id,format,path)来生成指定位置指定文件名的text报告。

select * from perf.kwr_report_to_file(start_id,end_id,’html’,’/home/kingbase/kwr_report/kwr_report_02_24_10_28.html’);

5.KWR报告分析

5.1.KWR之DB Time

DB Time主要用来判断当前系统有没有相关瓶颈，是否较为频繁访问系统导致等待时间很长？一般来说，Elapsed时间乘以CPU个数如果大于DB Time，就是正常的，系统压力不大，反之就说明压力较大，例子如图，3877.25*1很明显大于0.01，所以说明系统压力很小

5.2.KWR之load_profile

Load profile指标主要用来显示当前系统的一些指示性能的总体参数，这里介绍一些WAL size，用来显示平均每秒的日志尺寸和平均每个事务的日志尺寸，有时候可以结合Transactions这个每秒事务数，分析当前事务的繁忙程度
如图，平均每秒的事务数Transactions非常小，说明系统压力非常小，一般来说Transactions不超过200都是正常的，或者200左右都是正常的，超过1000就是非常繁忙了，再看看平均每秒的日志尺寸是个位数的，平均每个事务的日志尺寸是个位数的，说明了系统访问不是很频繁，而单个业务是比较复杂的，如果反过来，平均每秒日志尺寸比平均每秒事务日志尺寸大很多，说明系统访问很频繁，而业务比较简单，不需要响应很久

5.3.KWR之top 10 events

Top 10 Foreground WaitEvents，等待事件是衡量数据库优化情况的重要指标，通过观察Wait Event和%DB time两列就可以直观看出当前数据库的主要等待事件
如图可以看出系统主要是CPU被占用太多了