opengauss ASP的几点优化建议

本周五的openGauss开发者大会上我分享的内容里有几条对openGauss可观测性优化提升的建议，原本也想会后和研发的朋友一起探讨一下这几个问题。不过因为北京健康宝弹窗，很大可能性是无法线下参会了，今天我利用公众号这个平台先发一篇文章，具体的内容在周五下午的生态工具分论坛的最后一个演讲中也会提及。

关于数据库可观测性的重要性不用再多说了，各个国产数据库也在努力提供可观测性的数据给广大用户，只不过从DBA的角度来说，这些国产数据库厂商提供的可观测性数据的质量都不够高，不足以用于日常的运维分析、性能优化和故障定位。从一个老DBA的角度，今天我提几个openGauss的可观测性方面的优化建议，也算是给无法亲临现场的openGauss开发者大会添几根柴吧。

第一个优化建议是提给ASP的，ASP应该是openGauss开发人员引以为傲的功能之一了，确实ASP也算是我见到的国产数据库里第一个类似Oracle ASH的实现。ASP为运维人员提供了相当好的历史问题分析和性能分析的接口，我第一次看到这个功能的存在的时候也是比较兴奋的，不过兴奋之余，我又有点失望了，因为高斯的ASP里没有等待时间。

GS_ASP是持久化的数据，在内存中是DBE_PERF.LOCAL_ACTIVE_SESSION,其结构和GS_ASP基本一致。缺乏等待时间和ASP数据的采集位置有关，如果只在等待开始时候记录就很难记录到等待时长了。缺乏等待时长，在分析等待事件的时候，就不知道某个等待事件是不是处于正常状态。从高斯提供的另外一个接口看，openGauss是能够采集等待时长的。

在这个接口中，我们可以看到平均等待时长，最大，最小等待时长等数据，说明高斯是有能力提供等待时长这个数据的，因此在GS_ASP/LOCAL_ACTIVE_SESSION中提供这个数据也是有可能的。我们期待能够看到这个改进。只不过这种改进看似很小，对于内核代码来说是巨大的考验，不能为了增加这个可观测性数据而影响了高斯的并发性能。

另外一点就是针对ASP数据的筛选问题，目前ASP数据产生的太多了，很多数据中包含的信息对运维分析帮助不大（一部分EVENT为NULL，也没有持有锁，也没有阻塞别人或者被别人阻塞的活跃会化数据，可能是价值较小的，可以通过算法进行排除），在持久化的时候，应该把这部分数据尽可能的排除掉，这样会让数据更有效。目前默认的持久化比例是10:1，虽然这个参数可以调整，不过我们测试的情况来看，1:1保存还是有一定的资源开销的，保存的记录数量也十分庞大。这种采样可能会丢失掉大量的有效数据，如果能够通过高质量的筛选去除不重要的数据，剩下的全量保存，那样就更好了。

ASP的持久化保存，最佳的方式是文件方式，目前高斯支持文件方式保存，不过不是默认的。文件保存的开销最小，不过访问接口有点麻烦，因此选择文件保存作为默认方式后，还应该提供两个功能，一个是保存时长的问题，目前表的保存方式是可以设定保存时长的，这个参数应该也能够影响文件保存的时长，能够自动删除历史数据。同时高斯也应该提供对于文件保存的ASP数据的视图访问方式（类似于外部表的实现方式），让运维人员可以通过简单的SQL语句来访问该数据。

为了更好的进行ASP分析，DBE_PERF.WAIT_EVENTS也需要做一定的优化，创建一个DBE_PERF.WAIT_EVENTS_HISTGRAM接口，用于存储等待事件的柱状图信息。WAIT_EVENTS_HISTGRAM里包含了多种等待时长的等待次数的统计信息，这样运维人员根据柱状图信息，就更容易看出来某个等大事件在系统总发生了什么变化，可能存在什么问题了。只有简单的平均值最大值最小值无法给DBA分析提供足够的数据，如果能够在内存中存放最近半小时的柱状图信息，并且把历史的祝张图信息持久化到GS_WAIT_EVENTS_HISTGRAM表中，那么一旦DBA需要分析系统出现过的问题，或者做系统运行的趋势分析，就更加容易了。

除此之外，针对ASP数据，实际上也只能给运维专家来看，普通的DBA很难看得懂ASP数据。因此也可以模仿Oracle ASH报告的内容，提供一个产生ASP REPORT的接口，让技术稍微潮一点的小白也能做点ASP分析，肯定是一件十分有价值的事情。有ASH报告的模板在那放着，要实现一个高斯的ASP报告难度也不大。

最后，也是最重要的一点，就是高斯的文档里能不能出一份等待事件参考手册。Oracle的每个等待事件，基本上都能在MOS上找到一份阐述性文档，以及多份与之相关的文档，BUG报告，优化建议等。如果openGauss社区也能维护一本这种不断完善的参考手册，那么对于运维人员来说绝对是个福音了。