simulator lru latch - Oracle自动评估的代价
Latch NameGet RequestsMissesSleepsSpin GetsSleep1Sleep2Sleep3
row cache objects
58,368,646 483,476 1,905 481,612 0 0 0
simulator lru latch
51,439,871 419,549 13,929 405,970 0 0 0
shared pool
27,813,591 235,396 26,113 210,798 0 0 0
cache buffers chains
1,601,455,224 146,247 11,309 135,537 0 0 0
library cache
27,114,657 111,100 16,330 95,290 0 0 0
在一小时的采样时间内,以上是各主要Latch的使用和Miss信息,我们注意到simulator lru latch已经成为显著的Latch部分。
其Get请求达到1.5万次/秒,虽然Oracle的Latch效率极高,但是其性能影响是存在的。
此客户的数据库版本是 10.2.0.2.0,我们建议用户应当尽快将数据库升级到10.2.0.5.5版本上来。
simulator意为模拟,也就是说当Oracle在内存中进行数据块处理时,实际上还会在预先分配的Buffer中进行相关信息记录,如DBA信息,当数据块被老化之后,下次读取时,如果请求的数据在Simulator内存中存在,则认为继续缓存该数据块是有意义的,通过监控并模拟统计这些操作,并对计算结果加权运算,就可以实现对于内存的调整建议。
在模拟过程中,也是通过Latch来实现的,相关的Latch就有 simulator lru latch 、 simulator hash latch等.
以下是主要的几个模拟Latch:
SQL> select name from v$latch where name like '%simulator%';
NAME
----------------------------------------------------------------
simulator lru latch
simulator hash latch
shared pool simulator在Shared Pool中,记录了相关的内存分配情况:
SQL> select * from v$sgastat where lower(name) like '%simu%';
POOL NAME BYTES
------------ -------------------------- ----------
shared pool simulator latch/bucket st 9216
shared pool simulator hash buckets 16640
shared pool log_simultaneous_copies 480
就Buffer Cache而言,如果系统中该类争用严重,则可以考虑关闭db_cache_advice,消除这部分内部操作对于性能的影响。
以下是一个相关BUG,在该Bug中,由于DB_CACHE_ADVICE的开启导致了严重的simulator lru latch的竞争:
Bug 5918642 Heavy latch contention with DB_CACHE_ADVICE on
This note gives a brief overview of bug 5918642.
The content was last updated on: 01-APR-2008
Click here for details of each of the sections below.
Affects:
Product (Component)Oracle Server (Rdbms)
Range of versions believed to be affectedVersions < 11.2
Versions confirmed as being affected
Platforms affectedGeneric (all / most platforms affected)
Fixed:DescriptionHigh simulator lru latch contention can occur when db_cache_advice is
set to ON if there is a large buffer cache.
Workaround:
Set db_cache_advice to OFF供参考。
By eygle on 2011-11-18 08:13 |
Comments (0) |
Case | 2897 |