zoukankan      html  css  js  c++  java
  • Wait Event "log file sync"

     1、log file parallel write

        当日志缓存到日志文件时,这是一个主要的等待事件.虽然这个时间的名字中有"并行"(parallel)字样,但即使日志缓存并没有使用并行写,因日志缓存的写出而造成的等待仍然是此等待事件.
        我们可以通过v$system_event来了解下某一个阶段内,此等待事件的平均等待时间.通过此时间值,来评估我们的日志I/O是否正常.有资料介绍当log file parallel write的平均等待时间大于10毫秒时.有可能就表明着日志的吞吐量缓慢.我认为这只是一个参考值,在不同的系统上要根据不同的情况来决定.记录一些在正常情况下log file parallel write等待事件的平均等待时间,当出现问题后,以此时间作为是否有问题的标准.这种方法也是可取的.
        当日志I/O确实有问题时,减少重做产生的数量,确实能够缓解log file parallel write的等待时间.但有时,重做信息的数量是无法减少的.根据情况,将日志I/O转移到更快速的磁盘上,也是解决问题的方法之一.
        日志缓存的大小,有时候也会对此等待事件产生影响.如果你的日志缓存更大,会降低LGWR刷新缓存到磁盘的次数,增大日志的缓存,也会有助于缓解此等待事件.但过大的日志缓存,有可能会造成LGWR间歇性的拥堵.因为LGWR被触发的条件之一是日志缓存满1/3,如果日志缓存过大,1/3的日志缓存数量可能过多,每次LGWR被触发,不得不写大量数据,这造成LGWR间歇性的停顿与拥堵,这也会增加此等待事件的等待时间.我们可以通过设置隐藏参数_log_io_size来改变日志缓存满1/3才触发LGWR的阙值.通过设置此参数,我们即可以拥有较大的日志缓存,又避免了LGWR间歇性的停顿或拥堵.
        我没有在生产库中使用过这个参数,因为他毕竟是一个隐藏参数.虽然据说他不会带来什么bug.在我的测试机上,通过调节这个参数,确实可以对性能略有提升.但这些都是为数据库的"微调".不可能带来大幅度的性能提升.
        LGWR 在刷新缓存时,需要redo allocation和redo writing闩,并且LGWR需要等待一些redo copy 闩的完成.因此,如果这些闩的争用较高,则不要减少_log_io_size此隐藏参数,因为减少它,将会使LGWR更为频繁的刷新缓存.这会进一步加剧这3个闩的争用.减缓LGWR完成工作的速度.
    **小小结:日志缓存到底应该设置为多大??_log_io_size参数的值应该定为多少??这没有一个统一的标准,只有通过多做测试才能决定.
      2、log file sync
        此等待事件用户发出提交或回滚声明后,等待提交完成的事件,提交命令会去做日志同步,也就是写日志缓存到日志文件, 在提交命令未完成前,用户将会看见此等待事件,注意,它专指因提交,回滚而造成的写缓存到日志文件的等待.当发生此等待事件时,有时也会伴随log file parallel write.因为此等待事件将会写日志缓存,如果日志的I/O系统较为缓慢的话,这必将造成log file parallel write 等待.当发生log file sync等待后,判断是否由于缓慢的日志I/O造成的,可以查看两个等待事件的等待时间,如果比较接近,就证明日志I/O比较缓慢或重做日志过多,这时,造成log file sync的原因是因为log file parallel write,可以参考解决log file parallel write的方法解决问题,如果log file sync的等待时间很高,而log file parallel write的等待时间并不高,这意味着log file sync的原因并不是缓慢的日志I/O,而是应用程序过多的提交造成的.

    解决方法参考:

    高log file sync等待事件的3个主要原因。
         ①.高提交频率
                解决方法是简单的消除不必要的提交,事务是工作单元。工作单元应该是全部成功或全部失败。
         ②.缓慢的I/O子系统
            较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。频繁的提交会弄乱数据库布局和IO子系统。
         ③.过大的日志缓冲区
            过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量,允许LGWR变得懒惰,并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数,其默认值是LOG_BUFFER的1/3或1MB,取两者之中较小的值。换句话说,你可以具有较大的日志缓冲区,但较小的_LOG_IO_SIZE将增加后台写入,从而减少log file sync的等待时间。

    via:

    http://www.itpub.net/thread-1876671-1-1.html

    http://www.doc88.com/p-9902182802020.html

     http://www.itpub.net/thread-1807437-1-1.html    (漫谈log file sync )–介绍较详细

  • 相关阅读:
    【原创 Hadoop&Spark 动手实践 6】Spark 编程实例与案例演示
    【原创 Hadoop&Spark 动手实践 7】Spark 计算引擎剖析与动手实践
    【原创 Hadoop&Spark 动手实践 5】Spark 基础入门,集群搭建以及Spark Shell
    【原创 Hadoop&Spark 动手实践 4】Hadoop2.7.3 YARN原理与动手实践
    【转载】MapReduce编程 Intellij Idea配置MapReduce编程环境
    【转载】Hadoop 2.7.3 和Hbase 1.2.4安装教程
    【原创 Hadoop&Spark 动手实践 3】Hadoop2.7.3 MapReduce理论与动手实践
    【转载】systemctl命令完全指南
    【转载 Hadoop&Spark 动手实践 2】Hadoop2.7.3 HDFS理论与动手实践
    【转载】Hadoop官方文档翻译——HDFS Architecture 2.7.3
  • 原文地址:https://www.cnblogs.com/xyarn/p/9771283.html
Copyright © 2011-2022 走看看