从一个达梦数据库性能问题的根因诊断说起

从一个达梦数据库性能问题的根因诊断说起

以前看到很多使用知识图谱的产品，里带有的知识图谱都是十分花哨的，看上去似乎很高端很好看，不过我没想明白，运维人员使用这样的图谱如何辅助运维。真正的基于知识图谱的运维自动化工具应该是看不到图谱的，图谱只是用来帮助用户自动化分析问题的工具，而不应该成为一个展示品。

我们今天用一个达梦数据库问题的分析过程来展现一下知识图谱是如何为运维自动化提供能力的。

可以看到，诊断结论中认为，这段时间里系统的SQL并发执行数量过大，数据库的逻辑读和物理读都比较大,redo的并发量比较大。另外从配置上，DB CACHE的设置也存在一定的不合理的地方。下面我们再来看看智能运维工具给我们推荐了哪些诊断工具呢？

排在靠前的推荐是“逻辑读较多的SQL”,”执行次数较多的SQL”和”达梦数据库参数检查”这三个工具。我们先来看看TOP SQL诊断工具，看看CPU比较高的时候，系统有哪些逻辑读比较高的SQL。

有一条SQL语句针对DMSQL_OORDER做了一个全表扫描，每次扫描471M的数据，1200多万行数据。难怪消耗了那么多CPU资源了。

我们再来看看DBCACHE配置问题，在这里，智能运维工具推荐了达梦数据库命中率维度的诊断。实际上应该还有一个，因为推荐工具排重的问题，在这里被排除掉了，这个工具包含在诊断项4里面-“达梦数据库参数检查”，因为在在前面的推荐中已经出现了，所以在这里就被裁剪掉了。裁剪掉已经出现过的工具是为了让显示界面更为简洁。不过也会让某个章节的内容现得不够准确。这是两难中的选择的结果。

从这里可以看出RECYCLE POOL的命中率是存在问题的。不过这个诊断工具比较老，分析的内容也不是很准确。于是我考虑立即用新提供的“智能知识点”的能力，创建一个分析工具来完善这个分析过程。

老白已经多年不写程序了，手忙脚乱的花了块10分钟才搞定了这个知识点，并把它配置好了。整个框架代码，连注释不到30行，实际上只是修改了其中几处配置，这个知识点就写好了，写代码时间不超过2分钟。下面我们来看看效果。

这个新的知识点的加入，不仅仅会应多出一条诊断路径，因为整个图谱中的各个节点之间的关系也直接发生了变化，诊断结果也发生了变化。从实际效果上来看，虽然发现的问题也还差不多，不过其权重发生了较大的变化，结果变得更准确了，导向性更强了。

可以看到，这个知识点已经能够自动在诊断分析中发现了。我们也可以使用这个知识点来进行诊断。

可以看出，这个“智能知识点”不仅仅是一个智能路由器，自己也具有很强的诊断分析能力，正是这个知识点的诊断分析能力中发现了更多的应用方面的问题，所以从总的诊断结论上，应用问题的排序更靠前了。

这个知识点并没有怎么配置，也没有手工创建与其他知识之间的关系，只要把这个知识点创建起来，扔到图谱里去，就会自动的发挥作用了。运维诊断工具的低代码可以为一线运维和三线专家提供更好的工具，让他们能够更快的实现自己的运维经验的自动化，也可以大大加快智能运维系统的开发。这是我们的智能化知识点中的一种，叫做“泛路由知识点”，这种知识点具有两大特征，

第一个特点是泛路由发现，可以自动建立与其他知识之间的关系，并自动筛选适合的路由，将知识推荐给前端。第二个特点是低代码，实际上，通过简单的配置，这个知识点就可以调用一些平台提供的标准化的智能化分析手段，简单的两三行代码就可以构建一个十分强大的分析功能，用低代码的方法开发一些常用知识点工具，可以大大加速研发进度。

最后再讨论一个问题，昨天还有朋友问我文中前面提到的两条技术路线：大数据+高级算法和运维知识图谱+简单算法，到底哪条路才是企业做智能化运维的最佳选择。实际上，这两种技术路线对于企业的作用是不同的。

对于一些大企业，这两种技术能力都是需要建立的。如果企业目前更需要宏观的异常检测，问题发现，而具体的技术分析工作主要还是依靠人力，那么第一种能力是这个企业当前最迫切需要建立的。而如果企业目前需要一种能力去减轻人力分析的工作量，减少运维中的人力资源，那么第二种能力是企业首先要考虑建立的。如果企业在资金等方面充裕的话，两种能力同时构建肯定是最能看到效果的。而对于一些运维资金十分有限的中小企业，建立第二种能力可能是性价比比较好的，因为它马上能够在你的企业里发挥效用。而第一种能力，一定要等你的运维数据归集和积累达到一定程度后再去做，可能更有效一些。