在高事务并发的业务系统中,commit time是Oracle的巨大伤痛所在,commit time是目前为止Oracle最大的串行化所在,其处理能力直接决定了数据库可以处理多少负载。特别在database link环境中,commit time会带来致命的杀伤力,这也是在database link环境中无法做到高并发的基本原因之一。
Commit Time:= Commit CPU + Commit Queue Wait
:= Commit Queue Wait
在commit阶段,可以认为Server process很少会消耗CPU资源,消耗的CPU仅仅是lgwr进程的CPU资源,其主要消耗在于Waiting,等待lgwr进程完成工作并唤醒我。
Commit Time:= redo sync time
:= log file sync
:= redo write time + other waiting time
commit的吞吐量指标由以下几个:
transaction
redo sync writes
redo writes or redo bytes
我们这里选择redo sync writes作为主要的吞吐量指标,以transaction作为辅助性指标。
要保证commit的高效运转,需要确保各个部件完全的高效运转:
(1)、lgwr进程具有足够的CPU资源
CPU ratio,CPU Queue,lgwr CPU ratio,当CPU资源紧张的时候可能需要lgwr和CPU进行绑定,使其更加高效的运用CPU。
当并发量越大,越需要具有强劲的CPU能力使lgwr可以进行快速的通知处理。
(2)、redo log file具有足够用的IO吞吐量
log file parallel write,必须足够快,什么叫做足够快,也就是没有寻道时间,没有定位时间,只有写入时间,一般情况下应该小于1ms。
任何大于1ms的观察都意味着redo log file存在争用。对于具有大容量高速缓存的磁盘系统,也许总是应该是0ms。
(3)、足够快的lgwr频率确保lgwr不会产生写过大的IO量
每次redo write的bytes数量,要保持相对稳定redo writes的bytes数量,总是需要写过大的值,表示lgwr速度跟不上。
或者redo sync writes和 redo writes的比较,当redo sync writes和redo writes的差异比较大的时候,表示lgwr进程慢。
只要redo log file在磁盘里,其处理能力总是有限的。在达到commit极限的时候,最为有效的办法就是减少事务数量。
反正都比较凌乱,本来是想通过主要的RT指标,以及这些RT指标的影响因子来确定的,毕竟这里仅仅是整理思路使用,所以大规模简化了。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/92650/viewspace-775777/,如需转载,请注明出处,否则将追究法律责任。