ODA数据库一体机两层性能测试报告

ODA两层性能测试报告

测试时间：2012.1.10--2012.1.11

测试参与人员：吴伟献、冯艳华、张慧英、林滕洪、胡爱军

目录

一、配置说明 (3)

1、网络拓扑图 (3)

2、服务器配置 (3)

二、场景设计 (3)

1、脚本描述 (3)

2、场景描述及报告选用场景的运行时间 (4)

3、测试代理负载分布 (4)

二、事务响应时间 (5)

1、响应时间和每秒事务量 (5)

2、分析 (5)

三、服务器资源消耗情况 (5)

1、指标说明： (5)

2、服务器资源指标统计 (6)

四、分析 (6)

1、从服务器资源： (6)

2、从oracle指标方面 (7)

五、存在的风险 (7)

1、关于Linux指标数值 (7)

2、关于并发量 (8)

一、配置说明

1、网络拓扑图

2、服务器配置

负载端为普通PC机

服务器77.27和77.26的配置一致，具体如下：

系统Linux oak22.6.18-194.32.1.0.1.el5

内存98G

CPU24Intel(R)Xeon(R)CPU X5675@3.07GHz

数据库Oracle Database11g Enterprise Edition Release11.2.0.2.0-64bit Production(RAC)

二、场景设计

1、脚本描述

在95医院门诊挂号HIS中先登记一个门诊病人，保存该病人信息后，为其挂当日号。

2、场景描述及报告选用场景的运行时间

3、测试代理负载分布

二、事务响应时间

1、响应时间和每秒事务量

2、分析

从事务通过率和每秒事务总数分析，当并发量大于1500时，每秒事务总数并没有随着并发量的增大而增加。并发量到达1800时，“保存”事务的响应时间增加幅度明显，甚至有个别事务因为超时而失败。说明此时服务器的资源消耗比较大，性能开始走下坡路。

相比优化前的响应时间，有了大幅度的减短。

三、服务器资源消耗情况

1、指标说明：

CPU Utilization：CPU使用率，合理使用范围小于60～70% User mode CPU Utilization：用户模式下的CPU使用率Aveage Load：平均负载

Paging Rate：内存页交换速率

Buffer Cache Hit Ratio：oracle缓存的命中率（应大于90％）共享区缓存命中率：应大于99%

2、服务器资源指标统计

四、测试结果分析

1、从服务器资源方面：

从整体趋势看，77.26与77.27的各指标数值比较接近，除了“Paging Rate”指标，服务器27的数值持续大于服务器26，说明服务器27的内存相比26竞争较激烈外，两者均衡性能有了提高。

当并发量到1200时，两台服务器的Aveage Load都超过了10，也就是说每个CPU的负载超过了5，而此时CPU的平均使用率不高，表示CPU的性能有待加强，可能处理速度不够高。

从并发1200到1800的Aveage Load的数值变化趋势，可以看出两台服务器的CPU负载开始变得吃力。

由于在并发为2000的时候出现Aveage Load暴增的情况，因此补充运行了多次该场景，发现有两次的运行结果Aveage Load超过50，而另外两次则小于10，此处需要深入分析。

在进行2000个用户并发时，场景运行期间，CPU使用率预警次数为7次，其中服务器26在达到最大值96%时，此时27服务器的CPU使用率在89%，也说明负载压力的均衡性较第一次测试有了较好的提高。

2、从oracle指标方面

在场景运行期间以下指标多次预警，存在异常。

Latch waits、

Buffer busy waits、

Parse to execute ratio、

Inefficient use of array fetch、

Redo allocation latch sleep rate

Latch waits：

过高表明对Latch的争用激烈，由于不断的spin导致CPU资源紧张，从而增加系统的响应时间，相信这也是事务响应时间长的一个原因。可采用一定的方法来降低Latch的争用。如：提高_spin_count的值，但是代价是消耗更多的CPU资源；如果是由于语句版本过多，尽量加少使用相同的对象名；优化代码，最好是分析一次，执行多次。

本次测试主要关注ODA资源使用情况分析，因此对Oracle其他指标不进行深入分析。

五、存在的风险

1、关于Linux指标数值

在场景的运行过程中发现当并发用户达到集合点，等待释放时对于ODA（Linux）系统资源使用的监控指标会丢失，虽每次丢失后都及时添加了监控指标，但是重新连接服务器需要时间，而此时，并发用户已经释放。因此，Loadrunnr收集到的指标平均值小于各指标在场景运行期间的实际平均值。（在本次测试中，并发1000及以下时指标未发生丢失，并发量超过1200时指标开始丢失，Linux系统相关指标的增长趋势可作为参考，实际指标要偏高些）。

2、关于并发量

由于单台测试机的负载量在300左右，因此并发量为500及以上的测试任务是由一个负载端和多个代理端完成。由于一台测试机施加500的Vuser与两台测试机各对服务施加250的Vuser压力是不同，前者大于后者。因此服务器实际的负载量要在测试结果上打个折扣。

综上所述，估计ODA支持1100个左右的并发用户，即支持4300左右的在线用户，此时ODA的资源指标基本正常；在第一次的测试中ODA的负载极限是并发1100个用户。

在并发用户小于700时，即2500左右的在线用户，ODA以较优秀的性能表现运行；在第一次测试中并发量小于600时ODA只是以较稳定的性能运行。

对于ODA性能调优方面，可以选择增加服务器的CPU的个数，或者选择相比现在更优性能的CPU，提高出计算和处理速度。