关于奇怪的并行进程分析(一) (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的情况,我们后续继续进行跟踪,揭开问题的真实面纱。
- Gulp 工作流中Sass 增量编译功能的探索
- Sass与Compass——回顾
- 苹果就“降速门”致歉;央行批扫码支付不正当竞争;王健林旗下公司遭集体裁员
- 姚期智教授:量子计算是千亿万亿级别的产业,或成为科技创新的引擎
- Powershell中禁止执行脚本解决办法
- 使用AsyncTask异步更新UI界面及原理分析
- 商家为何要做小程序?
- Android中关于dip和px以及转换的总结
- Python介绍
- python案例-用户登录
- 推荐个找代码示例的VS 插件 All-In-One Code Framework Sample Browser
- 明星推出定制AI形象,虚拟形象有何优势
- apache工作模式梳理
- Mysql的二进制日志binlog的模式说明
- JavaScript 教程
- JavaScript 编辑工具
- JavaScript 与HTML
- JavaScript 与Java
- JavaScript 数据结构
- JavaScript 基本数据类型
- JavaScript 特殊数据类型
- JavaScript 运算符
- JavaScript typeof 运算符
- JavaScript 表达式
- JavaScript 类型转换
- JavaScript 基本语法
- JavaScript 注释
- Javascript 基本处理流程
- Javascript 选择结构
- Javascript if 语句
- Javascript if 语句的嵌套
- Javascript switch 语句
- Javascript 循环结构
- Javascript 循环结构实例
- Javascript 跳转语句
- Javascript 控制语句总结
- Javascript 函数介绍
- Javascript 函数的定义
- Javascript 函数调用
- Javascript 几种特殊的函数
- JavaScript 内置函数简介
- Javascript eval() 函数
- Javascript isFinite() 函数
- Javascript isNaN() 函数
- parseInt() 与 parseFloat()
- escape() 与 unescape()
- Javascript 字符串介绍
- Javascript length属性
- javascript 字符串函数
- Javascript 日期对象简介
- Javascript 日期对象用途
- Date 对象属性和方法
- Javascript 数组是什么
- Javascript 创建数组
- Javascript 数组赋值与取值
- Javascript 数组属性和方法
- 短视频APP开发,简单计时功能
- LeetCode | 94.二叉树的中序遍历
- Druid 的整合
- LeetCode | 104.二叉树的最大深度
- Flutter 目录结构和项目资源
- iOS音视频接入- TRTC互动直播
- 【一天一大 lee】查找常用字符 (难度:简单) - Day20201014
- 金九银十准备换场地?对标腾讯T3的Android高级工程师面试大纲及时雨来了
- 【一天一大 lee】两两交换链表中的节点 (难度:中等) - Day20201013
- 【一天一大 lee】二叉搜索树的最小绝对差 (难度:简单) - Day20201012
- 有奖互动 | 腾讯云开发者社区 3 周年庆,我过生日,送你们礼物 ~
- 【一天一大 lee】分割等和子集 (难度:中等) - Day20201011
- 【一天一大 lee】寻找两个正序数组的中位数 (难度:困难) - Day20201003
- 【一天一大 lee】颜色分类 (难度:中等) - Day20201007
- 【一天一大 lee】树中距离之和 (难度:困难) - Day20201006