开发者社区> jeanron100> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

关于奇怪的并行进程分析(一)

简介: 在使用orabbix进行监控的时候,得益于使用 实时DB time监控的选项,对于几分钟内的性能抖动也能够狠容易的记录下来,而且会把这个监控的结果基本真实反应出来,不会随着两个快照的间隔被平均,这样性能问题的分析和排查如虎添翼,我直接通过性能抖动的情况就能够快速定位在哪个时间段内可能存在问题,然后借助ASH就可以得到一个更具有针对性的报告,可以精确到1分钟甚至秒级。
+关注继续查看
在使用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的情况,我们后续继续进行跟踪,揭开问题的真实面纱。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
python多进程通信实例分析
python多进程通信实例分析操作系统会为每一个创建的进程分配一个独立的地址空间,不同进程的地址空间是完全隔离的,因此如果不加其他的措施,他们完全感觉不到彼此的存在。那么进程之间怎么进行通信?他们之间的关联是怎样的?实现原理是什么?本文就来借助Python简单的聊一下进程之间的通信?还是那句话,原理是相同的,希望能透过具体的例子来体会一下本质的东西。
2837 0
并发进程
  多道程序设计提高了处理器的利用率,但是也带来了一些制约问题,比如,一个进程的执行有时要受另一个进程的制约。同时执行的程序形成了并发的进程。    并发的进程带来了很多问题,但是,也有很多方法可以解决。
785 0
并行编程之任务并行
任务并行库 (TPL) 基于任务的概念。术语“任务并行”是指同时运行的一个或多个任务。任务表示异步操作,在某些方面它类似于创建新线程或 ThreadPool 工作项,但抽象级别较高。任务提供两个主要好处: 系统资源的使用效率更高,可伸缩性更好。
568 0
并行编程之数据并行
任务并行库 (TPL) 是 .NET Framework 4 版的 System.Threading 和 System.Threading.Tasks 命名空间中的一组公共类型和 API。System.Threadings.Tasks 命名空间提供可简化并发和异步代码编写工作的类型。
735 0
+关注
jeanron100
Oracle ACE,《Oracle DBA工作笔记》作者 现就职于国内某互联网公司,擅长数据管理,数据迁移,性能优化,目前专注于开源技术,运维自动化和性能优化。
1178
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载