老中医输给了CT机

老中医输给了CT机

每秒690个硬解析对于一台两路E5 22核的服务器来说也不算太高,按理说是可以接受的,为什么用户觉得硬解析是个比较急迫的问题呢?从命中率上看,解析的问题还不少。

老中医输给了CT机

解析占用CPU的比例已经高达30%了,但是为什么每秒600+的硬解析会有这么大的CPU开销呢?按理解析数量与硬解析数量高数倍的系统也是常见的,都不会出现Non-parse CPU只有不到70%的情况出现。这个系统在高峰期CPU已经成为瓶颈,因此解决这个问题对用户来说十分关键。

按照惯例我们会去看看解析和执行都比较高的SQL语句,不过从TOP SQL上也没看出啥问题。看样子这个问题没办法通过一份AWR报告来看清楚。于是我让用户把D-SMART的离线数据发给我,我们通过D-SMART的分析工具来做个离线分析,看看出问题的时候系统存在什么问题。当然最后分析出来的这套系统存在的问题是多方面的,今天篇幅的关系不做详细的讨论。今天只是从解析消耗这么大的CPU资源的问题进行分析。

从数据看负载的指标上看,硬解析的数量和AWR报告看到的差不多,于是打开指标明细页面,看看这个指标的变化趋势。

从上面的图上可以看出用户的系统一上班硬解析的数量就急剧上升,而且9点多以后就基本维持在600-700这个基准上了。

如果从某个单一的指标上看不出问题,我们该如何分析呢?一般来说我们会通过几个方面去做分析:

  • 1)通过专家经验,确定此类的指标有哪些诊断路径,通过这些诊断路径逐一排查;

  • 2)有时候专家经验不一定十分完善,而且对于某些指标,系统中还没有积累专家经验,此时就只能依托现有的知识库,通过知识推理找出相关的诊断路径,这种方式找出来的诊断路径有可能会比较多,有些路径的关联性并不很强;

  • 3)通过知识图谱,找出相关的指标,然后对这些指标做关联性分析,找出关联性比较强的指标,然后通过其他指标是否异常来辅助分析;

  • 4)通过该指标在更广泛的范围内进行关联性分析,找出其他运维对象的同一个指标与本运维对象存在关联的情况,从而判断是否在更广泛的范围内的基础设施问题引起了该问题。比如共用的服务器、存储、SAN网络、云平台、核心交换机等出现了问题,导致了此类问题的发生。

在D-SMART中,就按照这个思想构建了一个诊断工具:

针对这个问题,我们先通过智能运维工具我们做一下第三诊断路径“指标关联度分析”,看看隐藏在这个指标问题的后面有没有隐藏着什么我们忽略掉的问题。

为了获得更为准确的数据,我们分别选择了出问题当时的30分钟与问题表象从初期到严重的这段时间的一个多小时的数据,分别进行了计算。经过几秒钟的计算,智能诊断工具给出了一个让我们感到既意外又令人惊喜的结果(两次分析的结果完全相同)。分析工具总共找到了5个和硬解析指标相关的指标。其中令人有点意外的是,每秒的总解析数与硬解析数量的相关性比较低,比其他4个指标要低一个数量级,看样子总的解析数量与这个问题的关系不大。

关联性最高的指标是“
library cache lock 平均等待时间”,实际上这个指标应该是因为硬解析引起的问题,而不是原因,虽然关联,但是不是因。包括排位在第三第四的指标也是如此,这些指标会导致解析的成本变大,导致了现场的问题,但是这几个都不是问题的根因。排在第二位的指标就比较有意思了–“
Parse Failure Count Per Sec”,每秒钟解析失败的数量,这确实是我们容易忽略的问题,而且实际上这也可能是导致硬解析成本变得如此之大的主要原因。因为SQL写错或者权限问题导致解析失败,会导致每次SQL解析都是最高成本的,这一点以前我们也遇到过,只是这种情况出现的较少,比较容易被忽略。这种情况,哪怕是老司机也很难一下子想起了,这回AIOPS居然给在这个领域干了二十年的人上了一课。通过这个指标反过来分析关联的指标。

我们看到

Parse Failure Count Per Sec
和三个和SQL解析相关的等待时间的关联性相当高,从Oracle数据库的原理上也可以十分明确的理解,解析失败是十分高开销的,肯定会加大这些平均等待时间。

这时候再回过头去看AWR报告,确实存在一定数量的解析失败。不过对于上百个状态指标,我们很难第一时间从中发现问题。把一份AWR报告认认真真的从头看一遍,不遗漏任何疑点,确实也有一定的困难。而且人的思维定式也限制了我们往这个方向上去思考。实际上,从D-SMART的监控数据看,有时候解析失败的数量高达每秒20+。

这个案例中使用了D-SMART中的“指标关联性分析”工具,这个工具目前并不完善,仅仅能够找出关联性较大的指标。找出的这些关联性指标对于具有一定经验的专家还是很有价值的,不过对于运维小白来说,还是不够用。我们目前还在改进这个工具,不仅仅能够找出这些指标,而且还能够筛选出首选指标,并且通过其他的分析确定因果关系,从而自动筛选掉今天我们通过专家筛选掉的那三个指标。如果工具能够达到这个水平,那么哪怕是一个仅仅对数据库原理有一点粗浅了解的人也可以看懂工具的分析结果了。通过这个案例,老白也颇有收获,居然一个老中医被一台CT机给教育了,于是对AIOPS的期待又深了一层,AIOPS的未来可期。

老中医输给了CT机》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/54.html