IT博客汇
  • 首页
  • 精华
  • 技术
  • 设计
  • 资讯
  • 扯淡
  • 权利声明
  • 登录 注册

    记一次内存换IO的Oracle优化

    老A的自留地,欢迎加微信交流,微信号zhoul777发表于 2019-09-27 16:50:19
    love 0
    某客户数据库从P595物理迁移至P780新服务器并更换存储之后,发现应用性能反而下降。P780配置了32颗4核CPU(主频为3920 MHz),710G内存。如下所示:
    System Model: IBM,9179-MHC
    Machine Serial Number: 06DA0CR
    Processor Type: PowerPC_POWER7
    Processor Implementation Mode: POWER 7
    Processor Version: PV_7_Compat
    Number Of Processors: 32
    Processor Clock Speed: 3920 MHz
    CPU Type: 64-bit
    Kernel Type: 64-bit
    LPAR Info: 1 SN06DA0CR
    Memory Size: 727040 MB
    Good Memory Size: 727040 MB
    Platform Firmware level: AM740_088
    Firmware Version: IBM,AM740_088
    Console Login: enable
    Auto Restart: true
    Full Core: false
    P595配置了32颗双线程CPU(主频为2302 MHz),186G内存。如下所示:
    System Model: IBM,9119-595
    Machine Serial Number: 83E37E3
    Processor Type: PowerPC_POWER5
    Processor Implementation Mode: POWER 5
    Processor Version: PV_5_3
    Number Of Processors: 32
    Processor Clock Speed: 2302 MHz
    CPU Type: 64-bit
    Kernel Type: 64-bit
    LPAR Info: 1 83-E37E3
    Memory Size: 190976 MB
    Good Memory Size: 190976 MB
    Platform Firmware level: SF240_358
    Firmware Version: IBM,SF240_358
    Console Login: enable
    Auto Restart: true
    Full Core: false
    可以看到服务器在硬件配置层面提高了很多,在排除了执行计划变坏的可能性之后,数据库性能下降是极不正常的。
    在排除了服务器配置因素之后,进一步检查存储的I/O性能。通过查看AWR报告发现数据库性能下降期间,存储I/O的响应时间下降厉害,单块顺序读(db file sequential read)需要24ms,多块离散读(db file scattered read)需要33ms,日志文件同步(log file sync)竟然高达68ms,如下所示:

    几乎可以确认,存储I/O下降是引起数据库性能下降的主要原因。经过和客户沟通之后,由于种种原因,该库和另外一套数据库需要共用一套存储,而且短期内还不能更改这种架构模式。
    前面提到p780服务器的内存为710G,比原来的p595服务器足足多出524G内存。在目前的硬件条件下,要快速提高数据库性能,只能采取内存换I/O的优化手段。数据库SGA参数修改之前,BUFFER CACHE为40G,SHARED POOL为14G,如下所示:

    经过和客户商量,决定扩大数据库的BUFFER CACHE至256G,并设置db_keep_cache_size至200G,并将最“热”的表和索引KEEP进KEEP POOL中,KEEP语法如下所示:
    alter table xxx storage(buffer_pool keep);
    alter index xxx storage(buffer_pool keep);
    可以通过DBA_SEGMENTS.BUFFER_POOL字段查看对象是否已经KEEP进KEEP池中。如下所示:
    SQL> select distinct BUFFER_POOL from dba_segments;

    BUFFER_
    -------
    DEFAULT
    KEEP
    修改之后的BUFFER CACHE和KEEP POOL大小如下所示:



    设置相关参数并重启数据库,过一段时间,数据库性能得到了极大的提升。尽管单块读的时间依然很高(响应时间为19ms),如下所示:

    但是,查看AWR报告发现数据库每秒的物理读次数下降明显,每秒读数据块个数为1,925个,如下所示:

    而修改参数之前,每秒的物理读高达6624个,如下所示:

    可见,增大数据库的BUFFER CACHE效果还是很明显的,增大BUFFER CACHE使得更多的数据块可以被缓冲到内存中,从而有效地减少了物理读。但需要注意的是,增大BUFFER CACHE会在一定程度上增加CPU的使用率,所幸的是,增大BUFFER CACHE之后CPU空闲率维持在80%左右,系统内存使用率在78%左右,如下所示:



    总结:
    在CPU资源充足的前提下,适当增加BUFFER CACHE内存可以缓减存储I/O资源紧张。

    已有 0 人发表留言,猛击->>这里<<-参与讨论


    ITeye推荐
    • —软件人才免语言低担保 赴美带薪读研!—





沪ICP备19023445号-2号
友情链接