Re: "gc current block busy" wait in Concurrent BATCH Processes Run
- From: "Roman Podshivalov" <roman.podshivalov@xxxxxxxxx>
- To: VIVEK_SHARMA@xxxxxxxxxxx
- Date: Wed, 13 Feb 2008 12:29:17 -0500
Hi,
Based on the information from tahiti.oracle.com:
The gc current block busy and gc cr block busy wait events indicate that the
remote instance received the block after a remote instance processing delay.
In most cases, this is due to a log flush. The existence of these wait
events does not necessarily characterize high concurrency for the blocks.
High concurrency is instead evidenced by the existence of the gc buffer busy
event. This event indicates that the block was pinned or held up by a
session on a remote instance. It can also indicate that a session on the
same instance has already requested the block, which in either case is in
transition between instances and the current session needs to wait behind
it.
I would recommend to :
- partition your application to avoid concurrency on the block level
- use smaller block size for top used objects
- optimize log writer
- commit less frequently
- do less changes ;-)
Also you can run racdiag.sql script partially to determine TOP
read/write/ping objects:
-- TOP 10 WRITE PINGING/FUSION OBJECTS
-- This view shows the top 10 objects for write pings accross instances.
-- The inst_id column shows the node that the block was pinged on. The name
-- column shows the object name of the offending object. The file# shows
the
-- offending file number (gc_files_to_locks). The STATUS column will show
the
-- current status of the pinged block. The READ_PINGS will show us read
converts
-- and the WRITE_PINGS will show us objects with write converts. Any rows
that
-- show up are objects that are concurrently accessed across more than 1
instance.
--
set numwidth 8
column name format a20 tru
column kind format a10 tru
select inst_id, name, kind, file#, status, BLOCKS,
READ_PINGS, WRITE_PINGS
from (select p.inst_id, p.name, p.kind, p.file#, p.status,
count(p.block#) BLOCKS, sum(p.forced_reads) READ_PINGS,
sum(p.forced_writes) WRITE_PINGS
from gv$ping p, gv$datafile df
where p.file# = df.file# (+)
group by p.inst_id, p.name, p.kind, p.file#, p.status
order by sum(p.forced_writes) desc)
where rownum < 11
order by WRITE_PINGS desc;
-- TOP 10 READ PINGING/FUSION OBJECTS
-- This view shows the top 10 objects for read pings. The inst_id column
shows
-- the node that the block was pinged on. The name column shows the object
name
-- of the offending object. The file# shows the offending file number
-- (gc_files_to_locks). The STATUS column will show the current status of
the
-- pinged block. The READ_PINGS will show us read converts and the
WRITE_PINGS
-- will show us objects with write converts. Any rows that show up are
objects
-- that are concurrently accessed across more than 1 instance.
--
set numwidth 8
column name format a20 tru
column kind format a10 tru
select inst_id, name, kind, file#, status, BLOCKS,
READ_PINGS, WRITE_PINGS
from (select p.inst_id, p.name, p.kind, p.file#, p.status,
count(p.block#) BLOCKS, sum(p.forced_reads) READ_PINGS,
sum(p.forced_writes) WRITE_PINGS
from gv$ping p, gv$datafile df
where p.file# = df.file# (+)
group by p.inst_id, p.name, p.kind, p.file#, p.status
order by sum(p.forced_reads) desc)
where rownum < 11
order by READ_PINGS desc;
-- TOP 10 FALSE PINGING OBJECTS
-- This view shows the top 10 objects for false pings. This can be avoided
by
-- better gc_files_to_locks configuration. The inst_id column shows the
node
-- that the block was pinged on. The name column shows the object name of
the
-- offending object. The file# shows the offending file number
-- (gc_files_to_locks). The STATUS column will show the current status of
the
-- pinged block. The READ_PINGS will show us read converts and the
WRITE_PINGS
-- will show us objects with write converts. Any rows that show up are
objects
-- that are concurrently accessed across more than 1 instance.
--
set numwidth 8
column name format a20 tru
column kind format a10 tru
select inst_id, name, kind, file#, status, BLOCKS,
READ_PINGS, WRITE_PINGS
from (select p.inst_id, p.name, p.kind, p.file#, p.status,
count(p.block#) BLOCKS, sum(p.forced_reads) READ_PINGS,
sum(p.forced_writes) WRITE_PINGS
from gv$false_ping p, gv$datafile df
where p.file# = df.file# (+)
group by p.inst_id, p.name, p.kind, p.file#, p.status
order by sum(p.forced_writes) desc)
where rownum < 11
order by WRITE_PINGS desc;
--romas
On 2/13/08, VIVEK_SHARMA <VIVEK_SHARMA@xxxxxxxxxxx> wrote:
>
>
> Folks
>
> In a Benchmark Run, 256 concurrent BATCH Processes on RAC using Dedicated
> Sessions (NON-MTS) showing the following Waits:-
>
> How is the "gc current block busy" wait to be addressed?
> From the Statspack Report (Level 7) which section gives the Objects which
> is incurring this wait? Is it the "Segments By Current Blocks Received"
> section OR the "Segments by CR Blocks Received" section?
>
> Will share the Statspack Report, as needed.
>
> Config:-
> Oracle 10.2.0.3 on 3 Node RAC
> Solaris 10
>
> Cheers
>
> Vivek
>
> Statspack Report's Time Elapsed: 11.97 (mins)
>
>
>
> Top 5 Timed Events
> Avg %Total
>
> ~~~~~~~~~~~~~~~~~~
> wait Call
>
> Event Waits Time
> (s) (ms) Time
>
> ----------------------------------------- ------------ ----------- ------
> ------
>
> CPU time 5,854
> 57.6
>
> gc current block busy 24,910 1,463 59
> 14.4
>
> SQL*Net break/reset to client 1,075,218 1,285 1
> 12.6
>
> gcs log flush sync 103,520 511
> 5 5.0
>
> gc buffer busy 6,489
> 367 57 3.6
>
> -------------------------------------------------------------
>
>
>
> Host CPU (CPUs: 120)
>
> ~~~~~~~~ Load Average
>
> Begin End User System Idle WIO WCPU
>
> ------- ------- ------- ------- ------- ------- --------
>
> 8.58 9.54
>
> 8.26 15.61 76.13 0.00 1.19
>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely for the use of the addressee(s). If you are not the intended
> recipient, please notify the sender by e-mail and delete the original
> message. Further, you are not to copy, disclose, or distribute this e-mail
> or its contents to any other person and any such actions are unlawful. This
> e-mail may contain viruses. Infosys has taken every reasonable precaution to
> minimize this risk, but is not liable for any damage you may sustain as a
> result of any virus in this e-mail. You should carry out your own virus
> checks before opening the e-mail or attachment. Infosys reserves the right
> to monitor and review the content of all messages sent to or from this
> e-mail address. Messages sent to or from this e-mail address may be stored
> on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
Other related posts:
