zoukankan      html  css  js  c++  java
  • [原]由clob引发的性能问题所想到的(不是解决方案的方案)

    前文再续,书接上一回,今天回到单位,终于可以在生产机器上进一步观察了,由于烂糟的设计,通过调整索引来提供性能是行不通了(也许是我的火候还不够),于是把最终目的定为减少可怕的 physical read 上,也就是把那堆clob缓存到内存中。

    将clob缓冲的语句是:

    alter table table_name modify lob(lob_column) ( cache | cache reads ) ;
    回滚的语句是:
    alter table table_name modify lob(lob_column) ( nocache ) ;

    把那个烂糟语句所用到的表的 clob 都缓冲进内存里。

    做完之后,使用系统的人没有打电话上来,证明没有对业务系统造成冲击。我们对比一下调整前后的情况:

    调整前:

    [root@rac1-node01 ~]# iostat -k 5 5
    Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
    sda               1.98         0.00        47.52          0         48
    sda1              0.00         0.00         0.00          0          0
    sda2              1.98         0.00        47.52          0         48
    sdb            2727.72     43097.03        50.00      43528         50***
    sdc               0.00         0.00         0.00          0          0
    sdc1              0.00         0.00         0.00          0          0
    sdd               0.00         0.00         0.00          0          0
    sde               0.00         0.00         0.00          0          0
    sde1              0.00         0.00         0.00          0          0
    sdf               0.00         0.00         0.00          0          0
    sdg               0.00         0.00         0.00          0          0
    sdg1              0.00         0.00         0.00          0          0
    sdh               0.00         0.00         0.00          0          0
    sdi               0.00         0.00         0.00          0          0
    sdi1              0.00         0.00         0.00          0          0
    dm-0             11.88         0.00        47.52          0         48
    dm-1              0.00         0.00         0.00          0          0
    dm-2              0.00         0.00         0.00          0          0
    emcpowera         2.97         0.99         0.50          1          0
    emcpowera1        2.97         0.99         0.50          1          0
    emcpowerb         0.00         0.00         0.00          0          0	

    可以看到 sdb 的 tps 和 kB_read/s,都很大,这个还不是峰值呢,有时我能观察到100MB/s的传输率,如果按照我们以前的测试数据来看,最高的传输率能到140MB/s左右,没剩多少I/O能力让这个oracle 折腾的啦

    调整之后:

    Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
    sda               1.98         0.00        51.49          0         52
    sda1              0.00         0.00         0.00          0          0
    sda2              1.98         0.00        51.49          0         52
    sdb             147.52      2273.27         6.93       2296          7***
    sdc               0.00         0.00         0.00          0          0
    sdc1              0.00         0.00         0.00          0          0
    sdd               0.00         0.00         0.00          0          0
    sde               0.00         0.00         0.00          0          0
    sde1              0.00         0.00         0.00          0          0
    sdf               0.00         0.00         0.00          0          0
    sdg               0.00         0.00         0.00          0          0
    sdg1              0.00         0.00         0.00          0          0
    sdh               0.00         0.00         0.00          0          0
    sdi               0.00         0.00         0.00          0          0
    sdi1              0.00         0.00         0.00          0          0
    dm-0             12.87         0.00        51.49          0         52
    dm-1              0.00         0.00         0.00          0          0
    dm-2              0.00         0.00         0.00          0          0
    emcpowera         4.95         1.98         0.99          2          1
    emcpowera1        4.95         1.98         0.99          2          1
    emcpowerb         0.00         0.00         0.00          0          0	

    注意这个基本上就是峰值了,可以看到这次调整大大地减少了 physical read 所产生的负面影响。

    我们再看看AWR的对比报告:

    image

    明显 physical read 降低 71%。而内存方面,Buffer Cache 抢走了Shared Poll 100M左右的内存,约3%的波动。

    image

    再看看等待事件方面的变化:

    image

    CPU Time方面略有所降,估计原因是CPU在等待数据块的过程中,闩自旋的时间变短了所造成的,但是这个效果不太明显,毕竟这次调整没有调整到Top SQL的执行计划。direct path read 大大降低,但是db file sequential read 和 db file scattered read的比率上升了,我估计是由于对这些clob的缓存冲击了db buffer cache所造成的,但总的来说,在IO方面的改善还是成效显著的。

  • 相关阅读:
    Sigma Function (LightOJ
    Least Common Multiple (HDU
    七夕节 (HDU
    Goldbach`s Conjecture(LightOJ
    tarjan图论算法
    数论基础(更新中)
    You Are Given a Decimal String... CodeForces
    【UOJ#22】【UR#1】外星人
    【UOJ#21】【UR#1】缩进优化
    【BZOJ3242】【UOJ#126】【NOI2013】快餐店
  • 原文地址:https://www.cnblogs.com/killkill/p/1638868.html
Copyright © 2011-2022 走看看