关于奇怪的并行进程分析(一) (r6笔记第41天)

在使用orabbix进行监控的时候,得益于使用 实时DB time监控的选项,对于几分钟内的性能抖动也能够狠容易的记录下来,而且会把这个监控的结果基本真实反应出来,不会随着两个快照的间隔被平均,这样性能问题的分析和排查如虎添翼,我直接通过性能抖动的情况就能够快速定位在哪个时间段内可能存在问题,然后借助ASH就可以得到一个更具有针对性的报告,可以精确到1分钟甚至秒级。 可以看到在早上的七点左右的时候还是有一些明显的性能抖动,DB time会瞬间提高。

这对于一个OLAP的系统来说还是有些不正常的。 并行session的情况如下,可以看到在问题发生的时间段里,产生了大量的并行session.

而且同时我也收到了orabbix的告警邮件。 监控项目: Session Active:153 *UNKNOWN*:*UNKNOWN* ------------------------------------ 故障时间:2015.08.27-07:22:04 所以这个问题还是需要关注一下,这种情况就犹如给一个静坐的人用针突然扎一下,会出现很明显的性能抖动。 首先为了进一步验证,得到了在快照时间内的负载信息,可以看到在问题发生的时间内DB time还是蛮高的。 BEGIN_SNAP END_SNAP SNAPDATE DURATION_MINS DBTIME ---------- ---------- --------------------------------- ---------- 36343 36344 27 Aug 2015 04:00 60 85 36344 36345 27 Aug 2015 05:00 60 118 36345 36346 27 Aug 2015 06:00 60 150 36346 36347 27 Aug 2015 07:00 60 180 36347 36348 27 Aug 2015 08:00 60 137 36348 36349 27 Aug 2015 09:00 60 140 36349 36350 27 Aug 2015 10:00 60 67 36350 36351 27 Aug 2015 11:00 60 8 所以说得到了上面的信息,能够让我们更加清楚问题的背景和基本情况。 查看alert日志,在问题发生的时间段里,没有看到其它异常的信息。 Thu Aug 27 00:07:08 2015 Archived Log entry 63315 added for thread 1 sequence 688962 ID 0xa4527950 dest 1: Thu Aug 27 00:07:23 2015 LNS: Standby redo logfile selected for thread 1 sequence 688964 for destination LOG_ARCHIVE_DEST_3 Thu Aug 27 00:07:32 2015 Archived Log entry 63317 added for thread 1 sequence 688963 ID 0xa4527950 dest 1: Thu Aug 27 00:07:38 2015 Thread 1 advanced to log sequence 688965 (LGWR switch) 所以从数据库层面来说,可能没有什么明显的活动。 但是问题不可能无中生有,我们怎么去找到问题的根源呢,为了更加精确的定位问题,我们需要借助于ASH来还原那个时间段的问题情况。 为了排除Orabbix监控的延迟,我抓取的时间范围略大了些,是7分钟内的ash. 得到的报告如下,可以看到在问题发生的时间段内,取样数也确实蛮高的。

Sample Time

Data Source

Analysis Begin Time:

27-Aug-15 07:15:00

V$ACTIVE_SESSION_HISTORY

Analysis End Time:

27-Aug-15 07:22:05

V$ACTIVE_SESSION_HISTORY

Elapsed Time:

7.1 (mins)

Sample Count:

177

Average Active Sessions:

0.42

Avg. Active Session per CPU:

0.05

top user event为:

Event

Event Class

% Event

Avg Active Sessions

SQL*Net vector data from client

Network

39.55

0.16

Standby redo I/O

System I/O

2.26

0.01

RFS write

System I/O

1.13

0.00

所以对于这个问题的分析可能会有一定的难度,因为矛头似乎都指向了备库相关的问题。

对于等待事件SQL*Net vector data from client可以参考 Doc ID 1311281.1 说法是可以忽略。我们可以先把这个问题放一放,来通过其他的思路来分析一下。 首先数据库的负载突然提高,如果单纯是因为备库的原因,为什么不是其它时间段内,白天的时候没有任何报警。白天的负载更高,更应该出现问题才对。 所以这种情况应该还是有一定的触发条件,但是查看了crontab也没有什么发现,那么很可能就是scheduler相关的。 我们怎么来推论呢。 首先的考虑就是后台的scheduler,结果查看还是默认的晚上10点左右,所以到早上的那个时间段应该不会有直接的影响。 那么scheduler狠可能就是用户自定义的。 限定在问题时间段内,得到的信息如下 select owner,job_name,last_start_date,end_date,NEXT_RUN_DATE from dba_scheduler_jobs where last_start_date between to_timestamp('2015-08-27 05:00:00','yyyy-mm-dd hh24:mi:ss') and to_timestamp('2015-08-27 08:00:00','yyyy-mm-dd hh24:mi:ss') OWNER JOB_NAME LAST_START_DATE ------- -------------- --------------------------------------------- APP_TEST SYN_D 27-AUG-15 07.11.00.002185 AM ASIA/SHANGHAI APP_TEST SYN_E 27-AUG-15 06.15.00.809059 AM ASIA/SHANGHAI APP_TEST SYN_F 27-AUG-15 06.12.05.312974 AM +08:00 APP_TEST SYN_G 27-AUG-15 05.00.40.797679 AM ASIA/SHANGHAI 可以看到确实还是有scheduler job在运行,而且时间也基本是相符的。 LOG_ID LOG_DATE OWNER JOB_NAME STATUS ---------- ---------------------------------------- ---------- --------------------- ------------- 241839 27-AUG-15 07.30.00.140947 AM +08:00 TEST_APP SYN_D SUCCEEDED 241836 27-AUG-15 07.05.46.398691 AM +08:00 TEST_APP SYN_E SUCCEEDED 241840 27-AUG-15 07.30.01.319849 AM +08:00 TEST_APP SYN_F SUCCEEDED 241841 27-AUG-15 07.35.00.912152 AM +08:00 TEST_APP SYN_G SUCCEEDED 从以上的信息可以猜想可能是scheduler job引发的大量并行session的情况,我们后续继续进行跟踪,揭开问题的真实面纱。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-08-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏以南小隐-数通那些事儿

IOL镜像导入篇《GNS3 2.1.3 环境搭建系列教程四》

6773
来自专栏Golang语言社区

Golang实现ping

ICMP部分的结构 报头 ICMP报头从IP报头的第160位开始,即第20个字节开始(除非使用了IP报头的可选部分)。 Bits 160-167 168-175...

8576
来自专栏SDNLAB

VXLAN与EVPN的结合使用

EVPN是近几年最热门的网络技术之一。如果你还没听过EVPN,你的网络技能可能已经落伍了,赶紧看看之前的《EVPN简介》吧!EVPN全称是Ethernet VP...

4203
来自专栏Timhbw博客

Hexo-完全免费全平台搭建个人博客(2)-域名主题设置

2017-03-1011:01:58 发表评论 913℃热度 Hexo-完全免费全平台搭建个人博客(1)-整体搭建 上一篇文章把 Hexo 博客整体搭建一遍了...

37712
来自专栏杨建荣的学习笔记

Data Guard高级玩法:通过闪回恢复failover备库 (r10笔记第7天)

今天看到有一个网友提了一个问题,描述很简短 测试DG时,主库不能宕机,如何测试failover? 其实这个需求从业务层面来说是合理的,一...

3586
来自专栏SDNLAB

OpenDaylight控制器MD-SAL解析

一.前言 OpenDaylight开源控制器是业界当前比较流行的SDN控制器,其受到业界关注的主要原因是其具有良好的适应性,可适配不同的南向接口以控制现网各种各...

50410
来自专栏Golang语言社区

从零开始创建一个基于Go语言的web service

20个小时的时间能干什么?也许浑浑噩噩就过去了,也许能看一些书、做一些工作、读几篇博客、再写个一两篇博客,等等。而黑客马拉松(HackAthon),其实是一种自...

4439
来自专栏NetCore

微信公众平台快速开发框架 For Core 2.0 beta –JCSoft.WX.Core 5.2.0 beta发布

写在前面 最近比较忙,都没有好好维护博客,今天拿个半成品来交代吧。 记不清上次关于微信公众号快速开发框架(简称JCWX)的更新是什么时候了,自从更新到支持.Ne...

2588
来自专栏Jerry的SAP技术分享

利用CRM中间件Middleware从ERP下载Customer Material的常见错误

下图是我在ERP创建的Material,为其维护了一个Customer Material AOP。

3848
来自专栏Android源码框架分析

Android进程保活-自“裁”或者耍流氓

本篇文章是后台杀死系列的最后一篇,主要探讨一下进程的保活,Android本身设计的时候是非常善良的,它希望进程在不可见或者其他一些场景下APP要懂得主动释放,可...

4711

扫码关注云+社区