简单的案例说明:
某运营商的经营分析系统,ETL完成时间不能让人满意,期望在6:30,最晚7:00完成的ETL作业总是在9:00多才完成,老板意见很大,信息化部门压力很大。注意这是一个DB2数据库,我不懂DB2,这个案例很清晰的说明了优化方法的通用性。DB2的服务供应商给出了优化SQL的解决方案,我简单看了优化的SQL方案,直接就认为优化方案是无效的,不会产生效果。确实,服务商在辛苦了半个月之后毫无收获,我看了他们的系统,非常简单的调整,明确认为应该可以完成2小时的时间节约。措施非常简单,只是把ETL作业进行了均匀调度,使其平稳的分布在从10:00开始的时间范围内,而不是像原来一样空闲几个小时,运行几个小时,然后又空闲一段时间。由于同时派生的进程运行太多,导致CPU和IO都100%忙碌,达到硬件限制。只要我们适当的把资源分布就可以降低在CPU和IO资源的冲突,最大程度的利用资源,从而提高程序响应速度。
最后开发商没有做任何调整,只是简单的调整了运行时间和并发控制,有意识的安排程序错开运行,ETL速度平稳的加快了2个多小时,达成了优化目标。
业务系统的运行依赖于资源供给,Oracle数据库所有的资源来源于OS,OS所有的资源来源于依赖的硬件。CPU,Memory,Network,IO SubSystem。CPU可以说是其中最重要的资源,CPU,中央处理器,在所有部件中唯一一个主动性部件,其他任何部件都依赖于CPU的调度,属于被动响应。可以看到Oracle把CPU运行部分表示为服务时间,其他部分表示为等待时间。
很遗憾,CPU是所有硬件资源中最不具有柔韧性的部件,你几乎无法通过扩容去完成他,你很难因为资源不足去增加CPU数量,或者CPU主频不够去增加主频。作为一个性能优化者,几乎不需要去关注CPU的运行细节,特别在数据库应用中,CPU的能力事实上取决于内存系统,因为绝大部分操作是内存操作而非是运算操作。
CPU做什么事情:
运算
内存操作
页面交换
进程上下文切换
响应中断
网络内存处理
如何衡量一个CPU的性能?
CPU利用率和CPU Queue
CPU利用率100%是否意味着性能不好?
我们很难说CPU 100%是否意味着性能不好,如果这个100%的CPU都花在运算和内存操作上,大多数情况下我们认为这笔投资是最划算的,只是系统不具有扩展性而已。尤其对于批处理而言,我们总是希望100%的利用CPU,任何CPU资源的浪费就是意味着我们的代码写的不够好。
CPU利用率 100%,没有告诉他确实100%的全力运行,还是他已经在过载运行事实上CPU性能已经在下跌。不过个人感觉,CPU作为电子设备,过载运行的可能性不会很高,100%基本表示为其全速运行,如果这个100%的CPU都作用在用户进程上面。
当在一个OLTP系统CPU利用率100%,在绝大部分情况下都意味着问题,除非其已经处于负载最高峰。
在OLTP系统中,比较利用率更加重要的指标:CPU Queue,等待CPU资源的运行队列长度。
回到我们的RT,RT:= DB time:=CPU Time + Wait TIme
:=CPU Time + CPU QUeue TIme + Wait time
Oracle对于CPU Queue TIme并没有明确的记载,我们通过以下方法来计算:CPU Queue Time:=DB TIme - CPU time - Wait time
CPU从本质上是一个串行设备,在某一时刻只能为某个进程服务,其他进程只能等待。这里事实上可以看出,主频越高,等待的时间将会越短。所有等待的运行进程都会处于CPU Running Queue中,等待获得CPU资源。可以看到CPU资源的切换是一个无效率的操作,可能需要把CPU cache中进程数据被交换出去,从而大幅度影响性能。
多少的CPU Queue是合适的?
没有一个绝对的数字,只能说CPu的主频越高,可以接收的数字就越高。在很久以前,10年前吧,那个时候我把1作为运行良好,2就作为运行不好的说法,那时候主频才1G,现在已经4G的主频了,估计可以到4才表示问题了。
事实上,这个数字多少是依赖于业务系统。如果你的数据库应用严重的依赖于磁盘系统,大量的磁盘IO存在,你在CPU Queue中多等几次也没什么大不了,不会在总时间占用多大的空间。但是如果你是全内存操作,甚至是大部分运算操作,这个队列的大小就成为致命因素,因为业务的CPU渴望很高。
再次回到多少个Queue才合适的?
我们的说法,(1)、实际运行中的基线数字,如果你实际运行队列是8,依然运行良好,硬要说4就没有意思了。
(2)、目前我依据CPU能力取2.5~4的范畴。
事实上CPU Queue的大小可以通过CPU Queue Time的计算来完成。
上面的公式:CPU Queue Time:=DB TIme - CPU time - Wait time,计算出来的值再合CPU Time比较。当本身在DB Time之中,Wait Time较小的时候,CPU QUeue TIme就会成为一个影响因素。多少合适,10%或者20%,随意而定了,一般感觉还是5~10%是一个可以接收的范畴。
CPU Queue的根源是从两个方面引起的,(1)、CPU运行不够快 (2)、在某一时刻调度太多的程序
如何降低CPU消耗?
对于数据库应用来说,降低CPU消耗主要从以下几个方面来进行:
(1)、简化业务逻辑
(2)、降低LIO
(3)、降低latch冲突
(4)、减少引擎转换
(5)、进行合理调度
简化业务逻辑: 这个不说了,谁都知道,大量的业务系统中存在很多的无效操作,优化要阅读代码,对于很多优化工作者是个负担。
降低LIO: 更加有效的索引,更加有效的parse,更少的fetch
降低latch冲突:更加有效的parse,更加快的处理速度,更少的冲突
减少引擎转换:任意的引擎转换都消耗大量的CPU,并且效率低下。
降低Bind in and Bind out
避免在SQL语句中使用PLSQL函数
减少PLSQL和SQL的交互
减少SQL和Java等接口语言的交互
减少网络交互
进行合理调度:不要在某一时刻调度大量程序,而是顺序启动或者进行小批量分布。比如要启动10个进程处理,不要在某一时刻同时启动,可以每秒钟启动一个,在10秒之内启动10个程序。
对于操作系统而言:
(1)、减少不必要的页面交换
页面交换大幅度降低CPU的处理能力,数据库类应用的最终能力依赖于内存,当内存缺少的时候,CPU处理能力自然就大幅度下跌。
(2)、减少进程上下文切换
过多的进程将很大程度上降低CPU效率,CPU从本质上某一时刻只能为一个进程服务。任何进程的上下文切换都是无效工作。
(3)、减少网络处理和中断
网络处理消耗CPU资源,要尽可能的使CPU在一个时钟周期内充分工作,而不是无所事事,也就是说需要让他处理更多的工作。
CPU资源的监控:
Oracle: DB CPU Time
DB CPU Queue Time
OS CPU ratio
CPU Queue:= Active Session for ON CPU
OS:
sar -u
sar -q
vmstat
mpstat
uptime
主要指标为:
CPU Usage ratio:= User CPU+ SYS CPU
CPU Queue
辅助指标:
context swicth
page swap
intr number
CPU Usage的曲线:是平稳波动的曲线还是锯齿形曲线,锯齿形曲线往往意味着调度不当。
某运营商的经营分析系统,ETL完成时间不能让人满意,期望在6:30,最晚7:00完成的ETL作业总是在9:00多才完成,老板意见很大,信息化部门压力很大。注意这是一个DB2数据库,我不懂DB2,这个案例很清晰的说明了优化方法的通用性。DB2的服务供应商给出了优化SQL的解决方案,我简单看了优化的SQL方案,直接就认为优化方案是无效的,不会产生效果。确实,服务商在辛苦了半个月之后毫无收获,我看了他们的系统,非常简单的调整,明确认为应该可以完成2小时的时间节约。措施非常简单,只是把ETL作业进行了均匀调度,使其平稳的分布在从10:00开始的时间范围内,而不是像原来一样空闲几个小时,运行几个小时,然后又空闲一段时间。由于同时派生的进程运行太多,导致CPU和IO都100%忙碌,达到硬件限制。只要我们适当的把资源分布就可以降低在CPU和IO资源的冲突,最大程度的利用资源,从而提高程序响应速度。
最后开发商没有做任何调整,只是简单的调整了运行时间和并发控制,有意识的安排程序错开运行,ETL速度平稳的加快了2个多小时,达成了优化目标。
业务系统的运行依赖于资源供给,Oracle数据库所有的资源来源于OS,OS所有的资源来源于依赖的硬件。CPU,Memory,Network,IO SubSystem。CPU可以说是其中最重要的资源,CPU,中央处理器,在所有部件中唯一一个主动性部件,其他任何部件都依赖于CPU的调度,属于被动响应。可以看到Oracle把CPU运行部分表示为服务时间,其他部分表示为等待时间。
很遗憾,CPU是所有硬件资源中最不具有柔韧性的部件,你几乎无法通过扩容去完成他,你很难因为资源不足去增加CPU数量,或者CPU主频不够去增加主频。作为一个性能优化者,几乎不需要去关注CPU的运行细节,特别在数据库应用中,CPU的能力事实上取决于内存系统,因为绝大部分操作是内存操作而非是运算操作。
CPU做什么事情:
运算
内存操作
页面交换
进程上下文切换
响应中断
网络内存处理
如何衡量一个CPU的性能?
CPU利用率和CPU Queue
CPU利用率100%是否意味着性能不好?
我们很难说CPU 100%是否意味着性能不好,如果这个100%的CPU都花在运算和内存操作上,大多数情况下我们认为这笔投资是最划算的,只是系统不具有扩展性而已。尤其对于批处理而言,我们总是希望100%的利用CPU,任何CPU资源的浪费就是意味着我们的代码写的不够好。
CPU利用率 100%,没有告诉他确实100%的全力运行,还是他已经在过载运行事实上CPU性能已经在下跌。不过个人感觉,CPU作为电子设备,过载运行的可能性不会很高,100%基本表示为其全速运行,如果这个100%的CPU都作用在用户进程上面。
当在一个OLTP系统CPU利用率100%,在绝大部分情况下都意味着问题,除非其已经处于负载最高峰。
在OLTP系统中,比较利用率更加重要的指标:CPU Queue,等待CPU资源的运行队列长度。
回到我们的RT,RT:= DB time:=CPU Time + Wait TIme
:=CPU Time + CPU QUeue TIme + Wait time
Oracle对于CPU Queue TIme并没有明确的记载,我们通过以下方法来计算:CPU Queue Time:=DB TIme - CPU time - Wait time
CPU从本质上是一个串行设备,在某一时刻只能为某个进程服务,其他进程只能等待。这里事实上可以看出,主频越高,等待的时间将会越短。所有等待的运行进程都会处于CPU Running Queue中,等待获得CPU资源。可以看到CPU资源的切换是一个无效率的操作,可能需要把CPU cache中进程数据被交换出去,从而大幅度影响性能。
多少的CPU Queue是合适的?
没有一个绝对的数字,只能说CPu的主频越高,可以接收的数字就越高。在很久以前,10年前吧,那个时候我把1作为运行良好,2就作为运行不好的说法,那时候主频才1G,现在已经4G的主频了,估计可以到4才表示问题了。
事实上,这个数字多少是依赖于业务系统。如果你的数据库应用严重的依赖于磁盘系统,大量的磁盘IO存在,你在CPU Queue中多等几次也没什么大不了,不会在总时间占用多大的空间。但是如果你是全内存操作,甚至是大部分运算操作,这个队列的大小就成为致命因素,因为业务的CPU渴望很高。
再次回到多少个Queue才合适的?
我们的说法,(1)、实际运行中的基线数字,如果你实际运行队列是8,依然运行良好,硬要说4就没有意思了。
(2)、目前我依据CPU能力取2.5~4的范畴。
事实上CPU Queue的大小可以通过CPU Queue Time的计算来完成。
上面的公式:CPU Queue Time:=DB TIme - CPU time - Wait time,计算出来的值再合CPU Time比较。当本身在DB Time之中,Wait Time较小的时候,CPU QUeue TIme就会成为一个影响因素。多少合适,10%或者20%,随意而定了,一般感觉还是5~10%是一个可以接收的范畴。
CPU Queue的根源是从两个方面引起的,(1)、CPU运行不够快 (2)、在某一时刻调度太多的程序
如何降低CPU消耗?
对于数据库应用来说,降低CPU消耗主要从以下几个方面来进行:
(1)、简化业务逻辑
(2)、降低LIO
(3)、降低latch冲突
(4)、减少引擎转换
(5)、进行合理调度
简化业务逻辑: 这个不说了,谁都知道,大量的业务系统中存在很多的无效操作,优化要阅读代码,对于很多优化工作者是个负担。
降低LIO: 更加有效的索引,更加有效的parse,更少的fetch
降低latch冲突:更加有效的parse,更加快的处理速度,更少的冲突
减少引擎转换:任意的引擎转换都消耗大量的CPU,并且效率低下。
降低Bind in and Bind out
避免在SQL语句中使用PLSQL函数
减少PLSQL和SQL的交互
减少SQL和Java等接口语言的交互
减少网络交互
进行合理调度:不要在某一时刻调度大量程序,而是顺序启动或者进行小批量分布。比如要启动10个进程处理,不要在某一时刻同时启动,可以每秒钟启动一个,在10秒之内启动10个程序。
对于操作系统而言:
(1)、减少不必要的页面交换
页面交换大幅度降低CPU的处理能力,数据库类应用的最终能力依赖于内存,当内存缺少的时候,CPU处理能力自然就大幅度下跌。
(2)、减少进程上下文切换
过多的进程将很大程度上降低CPU效率,CPU从本质上某一时刻只能为一个进程服务。任何进程的上下文切换都是无效工作。
(3)、减少网络处理和中断
网络处理消耗CPU资源,要尽可能的使CPU在一个时钟周期内充分工作,而不是无所事事,也就是说需要让他处理更多的工作。
CPU资源的监控:
Oracle: DB CPU Time
DB CPU Queue Time
OS CPU ratio
CPU Queue:= Active Session for ON CPU
OS:
sar -u
sar -q
vmstat
mpstat
uptime
主要指标为:
CPU Usage ratio:= User CPU+ SYS CPU
CPU Queue
辅助指标:
context swicth
page swap
intr number
CPU Usage的曲线:是平稳波动的曲线还是锯齿形曲线,锯齿形曲线往往意味着调度不当。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/92650/viewspace-776149/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/92650/viewspace-776149/