Re: help: high "gc busy buffer"
Date: Tue, 11 Jan 2011 19:03:15 -0800 (PST)
Message-ID: <41ac2344-1b53-4d59-b546-c9f24eaa79fa_at_l22g2000vbp.googlegroups.com>
On Jan 11, 5:15 pm, charles <dshprope..._at_gmail.com> wrote:
> Dear group,
>
> We are using Oracle 10g on linux RAC with 4 nodes. We have a small
> table, no more than 300 rows, but most people will update/delete/
> insert on it during load testing. And ASH report shows it is the
> cause of this contention.
>
> EVENT CNT
> ------------------------------ ----------
> gc current retry 4
> gc current grant 2-way 31
> gc current request 47
> gc cr request 66
> gc cr multi block request 69
> gc current block busy 79
> gc cr grant 2-way 81
> gc current grant busy 113
> gc current block 2-way 416
> gc cr block busy 420
> gc cr block 2-way 568
> gc buffer busy 6448
>
> All the "gc buffer busy" points to one small table, no index/triggers
> on this table, which 2000 update, 1800 insert, 1600 select. The table
> is created in a ASSM tablespace, so i guess freelist is not going to
> help here.
>
> Could somebody give me some advice?
>
> Thanks
The first question to ask yourself, is the load testing a realistic load test. Some of the win-runners and other load testing software cannot (IMProfessionalO) accurately simulate real-life day to day workloads.
What was the timeframe for these statistics? 1 minute? 1hr? I am curious as to how you have a 300 row table that does 1800 inserts. 2000 updates - again what timeframe. As for the number, it does not seem that bad to me... What is the effect of these buffer busy waits? Are users actually waiting for a response in the app?
If there are at most 300 rows with 1800 delete/inserts and 2000 updates, you may want to do another transactional analysis and ask the question as to why are you doing it this way and is there a better way to achieve the end goal - whatever that may be. Received on Tue Jan 11 2011 - 21:03:15 CST