注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

程序员小站

J2EE丨Spring | JVM | Scala

 
 
 

日志

 
 

【转载】性能优化概要(1) 调优,阶段方式,优化方法,常规优化会话,定义问题,有效的优化目标,调优活动周期阶段,性能和安全权衡  

2013-01-31 12:30:34|  分类: 架构 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

1性能优化概要

这里介绍的都是概要性的,会提出很多新的知识点 后面会全面细致的展开

那为什么大家一提到性能优化就头疼?

找不到瓶颈、找不到问题,环境等等的问题

因为性能优化,除了你有坚实的基础外,有太多的变数

举了一个例子

银屏上播放的很多电视剧,都是什么婆啊?什么当婆婆遇上妈,什么什么离婚的,这种剧目为什么多?

因为小夫妻过日子不容易啊,我们的性能优化就好比小两口,要想学会优化,必须先打好基础

同样,小夫妻和睦,首要条件是你要知道老婆的爱好,脾气,生活习性,也就是熟知夫妻俩的生活节奏

但这还不足以保持夫妻俩长久的和睦,还有什么因素?

小夫妻和睦,有太多外界环境因素的影响,比如无房,房价涨了

比如夫妻俩缺少激情,有小三了,比如今天身体不适,天气不好,影响情绪,如果来个恶婆婆,恶丈母娘,那这小夫妻的日子要闹翻了天,对吧

同样,数据库性能跟太多因素有关系,除了自身的条件,硬件配置,服务器,内存,CPU,要强大,而且要匹配

很多电视剧中剧情冲突都是无端的怀疑,造成越陷越深,所以,性能优化,预防,诊断,优化都是非常重要的

主要内容

⊙ 调优过程的规则

⊙ 描述调优在不同的项目开发阶段的关联性

⊙ 列出调优的目标

⊙ 列出最常见的性能问题

⊙ 在开发和上线后的调优方法

⊙ 性能和安全的权衡

1.1调优的问题

首先我们会提出几个问题,谁来调优?为什么调优?怎么调优?

⊙ 为什么调优

当过度请求的影响似的资源达到临界点时,造成系统的响应时间迅速下降,这时候用户会越慢越点击请求,越慢越点,越点越慢的一个恶性循环

就好比高速公路汽车数量达到临界点时候,前面堵了一辆车,后面的车会接连堵塞,大家都有急切的心理,所以反而手忙脚乱,效率会急剧下降

⊙ 怎么调优

正如高速公路交警会才用多种方法提前来避免交通堵塞,

如在高峰期前提前预告司机绕路行驶、可以减少行车数量、尽量乘坐地铁或者公交车、也可以把高速公路马路拓宽、也可以把马路上坑坑洼洼的路面进行修补等

同样在ORACLE中我们可以采用修改执行路径、修改SQL以减少IO、增加硬件资源(CPU,MEMORY,DISK)、碎片整理等。这里涉及到实例级调优、OS及硬件调优、SQL调优。

无论用户是进行系统设计,还是进行系统维护,当需要进行优化的时候,都应当设定特定的性能目标。

如果没有特定的性能目标,而只是变更初始化参数和SQL语句,那么将浪费大量的时间。

这就里讲的是实实在在的效果 ,让内行人明白,让外行人清楚

作为调优的新手,总想着什么东西也想试着调一下

一是想练手,二是想尽善尽美

这是就犯了大忌

⊙ 谁来调优

与Oracle 数据库软件有关的所有人员(包括系统结构设计师、设计者、开发人员、数据库管理员和系统管理员)均应考虑性能问题。

如果问题出现,通常首先由数据库管理员(DBA) 尝试解决问题。因此,DBA 应准确地了解数据库中所有应用程序的概况及其相互间的影响。DBA 经常会借助于开发人员来优化应用程序,或借助于系统管理员来优化OS 和I/O 问题

当然,在好多公司里,DBA的工作很杂 各种角色都有承担

当在系统优化过程中,系统所涉及的每个人都扮演着一定的角色。

这里包括

◎ 应用和管理决策人员

◎ 应用设计人员:

应用设计人员必须饶过潜在的系统瓶颈进行设计,此外,他们还应当与系统设计人员和DBA进行交流,从而使得每个人都可以理解应用的数据流。

有些地方,开发很牛 ,有些地方DBA也很横

但不管怎样,能够配合起来做事最好了,这是公司希望的结果

◎ 数据库管理员(DBA)

数据库管理员必须规划、预防、监控系统的活动,并将监控信息进行归档,以此来识别性能正常时与性能异常时信息指标的差别,以判断性能问题的源头。

平时DBA的工作好象很轻松 ,但到关键时候,这些人的眼睛都盯着这群人,这种压力,是非常大的

如在数据库出现异常时,采用每10分钟做一次statspack或AWR,在数据库正常时采用每10分钟做一次statspack或AWR,对它们的报表进行对比得出性能问题的源头

statspack或AWR,要会用,并且用熟

◎ 系统管理员(SA)

系统管理员必须对系统的配置进行归档、跟踪负载、优化内核参数、查找操作系统响应的bug或patch。另外还涉及到存储性能,需要配置好合理的IO的性能

所有优化工具都与实例收集的动态性能视图、统计信息和度量所用的基本工具相关

⊙ 调优内容

从另外一个角度来说,系统是为oracle准备的

为了使系统得到良好的优化,必须认真设计系统和应用程序。常见的性能问题可作如下分组:

应用程序问题:编写得不好的SQL、序列化资源以及很差的会话管理

1) 实例问题:内存、I/O 和实例配置

2)操作系统问题:交换、I/O、参数设置和网络问题

通过优化应用程序,可使您付出的时间和努力获得最大的回报。优化SQL 语句、访问路径和存储结构都是优化应用程序的重要部分。

1.2调优的阶段

调优分成多个阶段,我们按照投资回报减少的顺序给出优化过的步骤,对性能影响越大,后期调优成本越高,其位置通常越靠前。

看这个图

成本和优化阶段图

我们看到优化阶段越是早,成本越低

我们看越晚优化,成本越高,如果在设计的时候就优化了,那成本很低,但是很多人都希望看到问题了才去优化,那就晚了。

首先,找老婆,要门当户对,如果对方是物质类型的,你得先准备好房子再去结婚,否则就别去结婚,等矛盾在以后发酵,那就不可收拾

所以,做父母的挑女婿,一定先问:有房么,有钱么,有票子么

他们是过来人,得把好这个关口

所以, DBA,也要在设计上把好关 做安检员

但实际情况是: DBA做的是消防员的工作

我看我们都喜欢做消防员,很多学生头疼医头,脚疼医脚,我们再来看优化的早晚对效益的影响

再看这个图

这是效果和收益图

跟刚才那张图的走向刚好相反

也就是说,越早调优越好

当用户抱怨系统慢的时候,再去优化是不明智的,因为当响应时间比较慢时,再通过一些最有效的优化策略来解决,就已经太迟了

比如你已经写好的坏的程序框价,坏的代码往往都是抄袭的,一旦这个时候要改动,就是要伤筋动骨了

出现这种情况的时候,如果用户还不愿意彻底重新设计应用程序,那么就只有通过重新分配内存或者优化IO来或多或少地提高性能了

1.3优化方法

Oracle 根据多年的经验开发了一种优化方法。此方法与所用的工具无关。ADDM 工具自动采用此方法。基本步骤如下:

1)在优化实例之前检查OS 统计信息以及一般的计算机运行状况,以确保问题出现在数据库实例中。

2) 自上而下进行优化。从优化设计开始,然后优化应用程序,再优化实例。

例如,在优化磁盘上的表空间布局之前,请尽量避免造成I/O 争用的全表扫描

设计应使用适合应用程序和负载特征的数据结构。

例如,逆序关键字索引可能适用于RAC 环境,以减少因为顺序主关键字产生的热块;但是如果每个实例插入同一个表中,也可能会造成通过互连传输大量块

当然也包括序列缓存

应用程序应避免需要通过单一资源进行序列化的进程

例如,多个进程使用的单个支票编号生成器。在实例级别进行优化时,通常受所选的设计和应用程序的限制

这是要做到自上而下进行优化

3) 对可以带来最大潜在好处的方面进行优化

这里介绍的优化方法非常简单。确定最大的瓶颈,然后对其进行优化。重复进行

所有各种优化工具均可以通过某种方式来确定SQL 语句、资源争用或占用时间最多的服务

4)达到目标时停止优化。如果要执行此步骤,则表示您已设置了优化目标。

下面的解释是根据那图里的东西来的

从实际的角度,在项目的设计和开发阶段更倾向于自上而下进行优化

在测试和生产阶段的优化工作通常是被动式优化,从下至上进行优化

在所有阶段中,优化均取决于实际的测试案例,因为理论上的优化并不了解可能存在的所有变量

怀疑或发现出现问题的方面之后,即可创建一个测试案例,并按提供的所有示例优化这个方面。对可以带来最大潜在好处的方面进行优化:缩短最长等待时间,减少最大服务次数。

1.3.1常规优化会话

进行优化时,应将重点放在可为优化工作带来最大回报的特定方面

步骤是通用的,适用于所有性能监视工具。自动数据库诊断监视程序(ADDM) 可自动执行优化方法中的许多步骤。

通常,经验丰富的DBA 可以在用户尚未注意到问题之前就已经解决了问题。

例如,公司知道访问数据库的用户数将要增加。此时,DBA 就可以开始规划必须进行的修改,以避免因为资源有限而造成整个系统的速度变慢

此类主动式优化要求DBA 熟悉数据库、用户群和应用程序的所有方面。

建议的优化方法如下:

1. 定义问题并确定目标。

此步骤是分析步骤。无论信息来源是用户、数据库统计信息还是度量,均将收集与问题对应的准确真实的数据

使用量化的并与数据库操作直接相关的术语来表述问题。例如,如果"XYZ"报表的运行时间是基线的两倍,则优化目标为:使"XYZ"报表的运行时间等于或小于基线

也就是目标要明确

2. 收集当前统计信息:检查主机系统和数据库的统计信息

收集操作系统和数据库的完整统计信息,并将其与基线统计信息进行比较。基线统计信息是实例的运行处在一种可接受状态时所获取的一组统计信息

检查不同之处,以确定系统中发生了哪些更改。"XYZ"报表是否发生了更改?数据是否发生了更改?生成报表的会话是否正在等待某个事件?

3. 考虑常见的性能错误:通过所收集的统计信息中的差异列表,与常见的性能错误进行比较。确定您的系统中是否出现其中某种错误。

4. 制定试用解决方案。在解决方案中包含概念模型。

此模型的目的是通过展示数据库的总体状态来提供帮助。您将寻求下列问题的答案:

- 性能为什么会下降?

- 如何才能解决问题以达到目标?

5. 实施和度量更改:制定了试用解决方案之后,进行适当的更改。

一次只能执行一项更改。如果同时进行多项更改,就无法知道哪项更改有效

如果更改未能解决问题,则无法知道是不是某些更改其了作用,而其他更改反而起了负作用。收集统计信息以度量更改。

猜想,然后验证

6. "该解决方案是否达到目标?"将当前统计信息集与基线统计信息集进行比较。

如果确定需要进行更多的优化,则返回步骤3 并重复执行相关过程。

如果解决方案达到目标,则将当前的统计信息集设为新的基线统计信息集。达到了目标。停止优化。

1.3.2定位问题

如何定位问题

问题随时可能出现。积极的DBA 会监视问题,并在用户注意到问题之前将其解决

过去发现问题和定义步骤很拖沓,有时会依赖于收听用户的反馈。用户反馈非常重要,但却经常是主观的,并且无法重现

在Oracle Database 10g 中,下列许多信息源都可以在Enterprise Manager 界面中查看到。

在10g,习惯用到em

1)检查日志中的错误消息,这些错误消息可能会为发现问题的性质提供快速的线索。

不要忽略特定于系统和应用程序的日志。

2)确保初始化参数设置对系统有意义。建议一天中的不同时段采用不同的设置(如果这样做有帮助的话)。

如白天业务,晚上跑批量

3) 检查CPU 队列和磁盘队列、磁盘利用率以及内存交换情况。这些都会有系统超负荷的迹象。如果应用程序优化得相当好,那么,最好的建议也许只能是增加硬件了。

4) 使用可用的工具(如Statspack 或ADDM),确定应用程序中占用资源最多的SQL语句。

5) 收集实例和OS 的统计信息。Statspack 报表指向等待时间最长并且占用资源最多的组件。ADDM 则进一步将重点放在可带来最大潜在好处的组件上。

问题找出来了,可能会很多

这时候,我们就要设置问题的优先级

也就是确定要首先优化的问题。

在性能报表中,可以看到许多统计信息,甚至优化得很好的数据库也会显示一组顶级等待事件

Oracle 服务器为空闲或正在等待的进程提供一组等待事件统计信息。

Oracle 服务器还会记录正在运行的进程的CPU 利用率。为了确定特定事件的影响,必须将其与所用的总时间进行比较

对数据库服务器发出的每个请求的响应时间包括等待时间和服务时间。服务时间是实际处理请求所用的时间(CPU 时间)

按照定义,等待时间是由于各种原因而等待的时间。服务时间和等待时间均可优化。

若要优化服务时间,必须更改处理、SQL、访问路径或数据存储结构。在等待即要发生的地方减少资源争用可以优化等待时间。

每个服务器进程通常处于下列三种状态之一:

1) 空闲:等待执行(休眠)

2)正在运行代码:正在使用CPU 或在运行队列中

3)等待(被阻塞):

- 等待某个资源可用

- 等待所请求的活动完成

这是statspack报告的一部分

报表显示了数据库CPU 时间为414.2 秒。用户调用所花费时间占总数据库时间的68.4%。sql execute elapsed time 显示为467 秒,此时间包含等待时间

仅从这个有限的视图来看,SQL 执行的等待时间比例就很大,因此可能会引导您检查与SQL 执行有关的等待统计信息

进一步的调查表明,等待是应用程序设计中固有的,无法更改。然后对parse time elapsed 重复该过程。

% of DB time 的值指示对此方面进行优化可能会产生的相关影响。如果可以消除hard parse elapsed time,则最多可能提高109 秒或18%。实际的提高可能会小得多,这取决于可从该方面获得的提高量。

这里提到的几个概念,后面会介绍到

1.3.3 有效的优化目标

消除确定的问题成为优化目标。相关的服务级别协议(SLA) 也会派生出目标

SLA 通常是必须达到的合同要求或业务要求。目标可能以SLA 或问题为出发点

SLA 表明,用户响应特定请求的时间不得超过30 秒。问题在于,平均响应时间为25 秒,并且还在增加

优化目标是用户响应特定请求的时间为20 秒

优化目标和SLA 均须具有三个特征才能生效。它们必须:

具体、可量化 、可实现

比如"使实例运行速度尽可能快"不够具体。具体的目标应是"月末报表套件完成时间必须少于4 个小时"。

可量化的目标具有可以度量的客观数量。如果目标是可量化的,那么目标是否达到就很清楚了。具体的目标也很容易成为可量化目标。

很容易陈述"用户响应请求的时间为10 秒"目标,但此目标是否针对所有用户请求?是否为平均响应时间?如何度量平均响应时间?

对目标中的用词进行具体的定义是十分必要的。如果将目标表述改为"用户响应特定请求的时间为20 秒或更短",可以客观地确定何时达到了目标

可实现的目标是可能的,并且在优化负责人的控制范围内。

下列示例是在典型DBA 控制范围内无法实现的目标:

1) 如果目标是优化实例以创建高性能的应用程序,但是不允许您更改SQL 或数据结构,那么可实现的优化量就会受到限制。

2)如果目标响应时间为1 秒,但是服务器与客户机之间的网络延迟为2 秒,如果不对网络进行更改,就不可能实现1 秒的响应时间。

即使上述情况并非绝对无法更改,但是DBA 总是会有业务约束,对解决方案可使用的资金和资源量进行限制。

始终应制定可量化的优化目标。没有优化目标,将很难确定是否有了足够的优化。

就好比一个舞蹈演员,舞蹈需要不断的进步,舞蹈也会越跳越好

但是好了还又更好,如果你没有一个明确的目标,你将会在无至尽的追求更完美,而越到后面花费的代价越巨大

也许也就提高了一点点,这显然性价比不高

所以我们需要对每项指标在每个阶段制定一个目标范围,在这个目标范围内属于正常范围。

。就好比正常血压范围是130<--->85 ,在ORACLE中DBA也需要指定这么一个调优目标,常见的调优目标有:

优化目标可以归纳为"以更短的时间完成更多的工作"。根据所处的环境,可作如下解释:

1)尽可能缩短响应时间或缩短用户等待时间

2)增大吞吐量,即缩短执行一个或一组作业的时间

提高负载能力,即可以执行更多的任务,或为其他任务释放处理能力

在某些环境中,需要进行折衷。在大批量联机事务处理(OLTP) 环境中,可以允许更长的用户响应时间,以便从多个用户获取更多的总事务数

再比如,在基于Web 的环境中,用户响应时间必须小于7 秒,否则,用户就会放弃使用。在这种情况下,任何其他条件都将服从于响应时间

业务需求会影响优化目标。性能可能会受到安全问题的限制,比如在"缩短恢复时间"目标。

如果业务环境中每分钟的停机可能需要付出数百或数千美元的代价,则防止实例失败和缩短恢复时间的开销比用户响应时间更加重要。

1.3.4 调优活动周期阶段

活动周期期间的优化步骤

开发新系统期间采用的优化方法与生产系统采用的方法相同。对于一个新系统,可能存在许多未知的因素;因此,应认真执行以上的步骤顺序

修复设计是解决问题的最佳方式。

如果应用程序使用了多个全表扫描,则可能会因为I/O 过量而减慢速度。但是,如果可以重写查询,使其只访问四个块而不是4,000 个块,则不需要考虑调整缓冲区高速缓存大小或重新分配磁盘文件。

应用程序的设计和开发

在设计和开发阶段采用的优化方法以各种系统的常见瓶颈为重点:规范化、数据结构、序列化点、主要报表和大批量请求

刚开始设计的时候,就已确定应用程序的主要功能。数据的规范化级别对性能有重大影响。过度规范化可能会产生大量多路联接,从而会占用所有可用的主机资源。

规范化不足则会带来另一组问题:不一致的数据、复杂的数据检查以及难以将数据迁移到其他方案或数据库。该解决方案需要采用完全规范化的设计,并使用内置的一致性检查进行谨慎的逆规范化。

选择正确的数据结构对性能有很大好处,例如对大型数据集使用分区表。在设计中避免资源争用,可以提高应用程序的可伸缩性。

测试:数据库配置

测试案例应运行应用程序功能、预期的负载以及对不大可能的负载的压力测试。通过这些类型的测试,可以在最佳物理布局以及最佳OS 和硬件配置方面获得有价值的信息。

监视热点(即使在快速磁盘上),这一点很重要。应规划数据配置,使其可以缩短恢复时间和加快数据访问速度。尽量考虑业务对恢复时间和可用性的要求,以便留出这些要求所需的开销。

通过可以耗尽计算机资源的负载进行测试。这些测试可确定占用最多的资源。这些资源就是限制系统的可伸缩性的资源。

DBA 在每个阶段使用时间模型来确定瓶颈,并使用优化会话来消除每个层次的瓶颈。

部署

初次部署新的应用程序时,预期的性能与实际情况通常会有所不同。这里要考虑两种差异:

第一种是对于新数据库上的新应用程序,第二种是对于添加到现有数据库中的应用程序。新数据库上的新应用程序没有基线,因此要根据当前性能进行优化

定期获取性能基线报表。随着应用程序在数据集规模或用户数方面的增长,可将增加的性能报表与基线进行比较。这样一来,就可以在性能下降到无法接受的水平之前进行优化。

将新应用程序添加到现有数据库中时,可以在部署应用程序之前的基线性能报表与部署应用程序之后的基线性能报表之间进行比较。这些报表可以显示新应用程序正在使用的资源,以及可能与现有应用程序发生的资源争用。

生产

对应用程序活动周期中的其他阶段的优化通常是主动式优化。您所做的是在用户注意到问题之前发现可能出现的问题。

对生产数据库的优化通常是被动式优化

出现了一些问题:以前需要数分钟即可运行完的报表,现在需要数小时,响应时间延长,用户不断抱怨未在分配的时间内完成备份。

某些事情发生了改变。是否存在其他用户?是否正在运行新的报表或应用程序?OS 中是否发生某些改变?

若要优化以前在可接受状态下运行而现在出现问题的生产系统,需要了解或推断发生了哪些改变。将数据库在可以接受的状态下运行时获取的基线统计信息报表,与发现问题时获取的新报表进行比较。差异之处应当可以显示。

在没有基线统计信息时优化生产数据库会比较困难,但是仍可实现。所用的方法相同,并对确定了优先级的组件进行优化。使用时间模型确定问题。按从上至下的步骤,从设计开始考虑可能的解决方案。使用优化会话测试解决方案。

收集基线统计信息集

每个生产数据库至少应存储一个基线统计信息集,以便在数据库性能下降时参考。使用此统计信息集可以确定是性能确实下降,还是用户判断情况已改变。

如果性能确实下降,则可以确定数据库的哪个方面已改变,并针对这个方面进行优化。可以创建问题原因以及如何解决问题的前提。

创建了前提之后,针对系统进行测试,并收集新的统计信息集。将新的统计信息集与基线统计信息集进行对比,确定是否得到了改进。

如果新的统计信息集实现了为系统制定的性能目标,则使用该统计信息集作为新的基线统计信息集。应保留以前的基线统计信息集,以便可以对系统的长期变化进行观察

收集统计信息和创建基线统计信息集的方式取决于所使用的工具。除了收集统计信息之外,自动数据库诊断监视程序(ADDM) 还分析不同之处并推荐解决方案。

这些完全是一些理论性的东西 但是,理论性的东西也很重要的

我们如何来度量性能指标呢?

在我们前面的调优目标中有介绍

⊙ 提高响应时间,设置响应时间各项指标及比率

⊙ 提高数据库的可用性

这个可以通过备份恢复,高可用性组件来实现。

⊙ 提供数据库的命中率,包括各内存组件的命令率。

⊙ 提高内存使用率。

⊙ 尽量少的等待时间。

1.3.5 性能和安全权衡

性能和安全的权衡,往往只考虑性能就会确实安全保护,它们是一对矛盾体

比如:

为了增加安全就会增加IO,增加了响应时间,降低了性能

控制文件和在线日志文件

为了安全,必须将它们镜像到不同的硬盘里

但这样,增加了IO

再比如,我们设置频繁的检查点,这样可以减少数据库崩溃后数据丢失量的风险,也可以加快崩溃恢复的速 度,但是会增加IO的频率,影响系统性能

再比如,我们设置归档模式,备份数据文件,可以保证数据库能通过足够早的备份中还原和恢复,避免数据库介质损坏的风险

但同样增加了IO,影响到在线数据库的性能

我们考虑的物化视图

物化视图,是以空间换时间的一种变通

并发数和事务数,会提高系统的利用率,但是会增加系统的负载。

虽然很理论, 但是很重要.!

  评论这张
 
阅读(1508)| 评论(3)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017