Re: Perf Advice Needed: cache buffers chains, high waits, _db_block_hash_buckets

Amen. Contention for cache buffers chains means too much logical IO, ie. find and exterminate heavy SQL.

Anjo Kolk wrote:

>Really,
>
>The only thing to do is fix the SQL. Each logical I/O or buffer get results
>in a cache buffer chain latch get. So by doing less LIO, you will get fewer
>latch gets and as a result fewer sleeps on latches. This is how you fix the
>*problem*. You can also fix the *symptom*: bump up _spin_count (assuming
>that you run on a SMP) or set _db_ block_hash_latches to a higher value.
>
>Fixing the SQL is the right way to go. Are you shooting for a 99.99999
>percent buffer cache hit ratio ? If you are than that could also be a reason
>for the problem. Oh and there is a bug in Oracle 8.1.6/8.1.7 I believe that
>causes an additional buffer get for the index root block (assuming that the
>hash latches with the high sleeps cover index root blocks).
>
>Anjo Kolk
>http://www.oraperf.com
>
>----- Original Message -----
>To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
>Sent: Thursday, February 28, 2002 7:53 AM
>_db_block_hash_buckets
>
>
>>db_block_buffers = 360448
>>db_block_lru_latches = 4
>>db_block_size = 8192
>>
>>_db_block_hash_buckets = 720896
>>
>>Ok, what I have so far is:
>>
>>- using itrprof, I saw that 35% of my elapsed time was based on waits of
>> "cache buffers chains" latches.
>>- checking v$latch_children (latch#=66), there are a good number (8-10
>> I'd guess) of the 4096 children that have a very high (10k+) number
>> of sleeps - the rest of the children (of this type latch) have sleep
>> counts are 10-12, so we have a ton of contention on a low # of "cache
>> buffers chains" latches.
>>- joining with x$bh (v$latch_children.addr=x$bh.hladdr), I see that
>> the most contentioned-for of these latches (51,240 sleeps!) has 66
>> blocks on the chain. Checking with all_objects, I'm noticing that these
>> blocks are scattered in some of the more important (and most-accessed)
>> tables and indexes
>>- The other latch children that have high sleep counts also have 30-50
>> buffers in their chains
>>
>>Questions:
>>
>>- to me, 66 seems awfully high - is it?
>>- the sleep count is obviously high from what I can tell - is it
>> definitely tied to the buffer chain this latch is protecting being
>> so long and just happening to be 66 buffers that are mostly important
>> tables and indexes?
>>- I haven't set it by hand, but _db_block_hash_buckets = 720896
>> and this is 11 * 2^16. Everything I've read says it should be
>> a prime number (and that jives with my comp sci background) - why
>> is it not prime, why is it exactly twice db_block_buffers?
>>- the number of children for "cache buffers chains" is 4096. Now,
>> increasing that could have a positive effect on distributing the
>> contention, but since the sleps are so heavily skewed to only a few
>> of the children as it stands, I don't get the feeling that's the
>> right fix.
>>
>>Anyone have any advice to offer? Pages/URL's that can help give some
>>advice?
>>
>>It's worth noting that these latches are basically non-existant as
>>wait events at low load - "log file sync" is about the only wait
>>event I see at low loads, and I'm working on reducing my commit
>>counts much further to help tackle that.
>>
>>Thanks!!
>>
>>James
>>--
>>James Manning <jmm_at_sublogic.com>
>>GPG Key fingerprint = B913 2FBD 14A9 CE18 B2B7 9C8E A0BF B026 EEBB F6E4
>>--
>>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>>--
>>Author: James Manning
>> INET: oracle_at_sublogic.com
>>
>>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>>San Diego, California -- Public Internet access / Mailing Lists
>>--------------------------------------------------------------------
>>To REMOVE yourself from this mailing list, send an E-Mail message
>>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
>>the message BODY, include a line containing: UNSUB ORACLE-L
>>(or the name of mailing list you want to be removed from). You may
>>also send the HELP command for other information (like subscribing).
>>
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Mogens =?ISO-8859-1?Q?N=F8rgaard?=
  INET: mln_at_miracleas.dk

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).