科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网软件频道在oracle中如何有效应用时间的有限和无限

在oracle中如何有效应用时间的有限和无限

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

  Oracle的性能分析在过去的20年里已经走了很长的一段路。这里首先提出“仅仅添加更多的资源”的方式,然后涉及比率分析,最后是等待事件分析的出现。但是那些方式都不完整或者足够广泛。

作者:中国IT实验室 来源:中国IT实验室 2007年10月7日

关键字: 应用 数据库 ORACLE

  • 评论
  • 分享微博
  • 分享邮件

  Oracle的性能分析在过去的20年里已经走了很长的一段路。这里首先提出“仅仅添加更多的资源”的方式,然后涉及比率分析,最后是等待事件分析的出现。但是那些方式都不完整或者足够广泛,所以在2001年我发表了一篇名为《Oracle响应时间分析(RTA)》的论文。RTA的文章同时提出并且详细描述了响应时间中的两个元素:服务时间和排队时间。有关RTA的一个更加微妙的方面就是理解服务时间和排队时间之间的关系,以及它们与操作系统之间是如何联系的。

  用户感觉到的响应时间是许多个相关系统的结果。Oracle服务器只是这些系统中的一个。花费在每个系统上的时间都可以划分为服务时间和排队时间。我们只能把所有的服务时间和所有的排队时间加起来,来判断最终用户的响应时间。但是在现实生活中,有时候这些努力相对于结果来说并不值得……不是说完成起来极端困难。但是肯定值得我们去做的最小的努力就是从Oracle的角度获取服务时间和排队时间。此外,我们还可以获得有关它如何与数据库服务器的CPU子系统相联系的细节。

  让我们看看基本的基于Oracle的响应时间公式:

  Rt = 终端用户响应时间 = Ts + Tw

  Ts = 服务时间 = CPU 时间= Oracle 内核代码执行时间

  Tw = 排队时间 = ORAt + TIERt

  ORAt = Oracle等待时间 (包括从服务器进程到Oracle客户端进程的时间,以及Oracle客户端进程的时间)

  TIERt = 从Oracle客户端进程到终端用户的时间。其中包括网络服务器、网络时间、浏览器时间等。

  从分析响应时间中我们可以穴道很多东西,其中一件就是服务时间有限,但是等待时间却无限。每个CPU子系统都有一个最大的固定的可以提供的CPU能力。如果你的机器是一个CPU的,这个机器就可以提供每分钟60个CPU秒的最大量。如果你的机器中有10个CPU,它就可以提供每分钟600个CPU秒。这个环境对排队时间来说绝对是不同的。

  排队时间是不固定的,并且只被工作负载所限制。如果工作负荷相对比较小,排队时间就可能接近于0.但是当工作负载不断增加,排队时间就会达到无限――它没有限制。

  有关排队时间无限的说法提出了两个我们需要思考的概念。首先,如果Oracle消耗了所有可用的CPU,那么要求更多的CPU就需要增加服务时间,同时也有可能增加Oracle等待时间。结果就是响应时间的增加。这是不好的,非常不好。这意味着我们的解决方案需要仔细权衡它们是如何影响CPU子系统的。(这个概念在我的新论文《Oracle等待接口详解》中有详细的解释。)第二个概念就是我们现在有另一种方式来查看一个非常动态的系统。这不仅可以帮助我们理解系统,还可以让我们帮助其他人来理解潜在的非常复杂的基于Oracle的系统。

  例如,考虑下面的图。数据是从实际生活中的Oracle系统上收集到的。每个小时、响应时间组件都会被收集并且总结。排队时间从v$system_event中收集,服务时间是从v$sysstat中收集。通过查看这幅图,如果性能是糟糕的,所有的非Oracle服务器体系组件都表明不是瓶颈,瓶颈就应该是在Oracle服务器中了。通过以下的图,我们可以推断,IO子系统有很严重的瓶颈,或者锁定/阻塞问题。也许2200左右就是CPU的瓶颈,但是剩余的时间肯定是IO瓶颈或者锁定/阻塞问题。

  让我们更仔细地看一下。问题都集中在可用的Oracle消耗的操作系统的CPU能力百分比。仔细查看上述的图形。我们从CPU子系统开始。因为在一个小时里面大概消耗了大约1000分钟的最大CPU时间,我们知道那肯定至少有17个CPU.最糟糕的情况就是使用的CPU资源相当于可用的CPU资源。这一点可以结合从上述图形中的数字得到:

  可用的CPU = 使用的CPU

  X CPUs * 60 分钟/小时 = 1000分钟/小时

  X CPUs = 1000分钟/小时 / 60分钟/小时

  X CPUs = 16.67

  所以,数据库服务器上至少有17个CPU.如果我们从对操作系统的监控中发现,CPU的利用率在50%左右,大概是2200,我们还可以推断出大概有34个CPU(16.67 X 2)。

  现在让我们把信息放在一起,这样它们就有用了。请注意在午餐时间附近,Oracle每小时消耗的CPU时间达到1000分钟。我们知道服务器可以每小时提供1000个CPU分钟,在午餐时间,它提供的时间少于每小时500个CPU分钟,用户并不满意这样的性能。因此,我们可以推断出排队时间(例如,Oracle等待事件)并不是CPU相关的, 而是与I/O有关的,或者是相关锁定/阻塞(例如排队等待)。有力的信息!

  我们知道理解和应用Oracle响应时间组件可以增加我们的性能威力。但是理解了Oracle服务时间是如何与CPU的操作系统相关联的,就是另一个级别的了。在没有理解Oracle从操作系统中消耗的可用的CPU的百分比的时候,我们就无法了解是否有足够的CPU可用。对CPU百分比的了解可以让我们的性能诊断更加准确,可以得出更加有力的解决方案。理解了时间的有限和无限,不仅仅可以帮助你,还有你的同事,以及你需要影响的人们。他们越好的理解这个情况,他们就越同意你的行动建议。换句话说,它使得你的性能分析更加有力,构建了信任。这也是所有的数据库管理员们都用得最多的。

查看本文来源

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章