学习
实践
活动
专区
工具
TVP
写文章
专栏首页bisal的个人杂货铺与IO相关的等待事件troubleshooting-系列2

与IO相关的等待事件troubleshooting-系列2

Troubleshooting步骤:

Troubleshooting与IO相关的等待

数据库性能调优方面一项关键的方法就是响应时间分析。找出时间都花费在数据库的哪些环节。

时间是性能调优中最重要的属性。用户通过交易或批处理任务的响应时间来感知系统的性能。

Oracle的响应时间分析使用如下公式:

Response Time = Service Time + Wait Time

响应时间=服务处理时间+等待时间

‘服务处理时间’使用‘CPU used by this session’统计数据来衡量。

‘等待时间’则是所有等待事件用时之和。

注:尽管很像,但这个公式绝对不是排队理论的基础公式。

通过分析总体响应时间不同组件的相对影响,可以使用AWR或statspack这样的工具进行性能调优,将调优的精力放到最消耗时间的组件中。

判断IO等待事件的真实重要性

        包括AWR和Statspack在内的许多工具都可以列出最重要的等待事件。Oracle 9i R2的Statspack报告之前的版本包含在了"Top 5 Wait Events"节。

        当看到这样的top等待事件列表,通常就会很容易地开始处理这些等待事件,但往往忽视了首先可以分析下他们对总体响应时间的影响。

        “Service Time”(例如CPU的使用)要远比“Wait Time”更重要,分析这些等待事件不会对节省“响应时间”有帮助。

        因此,应该将top等待事件花费的时间与“CPU used by this session”对比,将调优的精力放到最需要的地方。

        从Oracle 9i R2开始,“Top 5 Wait Events”已经改名为“Top 5 Timed Events”,通过统计session所用的CPU来衡量“Service Time”,并列到“CPU time”中。这就意味着可以更容易、更准确地衡量等待事件对总体“响应时间”的影响,正确地指导接下来的调优方向。

错误理解等待事件的影响:实例

接下来的两个真实案例说明了为什么需要查看“Wait Time”和"Service Time"两部分,对分析数据库性能的重要性。

实例1:Oracle 9i R2之前的Statspack

        下面是产生自46分钟的两个snapshot之间的Statspack报告“Top 5 Wait Events”节:

Top 5 Wait Events                                                             
~~~~~~~~~~~~~~~~~                                             Wait     % Total
Event                                               Waits  Time (cs)   Wt Time
-------------------------------------------- ------------ ------------ -------
direct path read                                    4,232       10,827   52.01
db file scattered read                              6,105        6,264   30.09
direct path write                                   1,992        3,268   15.70
control file parallel write                           893          198     .95
db file parallel write                                 40          131     .63
         -------------------------------------------------------------   

        从以上的列表,我们很可能倾向于立即开始查找“direct path read”和“db file scattered read”等待之间的原因,尝试调优他们。这种方法没有考虑到“Service Time”。

        从同一份报告中得到的“Service Time”如下:

Statistic                                    Total   per Second    per Trans  
--------------------------------- ---------------- ------------ ------------  
CPU used by this session                   358,806        130.5     12,372.6   

        让我们来做一下简单的计算:

'Wait Time' = 10,827 x 100% / 52,01% = 20,817 cs

'Service Time' = 358,806 cs

'Response Time' = 358,806 + 20,817 = 379,623 cs

        如果现在我们来计算所有“Response Time”组件的百分比:

CPU time                    = 94.52%
direct path read            =  2.85%
db file scattered read      =  1.65%
direct path write           =  0.86%
control file parallel write =  0.05%
db file parallel write      =  0.03%

        现在就明显了,与IO相关的等待事件对于总体响应时间来说并不是真正耗时的组件(少于6%),因此解析来的调优应该聚焦在服务处理时间组件上,例如CPU消耗。

实例2:Oracle 10i R2之后的AWR

注意:类似的信息也会显示在Oracle 9i R2以后的Statspack报告:

Top 5 Timed Foreground Events 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
                                                          Avg  
                                                         wait   % DB 
Event                                 Waits     Time(s)   (ms)   time Wait Class 
------------------------------ ------------ ----------- ------ ------ ----------
DB CPU                                           33,615          82.0           
db file sequential read           3,101,013       7,359      2   18.0 User I/O  
log file sync                       472,958         484      1    1.2 Commit    
read by other session                46,134         291      6     .7 User I/O  
db file parallel read                91,982         257      3     .6 User I/O  

        在AWR中,更容易看到CPU是最耗费时间的,因为CPU组件也包括在“Top 5 Timed Foreground Events”节。从上面的例子,我们能够再次看到等待事件的用时少于20%,家下来的调优重点应该放在服务处理时间的组件上,例如CPU消耗。

(未完待续)

本文参与 腾讯云自媒体分享计划 ,欢迎热爱写作的你一起参与!
本文分享自作者个人站点/博客:http://blog.csdn.net/bisal复制
如有侵权,请联系 cloudcommunity@tencent.com 删除。
登录 后参与评论
0 条评论

相关文章

  • 与IO相关的等待事件troubleshooting-系列1

    近来XX应用充分暴露出开发人员最初只关心功能,未考虑性能的问题,夜维、OLTP应用均出现了不同程度的与数据库相关的性能问题。

    bisal
  • 与IO相关的等待事件troubleshooting-系列6

    当Oracle从多个数据文件并行读到内存(PGA或Buffer Cache)的非连续缓冲时,可以看到这种等待事件。在恢复操作或为了优化而预处理缓冲(代替执行多...

    bisal
  • 与IO相关的等待事件troubleshooting-系列7

            这种等待事件通常产生于一个或多个控制文件的IO。像redo日志切换和检查点事件,都会产生频繁的控制文件访问。因此调优这些实践可以间接地影响这种等...

    bisal
  • 与IO相关的等待事件troubleshooting-系列4

            这是一种最常见的IO相关的等待。大多数情况下,他指的是单块读,例如索引数据块或通过索引访问的表数据块,也能在读取数据文件头块时看到这种等待事件。...

    bisal
  • 与IO相关的等待事件troubleshooting-系列3

            使用Statspack类似的工具对数据库响应时间分析之后,已经表明与IO相关的等待事件限制了系统性能,有许多的方法可以判断这种问题。

    bisal
  • 与IO相关的等待事件troubleshooting-系列5

            这是另一种常见的等待事件。他产生于Oracle从磁盘读取多个块到Buffer Cache中非连续(" scattered")缓存的时候。这...

    bisal
  • 与IO相关的等待事件troubleshooting-系列8

            Redo日志活动期间会有很多的等待事件,而且他们大多是和IO相关的。最重要的两个就是‘log file sync’和‘log file para...

    bisal
  • 与IO相关的等待事件troubleshooting-系列9

            这种等待事件的产生原因是包含DBWR进程和IO Slaves的Buffer Cache操作。

    bisal
  • 等待事件统计视图 | 全方位认识 sys 系统库

    在上一篇《内存分配统计视图 | 全方位认识 sys 系统库》中,我们介绍了sys 系统库如何查询内存事件统计信息和buffer pool统计信息,本期的内容先给...

    老叶茶馆
  • 实战 MySQL 锁等待问题的定位与排查

    在 MySQL 的实际使用中,常常会遇到一条 SQL 执行非常慢的情况,此前我们总结了一系列博客来排查相关的问题:

    用户3147702
  • 初相识|performance_schema全方位介绍(PFS)

    现在,很高兴的告诉大家,我们基于 MySQL 官方文档加上我们的验证,整理了一份可以系统学习 performance_schema 的资料分享给大家,为了方便大...

    老叶茶馆
  • 配置详解 | performance_schema全方位介绍

    在上一篇 《初相识 | performance_schema全方位介绍》 中粗略介绍了如何配置与使用performance_schema,相信大家对perfor...

    沃趣科技
  • 按 file 分组统计视图 | 全方位认识 sys 系统库

    在上一篇《按 user 分组统计视图 | 全方位认识 sys 系统库》中,我们介绍了sys 系统库中按 user 分组统计的视图,类似地,本期的内容将为大家介绍...

    老叶茶馆
  • Tomcat NIO(5)-整体架构

    在上一篇文章里我们主要介绍了 tomcat NIO 的数据处理类,即实现读写封装的Request 和 Response,在这里我们主要介绍 NIO 整体架构。

    TA码字
  • 通过 JFR 与日志深入探索 JVM - 1. JFR 简介与发展

    我们都知道,黑匣子是用于记录飞机飞行和性能参数的仪器。在飞机出问题后,用于定位问题原因。JFR(Java Flight Record) 就是 Java 的黑匣子...

    干货满满张哈希
  • Tomcat NIO(1)-开篇

    在日常工程或者开发中避免不了引入 web 服务器(或者是 tcp 服务器),常用服务器有tomcat,jetty,undertow,netty 等等,对于这些服...

    TA码字
  • Java网络编程与NIO详解2:JAVA NIO 一步步构建IO多路复用的请求模型

    本文转载自:htJava网络编程与NIO详解2:JAVA NIO 一步步构建IO多路复用的请求模型

    Java技术江湖
  • Java网络编程和NIO详解3:IO模型与Java网络编程模型

    本系列文章将整理到我在GitHub上的《Java面试指南》仓库,更多精彩内容请到我的仓库里查看

    Java技术江湖
  • How to Tell if the I/O of the Database is Slow - 2

            单块IO,指一次只读一个块。例如,当一个session等待一个单块IO时,典型的等待事件就是“db file sequential read”,...

    bisal

扫码关注腾讯云开发者

领取腾讯云代金券