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

白鳝的洞穴 2020-09-16

1733

数据库的活跃会话数是一个十分重要的监控指标，如果某个系统的活跃会话数突然变得比平时高很多，那么我们就需要对该系统多加关注了，是不是系统的某些方面的争用加大了或者应用变慢了呢？记得以前帮一个快递公司做数据库服务，他们的系统经常在查单高峰期的时候资源不足，导致系统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中获得的数据只是一个瞬间值，不一定能够真实反映出会话的真实活跃情况。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

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

评论