你会正确采集活跃会话数吗?

数据库的活跃会话数是一个十分重要的监控指标,如果某个系统的活跃会话数突然变得比平时高很多,那么我们就需要对该系统多加关注了,是不是系统的某些方面的争用加大了或者应用变慢了呢?记得以前帮一个快递公司做数据库服务,他们的系统经常在查单高峰期的时候资源不足,导致系统HANG死,后来我们做了一个监控指标,监控活跃会话数的变化,如果活跃会话数超过300了,马上报警,DBA立马开始杀一些会话,就可以确保系统不会HANG死或者宕机。如果我们有一个系统,平均的活跃会话数是30,突然变成了50,我们可能很快会加以关注,如果一个系统平时的活跃会话数是50,突然变成了70,可能我们不会太去关注它。

现在很多监控系统都在采集活跃会话数这个指标,不过并不是每个客户都正确的采集到了活跃会话数指标。前几天在一个客户现场,协助他们构建负载模型。发现他们很多系统的活跃会话数指标的日平均是50+,而这些系统都是负载很小的系统。这让我十分困惑,日平均超过50的活跃会话,这是一个十分繁忙的系统才具备的指标,这肯定是不合理的。于是我们进一步分析发现,他们是从v$session里通过STATUS=’ACTIVE’采集的活跃会话数指标。这下子我就明白为什么日平均值会这么高了。因为Oracle 10g开始有很多后台进程,这些后台进程经常会处于等待某个计时器或者消息的状态,而这个状态,在会话的角度来说,也是会被标志为ACTIVE,虽然这个会话此时啥事都没做。如果把这些会话也认为是活跃会话,会对我们的运维带来一些误导,我们无法正确的了解到真实的活跃会话情况。实际上我们可以很简单的还原这个现象,找到一套Oracle 10.2.0.5和一套11.2.0.4的上面没有任何应用的数据库,我们来看看从v$session统计的活跃会话的情况:

你会正确采集活跃会话数吗?

你会正确采集活跃会话数吗?

我们可以看到,10.2.0.5的活跃会话数是49,而11.2.0.4因为多了几个后台进程,变成了54。我们再来看看处于活跃状态的会话的类别:

可以看到,其中51个活跃的会话是后台会话,用户会话只有1个。
看到这里,可能有些朋友会说了,这不是很简单的事情吗,统计活跃会话的时候,只要把后台进程排除掉不就可以了吗?确实,在大多数情况下,排除掉后台进程,活跃会话数反映出的系统活跃情况是真实的,不过当后台进程的工作状态处于不正常的时候,后台进程也会处于不正常的活跃状态,这种状态是十分有害的。如果我们完全排除掉了后台进程,可能会错过另外一种系统不正常状态。
实际上在V$SESSION里有一个十分有用的状态字段,STATE。

我们可以看到,STATE字段中有WAITING,WAITED SHORT TIME等,实际上处于WAITING状态的时候,会话是处于等待状态,而不是在使用CPU,此时的EVENT字段对应的等待事件是会话正在等待的。处于WAITED SHORT TIME状态的时候,这个会话的EVENT刚刚等待过的等待事件,而不是会话当前的等待事件。等待事件有很多种,很多会话在等待某个事件的时候是不会消耗系统资源的,这些“ACTIVE”的会话对系统来说,是不会产生什么资源负载的。因此,我们在统计活跃会话数的时候,要过滤掉这些会话。怎么过滤呢?我们再来看看这些活跃会话都在等待什么。

我们可以看到,大多数后台进程都在等待一些定时器或者消息,这些等待都是一些IDLE的等待。如果我们过滤掉所有的IDLE等待事件的会话,那么我们得到的活跃会话数指标就比较准确了:

这时候我们获得的活跃会话数指标才是较为真实的指标。讲了半天,实际上我们还有更为简单的获得活跃会话数的方法。从11g开始,oracle增加了一些metric,其中有一个ID为2147的Metric:

从这里获得的某个时间段内的平均活跃会话数,更能够反映出其真实的情况。实际上,我们从$session中获得的数据只是一个瞬间值,不一定能够真实反映出会话的真实活跃情况。

你会正确采集活跃会话数吗?》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/957.html