PostgreSQL数据库是近年来热度上升最快的关系型数据库之一，近年来大量国内企业都在把系统向PostgreSQL上迁移。目前热度较高的国产数据库中也有一大半的厂商选择了PostgreSQL开源项目作为数据库产品的研发基础。不过PostgreSQL的运维一直是个难点，与Mysql相比，PostgreSQL过于复杂，运维难度远大于Mysql。而与Mysql相比，熟悉PostgreSQL运维与优化的DBA数量又远远不及。再加上开源数据库的文档资料相比Oracle等商用数据库来说更是差距甚大，如何做好PostgreSQL数据库的运维就成为很多企业面临的大问题。 在2020年的第十届中国PG用户大会上，我分享了一个主题-《基于知识图谱的PostgreSQL深度分析》，当时正好是基于PG的知识图谱1.0刚刚具备雏形的时候，正在实验性的用于D-SMART产品中，对PG等数据库进行辅助诊断。

当时我们采用在生产系统中采样，并进行专家标注的方法构建分析中最为核心的异常检测算法，结合知识图谱定义的诊断路径，找出与某个故障现象相关的指标集，然后通过异常检测发现其中存在问题的子集，最后通过收敛算法，找到问题的根因。 在那个演讲中，我举了一个实际的案例，在一个电力客户中有一套PG数据库，现场DBA对PG运维完全无感，因此这套系统一直是在盲跑，到底有没有问题，只有老天知道，只要不宕机就啊弥陀佛了。客户反馈系统慢也没有任何办法去做分析，因为运维团队里没有任何针对PG进行优化的知识。 正好客户和我们一起启动了一个智能化运维的课题，于是我们就针对这套数据库进行了一些智能诊断的尝试。在D-SMART 1.9中我们提供了一个智能诊断工具，利用这套知识库可以进行初步的分析，将问题收敛到了几个方面，运维人员根据这些方面的分析结论，结合智能化工具推荐的诊断工具，手动点击这些工具，最终定位了问题。这种智能化辅助的手段可以减轻DBA的工作负担，提高问题定位的正确性。不过也只是能够起到一定的辅助作用。 当时我们分享的这个案例只是一个实验性的案例，我们采用的异常检测算法是依赖于专家人工标注的。

通过离线的数据采集，经过无监督学习(实际上就是暴力计算)找到一些疑似故障点，然后对这些数据进行一定的人工标注，再通过半监督学习构建模型，用于生产系统中的异常检测。为什么要采用这种迂回的方法来构建异常检测模型呢？这是因为暴力计算需要很高的算力，如果用于实时监控，对服务器CPU资源消耗过大，需要一个庞大的集群才能支撑较大规模的数据库运维场景。 这种方法虽然在实验室中获得了一定的效果，但是在实际生产环境中我们遇到了一个巨大的问题，那就是这样构建起来的模型并不通用，换了一个客户，甚至在一个客户的多个不同的数据库或多个不同业务类型的应用系统中模型都不通用。对于一个具有数百个甚至上千个数据库实例的用户来说，都采用如此高成本的模型构建方法是完全行不通的。后来我们又尝试了一系列基于时间序列的无监督算法，比如HTM/LSTM，以及随机森林等方法，最后获得的效果都不理想。 基于上面遇到的问题，在构建2.0版本的知识库的时候，我们放弃了以前的一些设计，针对异常检测，需要找到一种计算量较小的，不依赖于专家标注的算法。于是我们想到了模仿Oracle的统计信息，以一定周期为单位(比如一周，半个月)，滚动更新统计数据，采集指标的数据进行采样，构建常规运行的数据模型，然后根据这些数据模型，建立算力要求较低的算法，用于生产环境的指标异常检测。 同时针对知识库的更新也在继续进行。从去年1.0版本的数千个顶点，两万多个关系变为5万个顶点，十几万个关系。

在知识库构建的过程中，1.0版本主要解决了从某个故障场景的诊断路径自动发散，通过发散后的路径来寻找各种问题的可能性。1.0版本并没有解决好问题的收敛，虽然智能诊断可以不断地发散，让DBA抓住所有的蛛丝马迹，但是没办法对问题进行收敛归类。从而较为准确的定位故障点，有时候甚至会出现大量的误判，把一些与这个故障无关的因素分析了出来。这是因为数据库系统是一个十分复杂的系统，当某类问题出现的时候，系统中还存在很多其他方面的问题，这些都可能对智能化分析产生严重的干扰。在数据库专家的辅助下，这些干扰可以比较容易的被裁剪，但是智能分析算法并没有人类的这种智慧，只是一种算法智能，是无法解决这些问题的。因此2.0版本的知识库中重点对诊断路径的收敛做了优化，最后形成比较规范的故障结论。 实际上，智能化诊断是一种算力与算法的诊断，而并不完全是一个真正的人工智能，我们更喜欢称之为“知识自动化”，是一种基于各种传感技术与算力的自动化驾驶。 首先是通过各种异常发现的算法与规则引擎，找出异常点，并归纳为某个异常场景。然后通过知识图谱发散思维，合理的扩散诊断路径。第三步是根据诊断路径找到关联指标，形成待分析的指标集。第四步是通过异常检测算法对这个指标集进行检测分析，找出可能的问题路径。最后对问题路径进行收敛，获得分析结果。 下面是D-SMART 2.0的一个诊断案例，我们在进行模拟压测时，D-SMART出现了一个告警，含义是shared buffers中的脏块写盘的状态出现了异常，backend进程承担了过多的脏块写出的工作。

比如上面的这个故障场景，在系统负载比较高的时候，经常会出现backend回写共享缓存的比例过高的问题，这会影响应用的性能，对于一些性能敏感的应用影响较大。针对这个告警，D-SMART提供了一个智能化分析工具和几条标准化的诊断路径。上面是“智能指标分析”工具显示的相关指标情况，在后面，该工具直接给出了诊断结论： 诊断结论还是通俗易懂的，懂一些PostgreSQL运维的人都可以获得如下的信息，首先这个问题出现的原因是系统并发量太大，其次数据库的配置有可优化的地方。另外系统中存在TOP SQL，IO的吞吐量也有点大。 事实是否如此呢？首先并发量大这一点十肯定的，因为出现告警的时间段正好在做压测。系统配置是不是有问题，我们可以直接通过工具去验证。目前2.0的知识库还有一个地方不够完善，那就是针对finding的确认，在2.1版本中，知识库里会带有诊断结果确认的知识，当然这些知识是通过关联相关诊断知识点来实现的。升级到2.1版本的知识库后，在每个发现后面会直接输出自动确认的结果。 图片 对BGWRITER相关参数的分析，提出的建议是不调整相关参数，而去加大shared buffers。从shared buffers的命中率看，确实在问题发生的时间段内的命中率较低。

这也是PostgreSQL数据库常见的问题，当shared buffers不足的时候，大量的数据块需要写出，此时backend就被迫承担了大量的bgwriter的工作了。对于大型的PostgreSQL数据库，要尽可能减少这种情况的出现。

上面的诊断结果和智能诊断的finding中DB CACHE配置不合理是吻合的，根据上面的建议，我们把shared buffers调整为15GB，然后再加载类似的负载。再看看刚才的问题是否缓解了。

从上面的这个数据可以看出，调整shared buffers之后，backend进程写出共享缓存的比例合理多了。和今天上午同样压测的情况相比，也要低了很多。我们再来看shared buffers的命中率情况：

Shared buffers的命中率也没有再出现上午的抖动情况。从压测工具上来看，tpmc也稳定在60多万，比上午增加了15%左右，而且tpmc也不像上午压测那样抖动了。从这个例子来看，知识库2.0很好的帮助DBA完成了一次较为复杂的诊断。 知识库2.0版本在分析能力上必1.0版本有了较大的提升，代价是在D-SMART服务器上需要消耗大量的CPU资源去对已有的监控数据做采样分析，从而获得较为准确的数据，用于指标的异常检测。和传统的监控系统相比，智能化运维工具需要更高的算力来做支撑。随着工具能力的不断提升，D-SMART从一个只需要跑在一台配置很低的虚拟机上，已经变成了一个算力吞金兽了。