• 博客访问: 2241468
  • 博文数量: 425
  • 用 户 组: 普通用户
  • 注册时间: 2009-07-04 10:12
  • 认证徽章:
个人简介

ORACLE ACE-A,自07年接触ORACLE数据库,拥有7年ORACLE数据库运维经验,ACOUG,SHOUG核心成员,曾先后就职于东软集团股份有限公司、阿里巴巴(中国)网络科技有限公司,现就职于无锡新彩软件有限公司担任数据库架构师、DBA主管,负责公司数据库架构的设计、DB的规模化运维和性能调优。

文章分类

全部博文(425)

分类: Oracle

2018-04-22 23:33:32

LOG FILE SYNC调优

作为通用的log file sync的诊断、调优方法,一般可以通过诊断系统的IO延迟为多大,CPU资源是否充足来判断哪里出现了问题。

IO延迟的诊断、调优

糟糕的IO性能往往是log file sync过高的罪魁祸首,DBA应该尽量把重做日志放在单独的IO设备上。虽然lgwr可以使用异步IO,但是日志文件打开的时候带有DSYNC标志,日志必须被刷新到磁盘,commit操作才能返回(如果主机有RAID卡,则要刷新到RAID卡的CACHE中,如果使用的是存储,则要刷新到存储的CACHE中)。可以通过log file parallel write这个后台进程等待事件来辅助诊断log file sync等待时间过大的问题。如果log file parallel write等待时间过大,那么你系统的IO很可能出现了问题,但是就像我前面提到的,log file parallel write过大也可能是由于需要写入的日志量过大导致的。优化IO的手段一般为:RAID的方式不要使用RAID5,最好为RAID10,如果使用PC本地盘,那么关闭RAID卡的读CACHE,全部用作写CACHE,如果使用的是存储,可以用2-4块盘做raid10作为日志的磁盘组,对于中高端存储,一般存储机头的CACHE也比较大,IO性能基本能得到保障。

可以尝试使用SSD来存放Oracle的重做日志文件,虽然业界不太推荐使用,但是随着SSD对于写放大算法的优化、Wear leveling、Over-provisioning、GC策略的不断成熟,DBA可以尝试把重做日志放在SSD设备上来提升IO性能。使用SSD存放重做日志的时,最好使用大厂商的SSD产品,如果预算没问题推荐选择SLC类型的SSD,并且在SSD盘上为日志预留足够多的空闲空间,因为对于SSD产品来说,预留空间越多,SSD的寿命也会越长,性能相对也会越好。

CPU资源的诊断、调优

如果CPU资源非常紧缺,Lgwr获得不了CPU资源,会导致系统调用变慢,增加log file sync的等待时间,就像我们上面提到的,system call、信号量、IO call都依赖着CPU资源。如果log file sync的时间与log file parallel write的时间差异过大,则可能系统的CPU资源出现了不足。solaris下还可以通过操作系统工具prstat来诊断lgwr进程的cpu调度延迟时间。其他平台不能直接针对进程进行跟踪诊断,可以通过系统LOAD,CPU使用率来辅助诊断,如CPU使用率超过百分之六十可能就会造成一定程度的调度延迟、CPU运行队列超过逻辑CPU的CORE数就有调度延迟的风险等等。系统的CPU资源出现瓶颈是比较棘手的,因为换硬盘相对来说并不是件麻烦事,但是换CPU就不同了,其难度一般会比较大,最终可能的结果就是换主机。不过也有一些手段可以尝试,例如调高LGWR的优先级,可以通过数据库参数_high_priority_processes进行,或者操作系统命令renice命令进行(前者可能更好点),如果系统CPU非常富足,也可以考虑用taskset等工具为Lgwr进程设置一个独占的CPU(core)

调优应用

有时候更为有效的手段可能不是拼命的调优数据库、调优硬件,比如:是不是可以合并事务,也就降低了LOG FILE SYNC的次数,变相的提高了系统事务的效率。但是为了提升系统的事务数,而去牺牲业务的完整性,需要仔细思考是不是需要这么做,这样做是不是有什么风险。如果在不牺牲业务完整性的情况下,可以合并一些事务,那么起的效果还是立竿见影的。

数据库调优

通过减少事务的日志量可以减轻lgwr的工作量,如:减少不必要字段的更新,减少不必要的索引,不使用CLOB字段等等。

减少日志组内的member数量。一般生产环境都会为日志组的每个member保留2份副本,存储于不同的磁盘或者存储上。如果有可能,可以减少日志组内的member数量,减轻Lgwr的工作量。

像备库传送日志采用异步模式。

内存调优

AIX下,如果开启内存预读,对于提升TPS也是非常的明显 dscrctl -n -b -s 1 还有要密切关注系统的内存使用状况,如果系统出现SWAP,lgwr非常可能被paged out,也会导致lgwr响应非常慢。

上述提供了一些调优log file sync的思路,但是随着系统并发事务数的增多,可能lgwr并不能足够快的去通知大量等待提交的进程。虽然在这个时候,并没有出现CPU资源出现不足,IO也足够快了,但是lgwr工作起来还是慢。上面我已经提到了,在lgwr完成工作后需要通知等待提交的进程,告诉它们提交已经完成,可以干其它事了。如果等待提交的进程过多,lgwr的工作就会越多,相应的延迟就会越大。而且如果有大量进程在等待log file sync,一旦lgwr写完成,它将通知这些进程苏醒,使它们重新进入CPU运行队列,这个情形下,由于lgwr已经工作了一段时间了(已经占用了很多的CPU时间了),而前台进程已经等待了一段时间了(等待LOG FILE SYNC),根据操作系统的默认的调度策略,这种情况下,前台进程将会有更高的优先级获取CPU资源,而lgwr将可能由于CPU资源突发式的紧张而没有获取到CPU资源,导致系统的事务数有抖动,突然有很大的降低。因此我前面所建议的调高LGWR进程优先级的手段是值得尝试的。

阅读(170) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册