首页 > Notes, Oracle, Tuning > Method R及相关阅读
10/03 16

Method R及相关阅读

本文记录的是本人近期阅读的Method R相关文章的一个汇总总结。

top关于Method R

Method R最早由Cary Millsap以及Jeff Holt在他们2003年出版的书《Optimizing Oracle Performance》中提出,这种方法提出之初是“To create a performance optimization method that works and that can be taught effectively to the typical Oracle database administrator. (OOP序言)”,就是说这方法是为Oracle性能优化而建,但在从最近Cary Millsap的访谈和他的最新文章Thinking Clearly about Performance中可以看到他已经将Method R的应用从Oracle数据库扩展到了电脑软件甚至是一切流程的优化上,当然他的公司Method R Corporation也是为此而建的。

topThinking Clearly About Performance

Thinking Clearly about Performance可以认为是《Optimizing Oracle Performance》中关于Method R的一个简化版,如果没有看过OOP的话,仔细的阅读这篇文章也能对Method R有深刻的理解。

文章的大概总结:

  • 什么是性能:性能就是完成一个指定任务的时间,性能就是时间
  • 性能的衡量与描述: 响应时间和吞吐率,这两个是相关的,但却不似线性相关
  • 分析性能问题:序列图能直观的表现一个任务的响应时间,但是却仅限于简单的任务。Profile才是分析响应时间的好工具。
  • 解决性能问题:阿姆达尔定律、风险管理、效率这几个都是在考虑解决性能问题方案时候必须要注意的问题。
  • 负载的衡量:负载可以说的系统资源的利用率,由排队论知道负载对于响应时间有着巨大的影响。排队延时和资源拐点论是在进行容量规划时必须考虑的问题,容量规划最重要的一点就是保证系统在运营高峰期时的资源消耗不会越过拐点。
  • 竞争延时:并行处理的系统中除了排队延时之外还有个影响很大的就是竞争延时,M/M/m理论中的多个通道是相互独立的,而实际系统中却不是这样,并行的进行总会在一些公共资源上发生竞争,而且最严重的就是这种竞争根本无可预测性,因为其中会有人为的因素在里边。
  • 性能的测试和测量:测试需要根据实际系统的情况来进行,要求高的测试多,要求低的测试少。性能测量是要注意必须要测量那些应该测量的,而不是只捡简单事情做,代理测量是很多错误判断的来源。
  • 性能应该作为软件的特性:考虑性能问题不能在软件成型之后,而是在软件设计之初就要考虑到的,在代码编写的过程中就将插桩代码作为软件的一部分,这样系统成型之后就能很方便的查找性能问题。将性能测量代码写入软件中最终能使你的系统永远的都能以最快的速度跑起来,而不至于因为性能不好而抓瞎。

topCary Millsap访谈

Questioning Method R: An Interview with Cary Millsap

什么是Method R?

Method R定义了4个简单步骤来解决问题:

  1. 找出对你来说最重要的任务 (Identify the task that’s the most important to you.)
  2. 详尽的测量其响应时间(R) (Measure its response time (R). In detail.)
  3. 使用最经济、最有效的方法去优化它 (Optimize that response time in the most economically efficient way.)
  4. 重复上述步骤直到系统达到经济上的最优化 (Repeat until your system is economically optimal.)
Method R与ASH/AWR
  • Method R是一套用于完成特定目标的流程。
  • ASH/AWR是Oracle数据库中的一个功能模块,尽管可以用它来部分的实现Method R。
Method R与Oracle Trace数据
Method R并不只是适合于Oracle数据库调优,它适合于任何过程的优化 (It’s simply a method for optimizing a process—any process)。

文章其他内容还包括:

  • 讨论了为什么现在还说Oracle性能调优很难,问题的关键在于方法不对。
  • 升级硬件并不能解决问题的例子
  • Method R的发展远景
  • Oracle数据库的日常维护,都要做些什么样的日常工作
  • 系统慢怎么办,内容与My Whole System Is Slow. Now What?基本类似
  • 是否要使用hint的问题:优先考虑的是为什么数据库自动选择的执行路径不对,先把这个问题解决。

top关于并行度、响应时间、吞吐率

Doug在Time Matters: Throughput vs. Response Time一文中写出了调优时的两个目标:1、提高单个任务的响应时间;2、提供系统的吞吐率。但响应时间和吞吐率是一对不可调和的矛盾,这一点Cary在他的Thinking Clearly about Performance已经有过阐述,在系统优化后中,我们不可避免的要在这两个目标之前作出一些平衡。

文章通过一个测试的例子表明:在单个会话的响应时间做到最优的时候,提高会话的并行度,会造成单个会话响应时间的提高,但同时也会提高整个系统的吞吐率,但是单并行度达到一定量的时候吞吐率将会下降,达到一个拐点。【实际上这也就是Thinking Clearly about Performance中说的那个拐点,只不过那篇文章中说的响应时间是调优任务的响应时间,而不是单个会话的。】

Doug在文中最终想说的话就是:性能优化不能也不应该只是独立的局限于某个进程(或者会话)的性能 (performance analysis, response time tuning, workload management (call it what you will) can’t and shouldn’t be limited to looking at the performance of an individual session in isolation.)

同样的Cary写了一篇Throughput versus Response Time来响应Doug的这篇文章,Cary总结Doug的观察结果说拐点其实就是 平均响应时间/吞吐率 达到最小的时候。同时他也提出了几个观点:

  • 批量处理的任务和交互式任务的性能衡量的要求是不一样的,批量任务注重吞吐率,而交互式任务注重响应时间。另外批量任务和交互式任务的另一个区别是执行时间,通常前者可预测、可控,也就是把系统CPU搞到100%也不要紧;而后者就不一样了,因此通常在处理交互式任务的系统中要预留部分空间的资源应对突发事件,以免搞的手忙脚乱的。
  • 对单个任务响应时间的优化也是对整体吞吐率的优化,关键是这种响应时间的优化是建立在只是去掉那些无用的浪费而非影响别人上就行了。

亮点:You can’t know whether a system is optimal without knowing whether its tasks are efficient, and you can’t know whether a given task is efficient without profiling it.

topMethod R的应用讨论和实例

My Whole System Is Slow. Now What?

系统慢,怎么办呢?在用户严重他所使用的功能就代表了整个的系统,而在DBA的眼中,系统可就是整个数据库了,这是一个要认真注意的问题。所以,当用户说系统很慢,兴许就是某个功能或者说在处理某项任务时慢了而已,或者也可能是有17个任务处理的慢了,但是最终原因却只有一个。因此,当用户说慢的时候,不要急,到用户那里去看,去了解系统到底那里慢了,如果有很多功能都慢的话,找出最重要的那个任务,然后测量响应时间,再接着去解决。

【就两部分:先要知道该怎么行动,然后去行动。】

测量相应时间最大的好处就是不管问题出在哪儿,你都能看到它。如果是代码写的不好,你会看到它;如果是别的程序抢占了太多的资源,你会看到它;如果是磁盘控制器有问题,你会看到它;如果是某些参数要调整,你也能看到。 (The great thing about measuring response time is that no matter what the problem is, you’ll see it. If the program you’re watching is poorly written, you’ll see it. If some other program is hogging too much of a resource that your program needs, you’ll see it. If you have a bad disk controller, you’ll see it. If some parameter needs adjusting, you’ll see it.)

On the Importance of Diagnosing Before Resolving

这边文章里面Cary使用了一个优化减少超市购物时间的例子来说明如何在着手解决之前如何对问题进行详细的诊断分析以及如何解决它。Cary在文中先总结了使用Method R解决问题的基本步骤:

  1. (问题诊断阶段)按照响应时间递减的方向依次检查每个子任务(Profile中的每一行)
    1. 能否在不损失功能的情况下把这个任务完全消除掉? 【其实就是明确自己的目标,把那些与实现目标无关的项目先去除掉。】
    2. 能否减少每个子任务的执行时间?
  2. (问题解决阶段)在可行的解决方案中选中净效益最高的方案(就是以最小的开销获取最大的收益) 【这也就是资本家的目标了】
    之后Cary使用超市购物的例子详细的解析了Method R解决问题的步骤,他最终总结的一点就是:

I’m not saying you should stick to the top line of your profile until you’ve absolutely conquered it.

你无须死盯着Profile的最顶上哪一行然后说非要搞定它不可,真正需要的还是具体问题具体分析。

Performance Optimization with Global Entry. Or Not?

这是一篇通过分析优化出机场的时间来说在进行系统优化时需要怎么去考虑问题,文章写的稍微有些话多了点 -_||。Cary在文中提出了两个自己分析问题时的观点:

  • 我根本不关心子系统(或资源)的优化,我关心的是(整个任务)响应时间 (I really don’t care about subsystem optimization; I care about response time. )
  • 在进行优化时,首先要明确你的目标是什么 (When you optimize, you must first know your goal. )
    其实这两个观点基本的意思是一样的,为什么会不关心子系统的优化呢?要回答这个还是要从优化的目标出发,优化的目标就是降低系统(或任务)的响应时间,而在没有明确一个子系统(或资源)的优化对总的响应时间是否有影响的情况下去优化它是没有意义的,正确的做法就是仔细分析整个任务的执行过程(出机场所要经历的所有过程),找出对系统响应时间影响最大的进行优化(拿行李是最消耗时间的),而不是随便找个过程就着手优化(Global Entry只对Passport Control有影响,但是Passport Control过程却是包含在拿行李这个过程中的隐含延时[latency hidding],也即优化Passport Control过程是白费的),这就是Cary说不关心子系统(或资源)优化的原因了。

延时隐藏(latency hidding)很有意思,平时经常用却没注意,学习文章可以参考Latency HidingLatency Hiding For Fun and Profit

Dang it, people, they’re syscalls, not “waits”…

在Method R中,响应时间的公式是R=S+W,要分析和理解响应时间R,就需要分清楚服务时间S和等待时间W。这篇文章想说清楚的就是在Oracle中所定义的等待事件(wait event)等待所消耗的时间应该算是上述公式中的W还是什么呢?文章Cary指出等待事件应该属于系统调用(syscall),应该属于下一个层次的R,原因有两点:

  • Oracle的等待事件实际是对一个操作系统的系统调用(syscall)的instrumentation,任何的一个等待事件基本都有一个与之对应一个(多个)的系统函数。
  • 等待事件中的等待是在等待系统调用的完成,这时候可以说任务已经是正在处理中。说到“等待”这个词,实际在我们的应用中分为两种:
    1. 用用户所花费在等待一个任务完成的时间所定义的等待,这种等待实际上是R=W+S中的R,回顾下R的定义就知道了。 【Response time is simply how long it takes to execute a given code path.】
    2. 用用户任务花费在等待服务的等待队列中所花费的时间定义的等待,这种等待才是R=W+S中的W。
      因此,对应于Oracle环境,可以这么定义“等待事件”中的“等待”:

等待:名词,在Oracle中,指的是一个由Oracle内核进程进行完成一个系统调用的响应时间。

要明白一个任务的R怎么构成的,最需要搞清楚的就是这个任务中的代码的执行路径,如果仅仅通过V$VIEWS去看的话,只能看到一个整体汇总的结果,而看不到代码执行的细节,只有通过了解代码的执行路径,才能准确的做到“区分dbcall中的syscall和dbcall之间的syscall (the distinction between syscalls that occur within dbcalls and the syscalls that occur between dbcalls)。”

文中的评论也给出了个很有用的讨论:每当控制权从系统的一个层面转到更底层(Oracle到OS,OS到设备)时,都相当于开始了一次新的响应时间R(Every time control passes from one tier to a deeper one (Oracle to OS, OS to device), there’s a new R being instantiated)。也就是说Oracle中的W实际上就是OS的R,OS中的W实际上就是硬件层的R,换成等式就是R(oracle)=W(oracle)+S(oracle)=R(os)+S(oracle)=W(os)+S(os)+S(oracle)=…还可以继续展开下去。



本文采用知识共享署名-非商业性使用-相同方式共享 3.0 Unported许可协议发布,转载请保留此信息
作者:马齿苋 | 链接:http://www.dbabeta.com/2010/readings-on-method-r.html
  1. 2011年5月23日19:57 | #1

    总结的很好..:-)

    很少看到有人在这么深入的阅读Cary Millsap的文章与博客.

  1. 本文目前尚无任何 trackbacks 和 pingbacks.

注意: 评论者允许使用'@user空格'的方式将自己的评论通知另外评论者。例如, ABC是本文的评论者之一,则使用'@ABC '(不包括单引号)将会自动将您的评论发送给ABC。使用'@all ',将会将评论发送给之前所有其它评论者。请务必注意user必须和评论者名相匹配(大小写一致)。

无觅相关文章插件,快速提升流量