[转帖]人大金仓- KWR 报告初体验

【本文正在参与炫"库"行动-人大金仓有奖征文】

开发者请集结丨炫“库”行动——2021人大金仓征文大赛悬赏万元等你来！

最近一直在研究 Oracle 的 AWR 报告，觉得它功能很强大，尤其是 DB Time 模型和等待事件能够让性问题的分析变得十分方便，再也不需要依赖大量的运维脚本去分析和定位问题了。

偶然之间，发现人大金仓的 Kingbase ES 也提供了一个类似的功能，叫 KWR 报告，深感意外。下面我们就来一起来探索一下吧。

1. 什么是AWR

---

首先我们先了解一下什么是AWR。它是Oracle 10g 版本推出的一个特性，全称叫Automatic Workload Repository（自动负载信息库）。AWR自动采集性能统计相关的指标，存储为性能快照（Snapshots），通过对比两次快照收集到的统计信息，来生成性能报告，帮助DBA对数据库进行性能调优。

AWR 的基本原理：数据库实例运行过程中不断产生一些统计数据，比如对某个表的访问次数，数据页的内存命中次数，某个等待事件发生的次数和总时间，SQL 语句的解析时间等，这些统计数据被一个叫做 MMON 的后台性能监控进程周期性地（默认每小时）自动采集，存储到 AWR 快照库里面，默认保留 8 天。

当出现性能问题的时候，DBA 执行 awrrpt.sql 脚本，指定快照范围，就可以生产相应时间范围内的 AWR 报告，定位性能问题的根本原因。

以下是一个 AWR 报告的示例：

2. 安装人大金仓 KES

---

去人大金仓公司网站上下载数据库的试用版：

人大金仓-KingbaseES V8 R6

我们选择的 KingbaseES V8 R6，下载一个单机版，以及开发版本的 License（后面安装时会用到）：

下载完成后，将安装包拷贝到 X86-64 平台的 Linux 虚拟机上，可以将 ISO 文件 mount 到文件系统，或者在 Windows 上用 winrar 解压后再拷贝过去也行。

安装程序是 SETUP/INSTALL.BIN，chmod +x 添加执行权限，运行后一路下一步，中间输入刚才下载的 license-开发版.dat，按照提示初始化数据库实例即完成安装过程。

在此我们将 KES 数据库安装到 kes_svr 目录，数据在 kes_data 目录：

3. 生成 KWR 报告

---

因为 KWR 依赖数据库内部的统计数据，所以最好通过配置文件 kes_data/kingbase.conf 开启全部的统计开关：

编辑 ~/.bash_profile 配置环境变量，将 KES 的 bin 目录添加到 PATH，并添加 2个快捷命令：

启动 KES 数据库，ksql 连接进去，创建 sys_kwr 插件：

创建性能快照 - 1，随便执行一些SQL语句，然后再次创建快照 - 2：

用刚才创建的 2 个快照产生 KWR 报告：

如果，我是说如果，这个报告是中文的，就太好了。据说中国的空间站上的显示屏上都是中文的菜单，希望下次看到这个报告时，它是中文的！

4. 管理KWR快照

---

快照是 KWR 的核心数据，整个 KWR 报告就是对采集到的快照数据进行挖掘，找出可能的性能问题的根本原因。

快照默认每个小时采集一次，保留八天，也可以通过参数去设置采集频率和保留时长。这样当发现过去某个时间段有性能问题的时候，可以通过KWR快照产生那段时间范围内的性能报告，回溯性能问题。

• 快照查询

快照的查询通过 perf.kwr_snapshots 即可：

• 自动快照

创建快照有2种不同的方式，自动快照和手工快照。

自动快照由后台进程周期性的生成快照，需要配置 kingbase.conf 参数：

sys_kwr.nable 参数默认是关闭的。

sys_kwr.interval是自动快照间隔，默认 60 分钟一次，这里设置为 10 分钟一次。

修改参数后，重启 KES 服务器，后台进程 kwr_collector 就会自动每 10 分钟采集一次快照。从 14:17 到 15:47 一共产生了 10 个快照：

这些快照以表的形式存在于当前库，可以通过 SELECT 去查看里面的内容，不过其内容比较基础，分析起来有一定难度。建议还是通过 KWR 报告去查看各性能指标。

• 手动快照

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

手动快照不受自动快照间隔配置参数的影响，随时可以产生。

• 快照清理

如果之前产生的快照不想要了，可以执行 perf.reset_snapshots()  函数清理全部的快照：

也可以 drop extension sys_kwr 删除插件后再重新创建插件的方式清理全部的快照。

5. 生成 KWR 报告

---

有了 KWR 快照后，就可以随时生成 KWR 报告了。

• 生成 TEXT 格式报告

调用 perf.kwr_report(snap_1, snap_2) 来生成 text 报告：

报告的内容很长，这里不显示了，需要的朋友可以自己去实践一下。

• 生成 HTML 格式报告

TEXT 报告的可读性稍微差一些，可以调用 perf.kwr_report(snap_1, snap_2, ‘html’) 来生成 html 报告，它是网页形式的，可读性非常好：

用 Firefox 打开 KWR_1_2.html：

感觉还是 HTML 格式的报告更便于阅读一些。不过 TEXT 格式的报告直接在ksql里就能看，看自己实际的需求吧。

• 将报告存为磁盘文件

也通过 perf.kwr_report_to_file()  函数可以将生成的 KWR 报告保存到磁盘上：

感觉这功能还挺方便的，不需要使用 Linux 的管道符操作了。这个功能 Oracle 好像没有。

6. 分析 KWR 报告

---

为了后面的演示更有针对性，我们在KES数据库不进行任何优化的情况下，运行 TPCC 测试 2 分钟以便让数据库产生一些负载，在此期间生成两个快照，最后生成 KWR 报告，结合该报告来分析重要的一些性能指标。

• 报告结构

人大金仓的 KWR 报告主要分 3 部分：

1）报告头

这部分主要是列出数据库实例的版本、运行环境和快照信息。

2）报告摘要

这是整个报告的精华所在，大部分的性能问题都能够从这部分报告里看到。看这部分内容的时候，如果有必要，还可以结合后面的详细报告具体分析问题。

这部分最重要的几个报告是：负载统计表（Load Profile）、实例效率百分比（Instance Efficiency Percentages）、前台等待事件（Top 10 Foreground Wait Events）、主机环境统计（Host CPU、Host IO、Host Memory、Host Network）。

3）报告主体

报告主体提供了更加全面的性能指标，主要包括：DB Time 模型、等待事件、SQL 报文统计、TOP SQL 统计、后台写统计、数据库对象统计和配置参数。

• 分析 DB Time

DB Time，就是数据库时间，它用来衡量数据库的繁忙程度，DB Time 越高，说明数据库业务越繁忙。

如报告所示，在 2.92 分钟的快照时间内，只有 0.16 分钟在执行数据库任务，说明数据库业务非常空闲。

在满负荷的情况下，DB time 会等于 Elapsed Time（快照时间）* CPU 个数，说明每一个 CPU 都在执行数据库业务。

可以从详细报告的 Time Model Statistics 里看 DB time 的各组成部分：

• 分析负载统计

分析 Load Profile 报告，能够从总体上了解数据库系统的负载情况。主要分为5个部分：

1. DB Time 统计
2. IO 统计
3. 解析和执行次数统计
4. 元组统计
5. 事务统计

IO 方面需要重点关注的指标有 WAL Size - WAL 日志 IO 大小，和 Blocks Read/Write Size - 数据页读和写的大小，这应该是物理读写的大小。

解析方面需要关注解析次数和执行次数的比例情况，如果硬解析过多，则必然 Parser Calls 跟Execute Calls 更接近，说明解析效率不高。如果今后能够提供软解析和硬解析次数，就跟完美了。

元组方面感觉可以大概看一下增删改查的比例就好，了解一下大概的业务类型。

事务方面看看回滚的事务是不是比例高，如果比例高是不是需要分析一下业务逻辑。

这个报告非常的有用，我比较喜欢的一点是这里提供了每秒（Per Second）、每事务（Per Transaction）的统计功能，可以比较直观的知道每秒写了多少WAL日志，每秒执行了多少元组的插入和删除等。

• 分析实例效率百分比

这个报告功能比较少，这里面出现的每一项，最佳情况是都为 100%，至少应该是 90% 以上。如果低于 90%，说明数据页缓存不够（Buffer Hit），需要加大 Shared_buffers，让更多的数据页通过缓存级能命中，较少 IO；或者说明解析和计划效率不高，发生了大量的硬解析的，需要从业务端把 Simple Query（select * from t1 where id = 5）通过扩展 SQL 协议来执行，即绑定变量的方式来执行。

如果能再多提供一些跟效率百分比相关的统计更好了，比如 LWLock 命中率，全部在内存上发生的排序比例等。

• 分析等待事件

等待事件是多少 DBA 分析性能问题的利器，PostgreSQL 目前就只提供了当前发生的等待事件，而没有提供 KES 里面这种累积式的等待事件，不能不说是一个遗憾。

我觉得这个报告是最重要的。拿到报告，看完负载统计后，应该立刻查看排名靠前的几个等待事件，尤其那种大约 DB Time 5% 以上的等待事件，往往是发现性能问题的关键线索。

这个报告里可以看到 DataFileRead 等待事件发生了 2497 次，DB Time 比例超过 30%，说明发生了严重的 IO 等待，存在大量的物理读。可以通过加数据页预先加载到内存的方式来较少物理读。

然后是 WAL 日志的 3 个等待事件也比较高，可以通过扩大 WAL 日志缓冲区、修改 WAL 刷盘的方式来减少 WAL 日志的写压力。

另外，平均等待时间也值得关注，比如报告里的 transactionid 的平均等待时间是 9.23 毫秒，说明分配事务 ID 的锁冲突太厉害了。

• 分析主机环境

看到这个主机环境报告，我惊讶了！

有过 DBA 经验的人都知道，有多少的问题是应该客户主机和网络环境问题引起的，尤其是在一些保密性强的环境里，很多的服务器上无法安装 NMON 之类的性能监控工具，这时候，能有一份不依赖任何外部工具就能生产的 CPU、IO、内存和网络统计报告是多么的激动。

废话不多说了，相信大家都能明白这几个报告的内容，和他们的重要性。

• 分析实例 IO 和内存

通过 IO Profile 报告，能更细节地了解数据库实例 IO 的详细情况，重点关注每秒读写 IO 的大小，并和网络 IO 去比较，看看是不是 IO 遇到瓶颈了。

另外，如果 IO 读写太高，需要分析一下业务场景，或者调整一下数据库的配置参数。

Top 10 Shared memory 报告则展示了数据库实例共享内存的一个分部情况，能够很清晰的知道哪些业务占了共享内存的大部分空间。

如果能按照功能，比如数据缓冲区、WAL 缓冲区、CLOG 缓冲区等分一下类可读性会更强。

分析 TOP SQL

TOP SQL 从多个维度展示了耗时耗资源最多的 SQL 语句，有了这些报告，可以很容易找出消耗资源最多的 SQL 语句，然后具体分析。

以 Top SQL By Elapsed Time 为例，该报告按 SQL 完整执行完成时间排序，显示了总花费时间、执行次数、平均每次的执行时间、执行时间占比和 SQL 文本等信息。点击 Query Hash 链接还可以查看完整的 SQL 语句。

具体调查某一条 SQL 语句的时候，还需要分析它涉及到的表和索引的统计信息，因为有时候性能问题往往是由部分热表、热索引冲突导致的。

整体感觉这些 TOP SQL 报告还是比较完备的，如果有执行计划的相关信息就更好了。

• 数据库对象统计

这一部分是从数据库对象：后台写统计、数据库统计和数据库对象（表、索引和自定义函数）统计显示各数据库对象的资源消耗的。

我们需要重点关注的是表和索引的 IO 读写情况。

比如 Top Tables By Logical Read 查看物理读的情况，它不仅展示了表的物理读，还展示相关联的索引表、Toast 表的物理读情况。对这些物理读很高的表和索引要特别关注一下。

结束语

---

好了，整个人大金仓 KWR 报告的体验过程就基本结束了，还有很多的地方读者朋友们可以自己去实践体会一下，如果有条件可以和 Oracle 产生的报告对比一下，看看互相的有点和缺点。

虽然国产数据库跟 Oracle 相比还有一些差距，但是单从人大金仓的这个 KWR 报告跟 Oracle 的 AWR 相比，已经算是有模有样了，基本上该有的都有了，我是对咋们国产数据库越来越有信心了。

最后所有国产数据人一句李白的话共勉：乘风破浪会有时，直挂云帆济沧海！

【本文正在参与炫"库"行动-人大金仓有奖征文】

开发者请集结丨炫“库”行动——2021人大金仓征文大赛悬赏万元等你来！

文章知识点与官方知识档案匹配，可进一步学习相关知识

云原生入门技能树首页概览13601 人正在系统学习中