oracle并发量导致性能下降,【案例分享】并发大时性能下降严重

1.问题描述：

收到客户的邮件，原来客户在进行X86和小机的性能对比测试时出现以下问题：一个高端pc server，内存32G，cpu是32核

pc  server上测试8个语句并行，小机下降不明显，但在此pc server上却下降明显。

执行时间由1分多，降到7分钟。小机上始终是2分钟。

附件是AWR报告，请分析原因。

2.分析过程：Per Second  Per Transaction  Per Exec  Per Call

DB  Time(s):  6.3  233.0  3.93  16.49

DB  CPU(s):  0.6  23.0  0.39  1.62

Redo  size:  2,475.8  91,824.5

Logical  reads:  30,695.3  1,138,476.7

Block  changes:  5.4  201.9

Physical  reads:  30,680.6  1,137,931.2

8个并行测试的情况下，逻辑读=物理读，

逻辑读表示操作内存中的BLOCK的个数，通过物理读(IO)读进内存后必然发生逻辑读。

这说明ORACLE根本没能把数据缓存到共享内存buffer cache，以便供其他进程复用。

从AWR报告中的等待事件可以看到，排在第一位的是direct path read,这是一个IO事件

即上面说的，绕开BUFFERCACHE，直接读到PGA私有内存(非共享内存)中时,单次IO的时间达到了42毫秒，太大，说明磁盘IO竞争严重，性能不佳。

但这个是原因还是结果呢？我们不妨往下看。Event  Waits  Time(s)  Avg wait (ms)  % DB time  Wait Class

direct  path read  75,500  3,155  42  90.25  User I/O

DB CPU    344    9.85

Disk  file operations I/O  45  1  21  0.03  User I/O

control  file sequential read  153  0  0  0.00  System  I/O

log file  sync  7  0  4  0.00  Commit

如下图所示，不再是由一个进程将数据读取到buffer cache,其他人直接复用内存中的数据，从而降低了对IO的请求次数，降低了磁盘的繁忙程度。

而是每个进程各自读取到自己的私有内存PGA中，每个进程执行同一条SQL都需要各自读取各自的，显然大量进程同时反复读取同一片数据，势必造成磁盘的繁忙和IO的性能下降。这就是从AWR报告中得到的分析结论。如下图所示。

那么为什么不是一个人读取到共享内存，其他人坐享其成就好了呢？

这是11G的新特性引起的。11g下当优化器判断需要较多物理IO的时候，那么就绕开BUFFER CACHE，直接读到PGA私有内存中。

这个特性的初衷是：当ORACLE默认一次读16个BLOCK时，由于所需的部分BLOCK已经在buffercache里了，不连续了，因此这16个BLOCK，很可能需要拆分为多次IO，导致原来的一次多块读变为了多次单块读。

但现实中，当并行个数多的时候，由于该特性，这个时候很容易把磁盘搞得很忙，IO性能下降严重，也就出现了执行时间从1分钟升至7分钟的情况。

而原来10G下的机制是：

一个会话读到内存中，其他会话坐享其成，直接读内存中的数据就可以，因此读磁盘的个数会小一些。

3.问题得到解决：

使用下列方法临时禁止该特性后，再次测试，问题得到解决。alter system set event= '10949 trace name  context forever, level 1' scope=spfile;

--重启数据库

Shutdown   immediate

startup

alter system register;

因此不难看出，IO慢实际上是结果，而不是原因，原因在于对同一片数据反复读取，出现太多IO了。