13518219792
作为通用的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的次数，变相的提高了系统事务的效率。但是为了提升系统的事务数，而去牺牲业务的完整性，需要仔细思考是不是需要这么做，这样做是不是有什么风险。如果在不牺牲业务完整性的情况下，可以合并一些事务，那么起的效果还是立竿见影的。
数据库调优
l 通过减少事务的日志量可以减轻lgwr的工作量，如：减少不必要字段的更新,减少不必要的索引，不使用CLOB字段等等。
l 减少日志组内的member数量。一般生产环境都会为日志组的每个member保留2份副本，存储于不同的磁盘或者存储上。如果有可能，可以减少日志组内的member数量，减轻Lgwr的工作量。
l 像备库传送日志采用异步模式。
内存调优
在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进程优先级的手段是值得尝试的。
