简单体验一把Polardb的等待事件

以前我多次说过等待事件分析对于数据库运维来说十分关键，目前也确实有越来越多的数据库开始支持等待事件分析了。实际上，一些基于PG内核的数据库，大多数是有等待事件的，不过PG原生态的等待事件只有事件，没有等待时间，而且缺乏统计等待事件的汇总信息表，所以使用起来并不容易。利用pg_stat_activity去采集等待事件也要看运气，有时候就会把一些重要的等待事件忽略掉。而且因为缺乏等待时间的指标，因此我们只能从总量上来看一些问题。

这两天正好Polardb的朋友给我发来了最新版的优化手册，可以对应Polardb-O 2.0.2版本的。我拿到后简单翻了翻，发现和2.0.1版本相比，多了一些性能监控方面的管理特性。这正是我们一直期待的。

实际上基于PG代码的国产数据库基本上都是支持等待事件分析的，包括人大金仓、瀚高、优炫、神通、openGauss等。我们的产品去年开始对接PolarDB的时候，原有的PG等待事件分析功能就能够直接支持了。我们这个Polardb数据库安装后还没有针对WAL和checkpoint进行优化，因此WAL的相关等待时间has排在第一位。

CHECKPOINT检查工具对当前的参数提出了一些修改建议。我们按照上述建议调整一下参数，这些参数都是通过alert system 设置后使用pg_ctl reload就可以动态修改的，十分方便。

我们看到，WAL方面的lwlock等待小多了，从系统的TPMC指标上来看，也有了明显的改善。在性能监控视图方面，PolarDB 2.0.2明显比2.0.1版本提升了不少。依赖于PolarDB的polar_monitor/polar_monitor_reload这两个插件，我们可以获得很多的原生态PG数据库所没有的监控特性。其中最为重要的是，我们能够获得等待事件的等待时长的数据了。等待时长可以为运维分析提供更为准确的信息。这一点我前阵子发的几篇关于openGauss的文章中也做了阐述。Polar_monitor插件为我们带来了数个polar开头的监控视图。其中就有我们锁期待的polar_stat_activity，这个和pg_stat_activity近似的监控接口有着我们需要的新数据。

这个监控视图的前半部分和pg_stat_activity类似，不过后面部分的内容确实十分有价值。等待时间、CPU开销，rss内存使用，共享存储读写指标（针对PorlarFS）和本地存储读写指标，这些监控指标可以让我们更加清晰地理解当前等待事件的情况。

这些数据比我们以前仅仅看到等待次数要清晰的多。Polar_stat_io_info/polar_stat_io_latency视图给我们展现了更为详细的IO状态。

Polar_stat_io_info监控视图

Polar_stat_io_latency监控视图

今天只是简单的体验了一下，目前我的环境中，这两个监控接口还没有数据，不知道是不是有什么参数要设置，留待后面慢慢研究吧。这些功能对于我们增强对PolarDB数据库的监控能力至关重要。

在一个高并发系统中，轻量级锁的等待占比是比较高的，因此对于高并发系统中存在的一些性能瓶颈的分析需要对轻量级锁进行深度分析。原生态的PG数据库中我们只能通过定期采集pg_stat_activity来了解轻量级锁的等待数量，这远远不够。和openGauss不同的是，PolarDB并没有针对所有等待事件收集等待事件的汇总信息，仅仅针对lwlock进行了采集，这些数据可以通过polar_stat_lwlock监控视图来获得。

有了这些汇总信息，我们就可以随时掌握一些重要的LWLOCK的等待情况了。这对于分析系统性能瓶颈十分关键。

针对lock,PolarDB也提供了类似的监控能力，这个能力同样来自于polar_monitor_preload插件。通过插件实现这些监控，其开销如何目前我们还没有测试，增强监控要带来一定的系统开销，这一点是肯定的。在Oracle 9i之前，OWI刚刚成熟的时候，Oracle数据库在高负载场景下也是经常建议关闭一些监控的。不过随着现代硬件性能的提升，以及OWI的日渐成熟，大部分监控都成为标准开启的了。在这方面，我想国产数据库也需要不断地在摸索中前进。记得数年前和一个国产数据库研发团队交流的时候，他们也提出过在自己数据库中开启了等待时间监控后，数据库并发性能受到了很大的影响，最终在正式版本中，他们只能舍弃了这个监控功能。