Oracle-L: Re: db_block_lru_latches and servers with multiple instances

From: <Jared.Still_at_radisys.com>
Date: Tue, 21 Oct 2003 08:44:25 -0800
Message-ID: <F001.005D3DFE.20031021084425@fatcity.com>

As someone has pointed out to me, latch contention is a consumer of CPU. If you are familiar with Oracle's process of spinning on a latch, you will realize that while waiting for a latch, the CPU will 'spin',
rather than go to the expense of doing a context switch and moving on to something else, then coming back to try and grap the latch.

This is in the belief that the latch will be released soon, which it is in most cases.

Resist all inclinations to modify _spin_count: the solution is still to reduce the latch contention.

Jared

Jared.Still_at_radisys.com
Sent by: ml-errors_at_fatcity.com
10/20/2003 06:59 PM
Please respond to ORACLE-L

        To:     Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
        cc: 
        Subject:        Re: db_block_lru_latches and servers with multiple instances

Interesting question.

Some initial thoughts on that are that latches don't actually consume much CPU. In a poorly written app (or in the extremely rare event of a database bug, but probability of that is so low as to not be worth discussing) you may encounter latch contention that will cause your application to run very slowly, but not actually use too much cpu in the process.

Rather than worry about latch contention on multiple databases, you might want to watch for excessive LIO's ( which do consume cpu), and consider the worst case load for each database in terms of physical IO, CPU and memory (it seems that saying RAM has become politically incorrect, as you are really dealing with virtual memory. but you really do
want your databases to fit in RAM), and determine if your server is up to the task.

Don't forget to consider the IO generated by backups.

Notice I didn't say anything about db_block_lru_latches. You can rarely tune problems away by twisting the knobs.

Now watch someone more knowledgable chime in and make me wish I hadn't replied.

Jared

<rgaffuri_at_cox.net>
Sent by: ml-errors_at_fatcity.com
10/20/2003 07:39 AM
Please respond to ORACLE-L

        
        To:        Multiple recipients of list ORACLE-L 
<ORACLE-L_at_fatcity.com> 
        cc:         
        Subject:        db_block_lru_latches and servers with multiple

instances

We have some servers with 6-8 instances. These are typically staging instances and maybe 1 low transaction production instance.

We keep multiple instances on one server strictly for cost. Licensing additional servers would be prohibitively expensive so we bought higher end servers and stacked them with multiple instances.

My concern here is with latch contention. I have read that its often best to have db_block_lru_latches set to 2 *CPU. We have 4 CPUs on each server and are an NAS hard disk array from network appliances.

Do I have to take into consideration the additional instances on the server when considering latch contention?

--

Please see the official ORACLE-L FAQ: http://www.orafaq.net
--

Author: <rgaffuri_at_cox.net
INET: rgaffuri_at_cox.net

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------

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.net
--

Author:
INET: Jared.Still_at_radisys.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------