OWI性能诊断.ppt

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,.,*,OWI,性能诊断,讲师：魏兴华，新彩软件数据库架构师,.,2,OWI,优化方法论,4,响应时间模型,3,3,旧的优化理论,-,命中率，及其缺陷,3,1,开车与,OWI,Log File Sync,优化,5,outline,.,Hold,一下，我们先来看看历史。,.,Buffer Cache,Library Cache,PGA,Dictionary cache,Latch,Sort In Memeory,Hit ratio,各种命中率,.,一般来说内存的命中率高就代表“性能好”,访问速度：,Cpu cache,SGA,File system cache,Raid cache,Storage cache,disk,早期的优化是围绕着命中率来展开的,也意味着优化的方法常常是通过提升硬件能力来提高命中率,进而“提高性能”,可是,总靠谱吗？,.,命中率是被平均的,命中率不是征兆学的,命中率往往通过提升硬件来解决数据库性能问题,命中率不容易理解,命中率高与系统性能没有直接的因果关系,命中率是与吞吐量、响应时间无关的,命中率的缺陷,.,一个小故事,分享一个面试题：,为什么,select*from test where id=1,瞬间返回结果,而,update test set name=xxxx where id=1,很慢，没有响应？,.,习惯性的提问：它在等什么？,.,开车与,OWI,.,小王接到领导电话，需要下午,2,点从无锡新区到市中,心参加一个重要会议，他预估了路程,30,分钟可以到,达，于是悠闲的吃过中饭，收拾好东西后，一点半,开始出发，但是另他意外的是他足足花了,50,分钟才,到，他迟到了！他感觉到客户对他的迟到产生了反感,，他悔恨万分自己错估了时间。如果你是小王，会,如何分析这次迟到的原因？,开车与,OWI,.,红绿灯太多？,堵车太严重？,遭遇了交通事故？,车没油了,?,开车速度太慢？,Why?,为什么迟到,.,以上的分析大部分人都能想出来，也非常的合理，既然,实际到达的时间比预估的长，有可能是开车速度过慢，,或者是发生了一些事件导致等待。这其中其实隐藏了时,间模型的方法论。在我们的例子里就是：,总的路程时间,=,开车时间,+,等待时间，开车速度过慢，会,导致开车时间过长，进而导致总时间过长，等待时间过,长同样会导致总的路程时间过长。,开车与,OWI,.,我用不同的颜色标识出了开车时间和等待时间，等待时,间包含了两次堵车的,10,分钟，红灯的,3,分钟。假如再给,小王一次机会，他该如何调整方案来保证半个小时可以,到达呢？,开车与,OWI,.,降低开车时间，可以通过加快开车速度来实现，或者选择较短的路程，如上图，如果有直线的路程，可以明显减少开车的路程，进而降低开车时间。,降低等待时间，比如是不是可以绕一个红绿灯比较少的路，或者在行人、车辆比较少的情况下的出行,如何优化？,.,响应时间,=,服务时间,+,等待时间,服务时间是进程占用,CPU,的时间，对应到我们上面的例子里就是开车时间，等待时间是进程在继续处理任务之前等待某些特定资源可用的时间，对应到我们上面的例子里就是等待红绿灯、堵车的时间。这个公式是基于这样一个事实：在任何时刻，进程或是在,CPU,上进行任务计算，或是脱离,CPU,运行队列处于等待状态。,响应时间模型,.,对应到数据库里，在会话级别，服务时间对应,v$sesstat,（做了什么）里的,CPU used when call started,，等待时间对应,v$session_event,（时间花哪了）里特定会话的所有前台进程相关等待事件的,time_waited,之和。,CPU used when call started,又被细分为：,CPU used for parsing,，,CPU used for recursive calls,，,CPU used for normal work,。（需要注意的是，,CPU,相关的统计信息是在一个,call,结束后才会被统计更新，而等待事件统计信息的资料将以实时的模式更新。因此一个耗时很长的,SQL,将不会更新他的,CPU,信息直到其执行结束）,数据库响应时间,.,数据库响应时间模型更加接近终端用户的体验，也将数据库性能调优提升到了一个新的高度。,DBA,在进行性能跟踪诊断的时候，时刻应该把响应时间牢记心中，而响应时间慢，往往是由于等待某些资源可用的时间过长导致。,为什么关注响应时间比关注命中率重要？因为时间对于终端用户的感受是最直接的，一位开发向你抱怨一个任务执行缓慢，或者网站的一位客户投诉网页打开慢，他们都是对响应时间的不满，他们根本不关心是因为某种命中率低或者你主机的内存、,CPU,资源、,IO,资源不足等等原因才来抱怨的。,响应时间模型的好处,.,OWI,表达的内容跟等待事件相关。继续以我们上面的开车为例，如果可以设计一个功能，能够跟踪小王当前开车的状态，并且在他开车发生等待的情况下，提供给你一个接口，通过这个接口可以查询当前他在发生什么等待、发生在这个等待上的时间、次数，并且保留他本次路程里，所有发生的等待的事件（红绿灯、堵车、等待行人通过）、等待的次数、等待的总时间，那么这个功能对应到,ORACLE,里就叫,OWI-oracle wait interface,，翻译为中文叫,Oracle,等待事件接口。,什么是,OWI,.,我们举一个数据库的例子：,update test set a=1 where id=1;,commit;,这个事务一共花费了,1024ms,，我们可以通过,v$sesstat,，,v$session_event,了解到整个执行过程,什么是,OWI,.,OWI,记录的等待过程,.,从数据库获取等待过程,SELECT EVENT,TIME_WAITED,TOTAL_WAITS,FROM V$SESSION_EVENT,WHERE SID=485,AND WAIT_CLASS Idle,UNION ALL,SELECT B.NAME,VALUE,NULL,FROM V$SESSTAT A,V$STATNAME B,WHERE A.STATISTIC#=B.STATISTIC#,AND B.NAME=CPU used when call started,AND A.SID=485;,.,从数据库获取等待过程,EVENT TIME_WAITED TOTAL_WAITS,-,Disk file operations I/O 1 4,latch:cache buffers chains 0 1,log file sync 5 1,db file sequential read 13 4,db file scattered read 2 1,enq:TX-row lock contention 372 1,SQL*Net message to client 0 36,CPU used when call started 10987,.,我们开启了一个事务并提交，这个过程里，经过了两次,db file sequential read,，共,6ms,，一次,enq:TX-row lock contention,，共,1s,，一次,log file sync,，共,6ms,，共发生等待,1012ms,。这些等待在,ORACLE,里称为,wait event,，对这些等待进行计数（次数,+,时间），并且通过各种,v$,视图进行展现的功能接口叫做,OWI,。,什么是,OWI,.,版本,等待时间总数（大约）,7.0.1,100,8I,220,9I,400,10GR2,874,11GR2,1152,12CR1,1567,各版本等待次数统计,.,Oracle,的等待事件之所以越来越多，一方面是由于新增的功能导致，另一方面也是把之前没纳入到等待事件中的系统调用重新开发，然后增加到新版本中来。比如开车过程中可能会遭遇堵车、红绿灯、行人过马路种种等待，一开始系统的,OWI,基于这三个等待来进行计数、展示，但是后来可能发现交通事故其实也是等待的一种，因此在下个版本发布的时候，将其纳入进来。,等待事件越来越多,.,OWI,是量化的。,OWI,记录了所有等待事件的等待次数、等待时间、平均等待时间。在没有,OWI,的情况下遭遇系统缓慢，可能会通过种种猜测来进行试错，活跃会话数过多？系统可能会有锁等待？,buffer cache,命中率太低？硬解析过多？但是如果是通过,OWI,分析，那么就可以理直气壮的得出，分析近半个小时的等待事件，出现了大量的,shared pool latch,争用，占整个,db time,的百分之三十，而正常情况这一指标仅仅只占百分之五，并且结合每秒硬解析数看，这个指标也非常高，因此可以推论出是由于硬解析过高导致的数据库性能下降。由此可以看出，熟练使用,OWI,后，能够摆脱以往优化性能问题时候的”猜测性“，将复杂的性能优化问题，解释为任何人都容易理解的量化的值,。,OWI,优点,.,OWI,是更贴近“自然”的分析理论。拿我举的开车的例子来说，大部分人都会想到细分出等待过程中的各个环节，然后找出最耗时的几个环节，有目的性的进行优化。,OWI,是征兆学的。,OWI,优点,.,不包含,CPU,统计，可以通过,v$sesstat,弥补,早期版本缺少历史数据,不完全的等待时间,以,OWI,为出发点优化数据库性能总不失为一个好的开始。但是它不能告诉你全部。,OWI,的缺点,.,视图名,作用,v$session_wait,记录,session,的当前等待状态，具有实时性,，,10G,后逐渐被,v$session,取代,v$event_name,记录了等待事件的名称，静态表,v$system_event,自本次系统启动以来累计的等待事件的次数、等待总时间，系统级别,v$session_event,记录具体,session,自连接以来等待事件的次数、等待时间，,session,级别,v$event_histogram,等待事件的直方图,v$active_session_history,会话状态、等待事件历史，,Dba_Hist_Active_Sess_History,v$session_wait_history,会话最近十次的等待事件,OWI,相关工具,.,理论很简单，转变思路很难,转变思路,.,LOG FILE SYNC,commit,操作,rollback,操作,DDL,操作（,DDL,操作实施前都会首先进行一次,commit,）,DDL,操作导致的数据字典修改所产生的,commit,某些能递归修改数据字典的操作：比如查询,SEQ,的,next,值，可能会导致修改数据字典。一个典型的情况是，,SEQ,的,cache,属性设置为,nocache,，那么会导致每次调用,SEQ,都要修改数据字典，产生递归的,commit,.,LOG FILE SYNC,.,LOG FILE SYNC,.,LOG FILE SYNC,.,Group Commit,c1,作为一个,commit record,已经被拷贝到了,log buffer,里，接着前台进程通知,lgwr,去写日志，在前台进程,post lgwr,到,lgwr,真正开始写之前，非常可能存在着时间差，就在这个时间差里，,c2,g1,c3,也已经把相应的日志拷贝到了,log buffer,里，其中,c1,c2,c3,是,commit,的记录，,g1,仅仅是普通的事务日志，不是,commit,日志。在,lgwr,真正开始写之前，它会去检查当前,log buffer,的最高点，发现在,c3,位置处，把这个点作为此次刷新日志的目标，把,c1,c2,g1,c3,的日志都刷新到磁盘。虽然刷新日志这个操作是由,c1,出发的，但是,c2,g1,c3,也是受惠者搭了便车，日志也被刷新到了日志文件里，这个功能叫组提交,.,LOG FILE SYNC,调优,作为通用的,log file sync,的诊断、调优方法，一般可以通,过诊断系统的,IO,延迟为多大，,cpu,资源是否充足来判断哪,里出现了问题。,IO,延迟的诊断、调优（,IO,抖动造成,log file sync,虚高，拼吞吐？,IOPS,？）,cpu,资源的诊断、调优（调高,LGWR,优先级有用？）,调优应用（减少,commit,）,数据库调优（块大小、减少,logmember,、,redo size,、,log switch,sequence,）,操作系统调优：内存、网络（,lgwr,内存,page out,lgwr async DG,）,.,v$event_histogram,.,新的调优手段,10G,后，事务的提交操作可以不等待日志持久化的完成（看不到,log file sync,等待）。,10GR1,的时候，,ORACLE,公司默默的推出了一个参数：,commit_logging，,这个参数可以有四种组合：,commit write batch|immediatewait|nowait,，其中,wait/nowait,与事务的持久化相关。,10GR2,版本发布的时候，这个参数被拆成了,2,个参数，,commit_logging,，,commit_write,，,10GR2,拆分后的参数，更能准确表达参数的意图。,.,参考文献,:,第二章、第六章,tanel poder:Understanding LGWR,Log File Sync Waits and Commit Performance,Riyaz Shamsudeen:,Closson:,You!,.,