为什么平均等待时长对于数据库运维十分关键

​昨天我谈到第二次使用人大金仓数据库的时候，能够从可观测性接口中获得等待事件的等待时间信息，感受到了数据库在易用性上的进步。有些朋友十分不解，不就是等待时间的长度数据采集吗？有这么重要吗！说实在的，运维人员获得数据库的等待事件的等待时长，是比重要还要重要的。

我们很容易从数据库中获得等待事件的次数，等待事件次数统计对于数据库内核来说，实现起来并不麻烦，只要维护一个内存数据结构，通过轻量级锁来保护这个内存结构就可以了。数据库的会话可以通过向数组累计统计数据来获得这些统计数据。甚至很多数据库根本不需要统计等待次数，只需要在会话信息中增加一些等待事件的相关数据项就可以了。每个会话都会维护自己的会话状态块，每次产生某个等待的时候只需要对其进行累加就可以了，其维护成本很低。但是要统计某个等待事件的等待时长那就不同了。

十多年前我和一个国产数据库厂商交流的时候，他们就提出来他们在新版本中引入了等待事件，但是目前只能提供等待次数，无法提供等待时长。他们测试过在会话信息中加入等待时长的统计信息，但是加入后，数据库的整体性能下降超过了10%，想了解一下Oracle数据库是怎么在OWI接口中实现等待时长的统计的。当时我对这个问题研究也不深，为了回答这个问题，我也研究了Oracle OWI接口的发展历史。实际上Oracle对这些数据的统计也是经历过一些波折的，最初甚至通过CPU周期、resource manager等去粗略的估算时长。到后来采用统一时间戳去做近似估算。其目的是以最低的成本，对数据库运行影响最小的方式较为近似的统计等待时长。

既然获得等待事件的时长需要付出如此的代价，那么为什么DBA还是需要获得这些数据呢？从等待事件的等待次数上不就可以知道数据库在干什么，在等什么了吗？实际上等待事件分析是十分复杂的事情，并不像某些DBA认为的，看到某个等待事件，去百度上搜一搜就可以定位数据库的问题。某个等待事件是否引发了某个数据库问题，并不仅仅要看这个等待事件是否出现，而是要看它占总等待的比例。这个比例可以是等待次数，也可以使等待时长，而等待时长的准确性更高。如果某个等待事件出现的次数很高，只能说这方面的负载很高，如果每次等待的时长都很低，或者说和日常数据库没出问题时候的平均等待时长十分接近，那么可能说明数据库在这方面的并发性能并没有出现问题，数据库的问题很可能并不是因为这个等待事件引起的。

比如说上图，我们发现了IO延时突然增加，那么我们就可以通过突发IO延时的增加与十几分钟后的服务器重启进行综合分析，从而把故障原因缩小到一个较为狭窄的分析面上，通过这个问题去做下一步的问题定位。

而如果我们只知道IO等待的次数，那么我们只能知道当前SQL读写IO的负载很高，可能有一些产生大IO的SQL，或者有大量的并发访问。但是我们无法知道当前的IO负载是否会引发数据库的问题，或者说数据库是否存在宕机的风险。十分高兴的是，我们看到目前大多数国产数据库都开始提供等待事件等待时长数据了，这对于DBA运维国产数据库十分关键。

而采集等待事件的等待时长对于数据库核心来说也是一个挑战，用最小的成本，对数据库性能影响最小的方式采集等待事件时长十分关键。记得去年我在测试Polardb-O的可观测性能力的时候，惊喜的发现了Polardb能够对一些重点等待事件采集等待时长，这些重点等待事件主要是lwlock和数据库IO相关的。而对于其他的等待事件，Polardb并没有提供等待时长，这种设计也体现了运维与数据库性能之间的平衡。一般来说，对于现代硬件，如果开启了这些采集，增加的数据库开销低于5%，甚至在一些系统中，低于10%都是可以接受的。但是如果太高，则无法接受了。

当时我发现商用版的Polardb-O中的针对IO的等待时长的采集数据是空的，而开源版的Polardb-PG中是能够看到这些数据的。当时我们也没有深究这个问题。今年我们加入了Polardb社区，同时在D-SMART中也开始针对Polardb做深度对接，将Polardb-PG数据库与社区版的PG数据库独立开来，利用Polardb的可观测性能力增强来加强Polardb的监控诊断与分析能力，所以我们重新对这些可观测性接口做了分析。通过与阿里的技术人员的沟通发现，要想在商用版的Polardb上采集到Polar_stat_io_latency等IO相关的等待时长数据，哪怕我们使用的是本地文件系统的单机版，也必须将数据库存放在Polar自带的PFS文件系统上，并设置polar_enable_shared_storage_mode = on，才能采集到相关的数据。

完成这些设置后，我们就可以从polar_stat_io_info/polar_stat_io_latency视图中看到数据了。在开源版本中，采集IO延时的时长的采集采用的是大多数数据库使用的原生模式，在数据库内核中直接实现就可以了。但是在商用版中，这些优化是利用云原生数据库的特性，通过PFS底层实现来完成的，这样可以大大降低数据库内核采集IO等待时长的成本开销。